Skip to main content

The 2026 Website Migration Checklist for Ecommerce

For digital strategy leads, ecommerce teams, and the
engineers they hand the work to, who need every check
written down with the proof that closes it.

A systems check for the team doing the building. Every item states what has to be true and the check that proves it, grouped by the phase where fixing it is still cheap, with one goal per phase: carry the traffic and the revenue through the launch.

136
Checks
4
Phases
21
Categories

Before you start

This is a systems check, not a project plan.

A build runs continuously. Every sprint ships something, and every sprint someone has to stop and ask two questions: is the plan still covering everything, and has what we just built been checked from the angle that would catch a problem? This is the list that answers them.

The goal of the list is narrow. Carry the traffic and the revenue the old site earned through the launch and out the other side.

Nothing here is tied to a platform. The checks describe what has to be true of the site rather than how a particular system produces it, so they apply equally to a hosted store, a headless build, and a custom enterprise application.

Nothing here is tied to a schedule either. A launch nine months out runs the same four phases as one four weeks out, in the same order. A short timeline compresses them and never removes one.

Every check comes out of the same place: more than 100 site migrations run over our careers. Nothing on this list is theoretical. Each row is here because its absence cost somebody traffic, revenue, or a month of recovery, and most of them are what a shortcut or a rushed week turns out to cost.

Want a second set of eyes before you cut over?

This is the checklist we run on client migrations. We have partnered with leading Shopify, Adobe, and Salesforce agencies on theirs, and we are glad to help with yours.

A clay rollercoaster track whose rails straighten at the far end into a rocket lifting off

The URL structure and the templates are still open, so a decision made here costs a conversation rather than a rebuild.

Goal for this phaseSign off a URL structure and a redirect map that account for every URL which earned traffic, an external link, or revenue in the last 12 months, before the build freeze.

URL inventory

Protects every URL that earns traffic, a link, or revenue today. Without a complete inventory, pages get discovered a month after they died, when the traffic is already gone.

Usually owned by
SEO lead, with analytics pulling the value per URL
Done when
One file lists every old URL with its status code, its inbound links, and the revenue it earned, and the team has agreed it is complete.

  1. The URL inventory is built from four sources, not one

    How to verifyConfirm the list merges a full crawl, analytics landing pages, Search Console pages, and server log requests. A CMS export alone will miss the long tail that still earns links.

  2. The inventory covers non-HTML assets that earn traffic

    How to verifyCheck that PDFs, images, and feed URLs appear in the list. Filter the log file by extension to see what is actually being requested.

  3. Every inventoried URL has a current status code recorded

    How to verifyCrawl the inventory and store the response code per URL, so URLs that are already broken before the migration are handled rather than carried over.

  4. URLs with external links are flagged separately

    How to verifyJoin the inventory against referring-domain data. These are the URLs where a missed redirect costs link equity you cannot rebuild.

  5. Revenue is attributed to URLs before the rebuild

    How to verifyPull revenue or lead value per landing page for the last 12 months and attach it to the inventory, so mapping can be prioritized by value rather than by template.

What each template needs on the day

The phases above run in time order. These run by page type, because a launch gets divided among the people who own each template. Global applies everywhere.

These hold true on every page. Check them once against a sample of each template.

  1. Robots rules and the noindex flag are what production intends

    How to verifyRead the live robots.txt and crawl a sample for noindex. Staging defaults reaching production is the failure that costs the most and is the easiest to miss.

  2. One canonical per page, self-referencing and resolving

    How to verifyConfirm the canonical points at the live indexable URL, not a staging host or a redirect.

  3. Analytics, consent and server logging are all recording

    How to verifyLoad a page and confirm the tag fires, the consent banner does not block measurement by default, and the request appears in the logs.

  4. The header and footer link set matches the old site

    How to verifyDiff the sitewide link lists. Global navigation carries most internal linking, so a dropped block changes the whole site's internal structure.

  5. HTTPS, www and trailing slash all resolve one way

    How to verifyRequest each variant and confirm a single redirect to the canonical form, with no chains and no loops.