Twelve weeks, wall to wall, for a mid-sized catalogue moving off Magento or WooCommerce onto Shopify with a custom theme, third-party integrations and clean 301s. That's the honest number for a Shopify migration timeline when nobody on the client side goes missing for a fortnight. Six weeks is possible if you accept a stock theme, a flat catalogue and no ERP integration. Twenty weeks happens too, and it's almost never because of code. It's because the product data was worse than anyone admitted, or the person who owns the payment gateway account was on leave.
Here's how the twelve weeks actually get spent, and where the slippage comes from.
Week 0: the pre-mortem nobody schedules
Before any clock starts, we run a discovery pass that answers four questions. How many SKUs, and how many of those are variants of variants? What is currently integrated (ERP, WMS, accounting, marketplace connectors, subscription billing, loyalty)? Who has admin credentials for each of those? And what does the current URL structure look like?
That last one decides more than people expect. A store with clean /product/handle patterns and category pages that map one-to-one onto Shopify collections is a redirect job you can automate. A store with faceted URLs indexed six ways, session IDs in query strings, and 4,000 legacy blog posts under three different path prefixes is a fortnight of spreadsheet work on its own.
We ask for a CSV export of every indexed URL from Search Console and the server logs in week 0, not week 9. When teams push back on this, it's usually because nobody has the logs. That's a finding in itself.
Weeks 1–2: data architecture and the variant problem
Product data is the single biggest predictor of whether a replatform lands on time. Shopify allows 100 variants per product across three option dimensions by default (2,048 with the newer variant limits on some plans, but you still hit option-count walls). Magento's configurable products don't respect that limit. Neither does a WooCommerce store where someone bolted on a variations plugin in 2019.
So the first real work is a mapping document. Source field to destination field, product by product type. Where does the size chart live? Is the HSN code in a custom attribute, and does it need to survive for GST invoicing? What about MRP versus selling price, which Indian stores need displayed separately for compliance and which Shopify handles through compare-at price?
A worked example on effort: 3,200 parent products, average 4.5 variants each, gives roughly 14,400 variant rows. At a realistic 40 rows per minute for automated import with manual spot-checking on 10% of them, the import itself is under a day. The 1,440 spot-checks at two minutes each is 48 hours of human time. That's why data weeks are two weeks, not two days.
The awkward case: bundles and kits. Shopify's native bundling is limited, and if your source platform treated a gift set as a product with its own SKU and its own stock, you need to decide in week 1 whether that becomes a Shopify bundle app, a separate SKU with manual stock reconciliation, or a custom-built solution. Deciding this in week 8 is how projects slip.
Weeks 2–5: design and theme build, running in parallel
Design does not wait for data. If it does, you've serialised two tracks that should overlap and added three weeks for nothing.
By the end of week 2 we want wireframes signed off for the six templates that matter: home, collection, product, cart, search results, and one content page. Not fifteen templates. Six. Everything else is a variation.
Weeks 3 to 5 are theme development. If you're starting from Dawn or a well-built premium theme, this is a customisation job. If the brand insists on a bespoke front end because their Magento store had a hand-rolled checkout flow, add three weeks and expect to argue about it. We've done both. The bespoke builds look better in a deck and cost more to maintain, and about half the time the client's own team can't edit them afterwards without calling us.
The dependency that bites here: content. Copy, photography, size guides, category descriptions. A theme with no real content in it looks finished and isn't. We block out week 5 for content population specifically because clients underestimate it by a factor of three. Somebody has to write 40 collection page descriptions. It is never the developer.
Weeks 4–7: integrations, and the ones that always take longer
Payments first, because in India this has a lead time you don't control. A Razorpay or Cashfree account with the right MCC, KYC documents cleared, and settlement cycle confirmed can take a week or three if the entity structure is at all unusual. Start the paperwork in week 4 at the latest. For UAE stores, the same applies to Network International or Telr onboarding.
COD deserves its own paragraph. If a meaningful share of your orders are cash on delivery, you need order verification (OTP or WhatsApp confirmation), a serviceability check against pincodes at checkout, and a courier integration that pushes AWBs back to Shopify. Three moving parts, three separate app or API decisions, and they interact. A pincode check that runs on the product page but not at checkout is a support ticket generator.
ERP and accounting sync is the classic slipper. Tally, Zoho Books, SAP B1, whatever it is, the integration is usually built by a third party on their schedule, not yours. We ask for a named technical contact on the ERP side in week 1 and a test environment by week 4. If neither exists, we plan for manual order export at launch and integration in week 14. Saying that out loud early is much better than discovering it in week 10.
Everything else — email platform, reviews, loyalty, analytics, subscription billing — is comparatively simple, but the volume adds up. A typical mid-market store carries 12 to 18 apps. Each one needs installing, configuring, testing and a decision about whether it survives the move at all. Roughly a third don't. Good.
Weeks 6–8: SEO, redirects and the part clients skip
Traffic loss after a replatform is almost always a redirect problem, and redirect problems are almost always caused by starting the mapping too late.
The work: export every URL that has organic entrances or backlinks, map each to a destination on the new site, and load the map as Shopify redirects. Shopify's bulk redirect import handles tens of thousands of rows, but it will not tell you when a mapping is wrong. Only a crawl after launch will.
Two things we insist on. One, redirect to the closest real page, never to the homepage. A blanket homepage redirect for 3,000 dead product URLs reads as a soft 404 to Google and you lose the equity. Two, keep the old site's sitemap and internal linking pattern documented so you can diagnose what broke.
Also worth doing in this window: title tags, meta descriptions and structured data for the new templates. Shopify's default product schema is decent, but review markup, breadcrumbs and organisation data usually need adding. Our SEO and content team does this alongside the build rather than after it, because retrofitting schema into a finished theme is slower.
Weeks 8–10: QA, and the test matrix that matters
Two weeks of testing on a twelve-week project. Not one. Not a long weekend.
The matrix: every payment method including UPI, netbanking, cards and COD; every shipping zone and rate; discount stacking, because it never behaves how the marketing team assumes; tax on interstate versus intrastate orders if you're selling across Indian states; order confirmation and shipping notification emails; guest checkout; the mobile experience on a real mid-range Android over 4G, not a desktop browser at 1440px.
Speed testing belongs here too. A theme that scores 82 on desktop and 34 on mobile in Lighthouse is not ready. Most of the gap is app scripts and unoptimised hero images. We fix the obvious offenders during QA and set up ongoing monitoring — SwiftStore is what we use for the scan-and-monitor part, and it handles a fair chunk of the routine fixes without a developer touching the theme. For the deeper theme surgery, that's a separate engagement in speed optimisation.
We get about a third of the discount-logic edge cases wrong on the first QA pass. Buy-two-get-one combined with a customer-tier discount and free shipping over a threshold produces results nobody predicted. Budget for a second pass.
Week 11: launch, and what "launch" actually involves
Cutover is a two-hour job wrapped in a week of nerves.
The sequence: freeze catalogue edits on the old platform, run the final delta import of products, customers and open orders, point DNS, verify SSL, run a live transaction on every payment method, submit the new sitemap, and watch the redirect log for 404 spikes.
Do it on a Tuesday morning. Not Friday evening, and nowhere near a sale. If the calendar says the only free window is 10 days before Diwali, move the launch to January. We've told clients this and lost the timeline argument, and the ones who went ahead spent their peak week fixing checkout instead of buying ads.
Customer passwords don't migrate. They can't, because the hashes are salted differently. Every existing customer needs a password reset email, and that email needs to explain why, or your support inbox floods. Send it the day of cutover, not the day before.
Week 12: stabilisation, not celebration
The last week is monitoring. Crawl the site daily, watch Search Console for coverage errors, check that orders are flowing to the ERP or the export sheet, compare conversion rate against the fortnight before cutover, and fix the twenty small things that only real traffic reveals.
Expect a dip. A 5 to 15% drop in organic sessions for two to four weeks after a well-executed migration is normal while Google reprocesses the redirects. If you're down 40%, something is broken and it's usually redirects or a stray noindex left over from staging. Check the robots.txt and the theme's meta robots tag first. It's the boring answer and it's often right.
What actually causes the slip
In rough order of frequency:
- Content. Nobody owns it. The build finishes and sits empty for three weeks.
- Payment gateway onboarding. Started too late, KYC bounced, entity name mismatch on the bank account.
- ERP integration. A third party's roadmap, not yours.
- Scope added at week 7. Someone sees the staging site and wants a quiz funnel.
- Product data worse than described. Duplicate SKUs, missing images, prices in two currencies in the same column.
Four of those five are on the client side. That's not a complaint, it's a planning input: the milestones where you need a decision from the brand should be named, dated and owned by a person before week 1 ends.
When twelve weeks is the wrong plan
If your catalogue is under 200 SKUs, you're on Shopify already or on a hosted platform with clean exports, and you'll take a customised stock theme, six weeks is realistic and paying for twelve is waste.
Going the other way: multi-store setups, B2B with customer-specific pricing, a wholesale channel, three warehouses with real inventory allocation logic, or a headless front end. Those are 16 to 24 weeks and probably a case for Shopify Plus rather than a standard plan. Plus is worth the jump when you need checkout extensibility, B2B price lists or more than the standard staff and location limits, and not much before that.
If you're sizing this up, the useful next step is a scoping call where we look at your actual URL export and product data before anyone quotes a date. We publish typical ranges on the development cost page, and the migration service page covers what's in scope by platform. Or send us the store URL and a rough SKU count through the free audit form and we'll tell you which of the twelve weeks you can compress.