Managed ecommerce migration: one lead from audit to launch

The scope is agreed in the assessment and written down, but a typical project covers the catalog (products, variants, categories, attributes, images), customer accounts, order history, content pages and blog posts, custom fields and metadata, the URL inventory and redirect map, and the functional decisions around apps, plugins and integrations. Storefront design is either rebuilt on the target platform or adapted to its constraints; which one is realistic is stated before work starts, not discovered afterwards.

What is explicitly out of scope is written down too. A migration that is vague about scope is the one that produces surprises in the last week.

Automated migration tools are good at copying standard entities between well-known platforms, and for a small, simple catalog they may be all you need. They do not decide what happens to a Magento attribute set with forty custom attributes, which WooCommerce plugin tables hold data the business still depends on, or how a multi-currency store should be modelled on the target. Those are decisions, and someone has to own them.

We use automation for what it is good at—extracting, comparing and re-checking thousands of rows—and a human makes and documents the production decisions.

1. Source audit: data volumes, custom fields, plugins/apps, integrations, URL structure, and the reason for the move.

2. Mapping: every important source field gets a destination, a transformation rule or an explicit decision to archive or drop it, approved by you.

3. Trial migration: a representative sample—including the awkward bundles, translated variants and old orders—runs into a staging store. You review it against agreed acceptance criteria.

4. Full migration and reconciliation: counts, relationships, prices, stock and totals are compared between source and target.

5. Launch: content freeze, delta migration of orders and customers created since the full run, redirect activation, DNS or domain switch and go-live checks.

6. Post-launch QA: buying journeys, redirects, crawl errors, integrations and feeds are watched during the first days, and issues are fixed or escalated.

The store does not have to stop trading for the length of the project. The full migration runs while the old store stays live; only the launch window needs a short, planned freeze on catalog edits, followed by a delta migration of new orders and customers. How long that window is depends on the two platforms, order volume and the integrations that must switch over, and it is agreed in the launch runbook in advance.

A written migration plan and scope, the approved field mapping, trial-migration results with acceptance sign-off, reconciliation reports for the full run, the redirect map, a launch and rollback runbook, and a post-launch checklist with its results. If you later need to answer "where did this field go?", the answer is on paper.

If you have a few hundred simple products, no order history worth keeping and no organic traffic to protect, a self-service tool or the target platform's own importer is usually cheaper and perfectly adequate. We will say so in the assessment. Managed migration earns its cost when the store has years of data, meaningful search visibility, custom functionality or integrations that must keep working on day one.