Define the migration and freeze a useful baseline
Replatforming can change the commerce engine, URL model, front end, content system, domain, tracking and operational workflow at once. Naming those changes prevents the team from treating a redesign as a simple data copy. The baseline should preserve enough search, performance and functional evidence to tell whether the new store retained the important jobs of the old one.
Write the change boundary before choosing the cutover
List what remains stable and what changes across domain, protocol, locale, catalogue hierarchy, platform, checkout, integrations and content. Record launches or campaigns that must not overlap the move and identify which decisions require the merchant, technical owner or another specialist.
Capture search, field and lab evidence
Export representative indexed URLs, queries, landing pages, status codes, canonicals, structured data and internal links. Preserve real-user performance by template and device where available, then run repeatable lab journeys so immediate post-launch diagnosis does not depend on field data that needs time to accumulate.
Inventory content, commerce data and dependencies
A migration inventory is more than a product spreadsheet. It covers URLs, media, metadata, taxonomy, editorial content, feeds, analytics, consent, search, reviews and services that influence price, stock, tax, delivery or checkout. Every asset needs an authoritative source, a migration decision and an owner who can verify the result.
Map public search assets separately from operational records
Catalogue the pages and files that customers and crawlers use, including category copy, guides, images, downloadable documents and high-value external destinations. Treat products, customers, orders, refunds and fulfilment records as different data classes with their own retention, security and reconciliation needs.
Confirm access and data responsibility
The customer should identify owners for the old and new platform, domain, DNS, payments, analytics, feeds, ERP, logistics and support tools. Personal or financial data should move only through an approved method with an explicit purpose; legal, tax and records-retention decisions remain with the responsible business and advisers.
Map old intent to truthful new destinations
A redirect plan should preserve the purpose of valuable URLs, not merely reduce the number of 404 responses. Each old product, category and editorial page needs a decision based on its content, current state and closest useful destination. The new information architecture should stand on its own rather than recreate every historical weakness.
Prefer one-to-one or closest-equivalent mappings
Keep stable URLs when practical. Where they change, map to a page that satisfies the same customer need and use a permanent server-side redirect after verification. Avoid sending large groups of unrelated discontinued products to the home page or a broad category that cannot answer the original intent.
Align canonical, language and internal-link signals
Update canonical URLs, hreflang pairs, breadcrumbs, navigation, editorial links, sitemaps and structured-data identifiers to the final production addresses. Remove staging references and redirect chains so the new store does not publish several competing versions of the same page.
Test the new storefront and rehearse cutover
A migration preview must be protected from accidental indexing while still allowing authorized crawl, rendering and browser QA. Representative templates and edge states should be tested with real migrated data, not only ideal fixtures. A written cutover runbook reduces the number of high-risk decisions made while the store is changing live.
Validate search and purchase journeys together
Crawl the preview and inspect status, metadata, canonical output, rendered content, structured data, pagination and internal links. In the same revision, test search, filters, variants, stock, price, cart, checkout handoff, confirmation and failure states across agreed devices without using real customer payment details.
Prepare launch order, ownership and rollback
Sequence content freeze, final data delta, DNS or platform switch, redirects, sitemap publication, analytics verification and smoke tests. Assign each check and define the condition for pausing or reversing the cutover. A backup is not a rollback plan until restoration has been understood and tested safely.
Observe the launch with immediate and delayed evidence
The first hours can reveal broken routes, checkout failures, blocked resources and tracking regressions, while search and field-performance changes require a longer observation window. The monitoring plan should distinguish an implementation incident from expected reprocessing and should compare equivalent page groups rather than one favourable URL.
Run bounded post-launch verification
Test critical routes, sample redirect mappings, crawl controls, canonical output, sitemaps, structured data and purchase states on the exact production revision. Review server and application errors, analytics consent order and feed health without exposing credentials or customer information in reports.
Read field and search trends with context
Annotate the release and compare page groups, devices and countries over an agreed period. Use repeatable lab tests for immediate performance regressions, but wait for sufficient real-user and search evidence before attributing a durable change to the migration.
Agree acceptance, handover and the limits of control
A migration is accepted by evidence that the agreed data and journeys moved correctly, important old addresses reach relevant destinations and the new store can be operated by its owners. It cannot guarantee unchanged rankings, indexing, traffic or revenue because external systems reprocess the site and commercial conditions continue to change.
Use explicit reconciliation and quality criteria
Record expected and migrated counts for the agreed data classes, investigate differences, sample high-value records and verify critical templates, redirects and transactions. List accepted exceptions and unresolved vendor limitations instead of describing a partial move as complete.
Transfer operating knowledge and remaining risk
Hand over the URL map, data reconciliation, launch log, account ownership, monitoring schedule, rollback notes and prioritized post-launch backlog. Copywriting, new features, legal compliance review, provider fees and ongoing SEO remain outside the migration unless the written scope assigns those deliverables and owners.
Questions readers ask
No. Careful baselining, mapping, testing and monitoring reduce avoidable risk, but search systems still need to recrawl and reassess the new store. Competition, content, stock, demand and external signals can also change during the same period.
Every material old URL needs an explicit decision, but not every address deserves a redirect. Use a relevant equivalent when one exists, preserve a clear final state when content is genuinely gone, and avoid bulk redirects that mislead users or hide gaps in the migration inventory.
No. They have different schemas, operational uses, security concerns and reconciliation requirements. Define the authoritative source, required history, approved transfer method and acceptance check for each data class before the cutover is scheduled.