Pre-migration audit: the phase that sets your real budget

Most of the 64% budget-overrun rate is scope discovered late. This phase moves the discovery to when it's free. Nothing gets exported, installed, or quoted until it's done.

The audit checklist

• →
  Crawl the entire live site with Screaming Frog or a comparable tool and export every URL: products, collections, blog posts, filter pages, landing pages. This file becomes your redirect map's source of truth in Phase 3. No crawl, no launch.
• →
  Inventory every plugin, app, and custom script against a structured tech stack audit. Each one gets a verdict: native on the new platform, replaced by an app, rebuilt custom, or retired. Custom checkout logic, gift-card balances, loyalty points, and subscription billing are the four that most often hide a rebuild project.
• →
  Audit product architecture against the destination's limits. Shopify's 3-option/100-variant ceiling is the famous one, but every platform has constraints — attribute models, category depth, metafield equivalents. Products that break the destination's model must be restructured before migration, and finding them now is what keeps the quote honest.
• →
  Pull baseline metrics you'll defend later: checkout conversion, organic sessions by landing page, page speed, support ticket volume, and revenue by channel from your core KPI set. The post-launch argument about whether the migration worked is settled by this snapshot.
• →
  Set budget and timeline with the contingency built in: 25–40% on both. With 64% of data migrations overrunning budget and 54% overrunning timeline, contingency is a planning baseline, not a cushion. Typical all-in spend runs $25K–$500K depending on scope; SMB moves take 2–4 months and enterprise moves 6–18. Model the destination's three-year TCO in the ECM platform calculator before any vendor demo anchors your numbers.
• →
  Pick the launch window now, and make it nowhere near Q4. Launch by early October or wait until January. A slipping timeline that collides with BFCM converts your best month into a QA environment.

Data migration and build: mapping decisions before tool decisions

The transfer tools are commodities. The mapping decisions are the craft, and they're where projects quietly go wrong.

The data checklist

• →
  Decide the attribute mapping deliberately, on paper, before import. Custom attributes from the source platform become metafields, variants, or tags on the destination, and the relationship is rarely one-to-one. This single planning session is the highest-leverage hour in the project; agencies report it's where most migration time burns when skipped.
• →
  Choose tooling by catalog, not marketing: native importers (free) for simple stores, Matrixify-class bulk tools ($20–$200/mo) for large catalogs with technical hands, LitExtension-class services ($200–$400+) for obscure source platforms, agencies ($5K–$250K+) when organic traffic or custom logic makes failure expensive. Watch add-on fees — SEO and redirect handling priced separately can double a tool quote.
• →
  Run the demo migration and audit it like an inspector: 5–10 random products checked for titles, variants, pricing, and images; customers verified with order history attached; every category level if your taxonomy nests deep. Imperfection caught in the demo is free; caught in production it's the 2–5x post-launch fix bill.
• →
  Know what will not transfer and plan each workaround now: customer passwords (hashed — schedule the reset-email campaign as a comms project), themes and design (a rebuild, always), and custom logic (rebuilt or replaced per your Phase 1 inventory). Historical orders typically import as read-only archives that preserve lifetime value and reporting but can't be modified or refunded — brief your support team before launch, not after the first confused ticket.
• →
  Build integrations against the new platform in a staging environment: ERP, 3PL, email platform, reviews, subscriptions, analytics. Each integration is a possible silent failure at launch; each gets its own test case in Phase 4.

SEO protection: the phase with the least forgiving data

Search equity is the one asset a migration can permanently destroy. The Ahrefs finding — 60% of pages that lose rankings never fully recover — is the stake. The checklist below is the insurance.

• 01
  Build the 1:1 redirect map from the Phase 1 crawl, not from memory or a sitemap export. Every legacy URL gets an explicit 301 to its most relevant new equivalent. Regex rules handle dynamic and filter URLs. Redirecting everything to the homepage is not a map; Google treats it as a soft 404.
• 02
  Validate every redirect against the staging site with a crawler before launch. The two recovery patterns are consistent across documented cases. Validated maps produce a roughly 15% organic dip in month one with full recovery by month three. Unvalidated maps produce hundreds of indexed 404s, a 30–60% organic loss in the first three months, and a 2–6 month climb back.
• 03
  Preserve metadata, schema, and canonicals explicitly. Title tags, meta descriptions, alt text, and structured data are premium add-ons on most migration tools and silently skipped on basic plans. Confirm JSON-LD product markup renders on the new platform — well-structured product pages increasingly surface in AI search results without extra work, and losing that markup is losing the visibility.
• 04
  Update the XML sitemap and resubmit in Search Console at launch, keep the old sitemap accessible briefly so crawlers process the redirects, and watch Coverage reports daily for the first two weeks. 404 spikes caught on day two cost hours; caught in week six they cost a quarter.
• 05
  If organic drives meaningful revenue, put a migration-experienced SEO specialist on this phase alone. Their entire job is the crawl, the map, and the validation — the three steps DIY migrations most often shortcut, and the cheapest insurance in the whole project against the 60%-never-recover statistic.

Launch QA: testing like revenue depends on it

The final week is testing, not building. Customer patience is the constraint: 70% of consumers abandon a brand after just two bad experiences, and 40% abandon sites that load slower than three seconds. Launch problems spend that patience fast.

• 01
  Place real test orders through the full stack: payment capture and refund, tax calculation by region, shipping rates against carrier rules, discount codes, and confirmation emails. Miscalculated tax settings and broken shipping zones are the two most common launch-week revenue leaks, and both are free to fix in staging.
• 02
  Test every rebuilt integration as a system: email flows firing from the new platform, reviews rendering, subscriptions billing on schedule, inventory syncing with the 3PL, analytics and pixels recording. A checklist row that says 'installed' is not a test; a transaction flowing end-to-end is.
• 03
  Load-test against your real peak, not average traffic. If the legacy platform's instability during spikes was a reason you left, verify the new stack holds at 2–3x your best day before that day arrives with customers attached.
• 04
  Run the cutover with a freeze plan: a short maintenance window at your lowest-traffic hour, a final delta import of orders and customers created during the transfer, and the DNS switch. Orders placed mid-transfer with no reconciliation plan become the support backlog that eats week one.
• 05
  Spot-check migrated content formatting by hand. Platform editors strip HTML on import — bold text, embeds, and image alignment in blog posts and pages need a human pass. Tedious, cheap, and better found by you than by a customer or by Google.

Post-launch: the project isn't done at launch

The migration is done when the numbers beat the old platform's, not when the DNS flips. Ninety days is the honest evaluation window.

• 01
  Monitor daily for the first two weeks: Search Console coverage and 404 reports, checkout conversion against the Phase 1 baseline, page speed, error logs, and support ticket themes. Every documented fast recovery shares this trait — problems found in days, not discovered in monthly reporting.
• 02
  Expect the organic dip and hold your nerve if the map was validated. Roughly 15% down in month one, recovering by month three, is the documented pattern for clean migrations — one published case recovered and grew organic sessions 10.7% within 90 days. Panic-reverting redirects mid-recovery is how clean migrations become messy ones.
• 03
  Reconcile the app and integration bill at day 30. Replaced tools have a habit of staying subscribed on the old card. The 20–30% operational-overhead savings migrated merchants report only materializes if someone actually cancels the legacy stack.
• 04
  Run the 90-day review against the Phase 1 baseline: checkout conversion, organic sessions, page speed, ticket volume, and total platform cost. 90% of migrators report revenue improvement — verify you're in that cohort with numbers, and if you're not, the variance analysis starts with the redirect map and the checkout funnel, in that order.
• 05
  Write the post-mortem while it's fresh. What the audit missed, which contingency got used, what the next migration should do differently. With 27% of companies eyeing a switch at any given time, this document is an asset — and ECM tracks how these platform moves keep playing out in weekly Insights.