Before you cut over, get three things right or your rankings walk out the door with the old CMS: your canonical tags must still point at the same real URLs, your hreflang cluster must stay reciprocal and absolute, and your structured data must ship as JSON-LD that actually validates on the new templates. Redirects get all the attention. These three get skipped, and they're the ones that quietly tell Google and the answer engines which page is the real one, who it's for, and what it even is.
Think of it like moving into a brand-new building where none of the doors have numbers yet.
The movers (crawlers) show up with your furniture. They can see the boxes. But without labels, they have no idea which apartment is really yours, whether the French-speaking tenant is upstairs or across town, or whether the thing they're carrying is a product, an article, or a stack of legal disclaimers. Canonical tags, hreflang, and structured data are the labels. Migrations love to strip labels off boxes.
Canonical tags: the nameplate on the right door
A canonical tag says "of all the doors that look like this one, this is the real address." On the old site your CMS probably generated self-referencing canonicals automatically, and you never thought about them. (Nobody thinks about the thing that works.) Then you migrate, and the new platform starts doing one of two deeply annoying things.
Either it hardcodes the staging domain into every canonical, so you launch with a few thousand pages politely insisting the real version lives at staging.yoursite.com, or it drops the trailing-slash and case rules that used to normalize duplicates, so now /Shoes and /shoes/ both claim to be canonical and Google gets to pick. Worth remembering: Google treats the canonical as a hint, not a command. Get it wrong and they'll overrule you, usually toward the version you didn't want.
The check is boring and non-negotiable. Every canonical on the new build must be an absolute URL on the production domain, must resolve with a 200, and must match the URL you actually want indexed down to the slash and the case. Self-referencing is the default you want unless a page is a deliberate duplicate.
Hreflang: making sure the movers find the right tenant
Hreflang is where good migrations go to die, because it only works when it's mutual. If your English page points to the German page, the German page has to point back. Break one side of that handshake during the move and the whole cluster gets ignored, which means Google shows the English page to your German audience and your bounce rate does something ugly.
Two things break in migration. First, the URLs inside the hreflang tags go stale because the slugs changed on the new platform, so English now points at a German URL that 301s (hreflang wants the final destination, not a redirect). Second, someone fat-fingers the codes. It's en, not eng. It's en-GB, not en-UK (the country code is ISO 3166-1, and "UK" isn't in it, however much it feels like it should be). And if you serve a language picker or a global default, you want an x-default entry, which teams forget roughly every single time.
Verify the cluster after cutover with fresh crawl data, not the spreadsheet you built in the planning phase. The spreadsheet is describing the building you're leaving.
Structured data: the label that says what's in the box
Structured data is how you tell a machine that this box contains a product with a price and a review score, and not just words that happen to mention money. Google reads JSON-LD, microdata, and RDFa, but it recommends JSON-LD, and so should you, because JSON-LD lives in a single script block instead of being wired into every HTML element on the page. That matters enormously in a migration.
Here's why. Microdata is welded to the markup. When your new platform re-renders the templates (and it will, that's the whole point of migrating), the microdata attributes scatter and half your Product schema evaporates. JSON-LD is a self-contained block, so it either ports cleanly or it obviously doesn't. Less ambiguous, easier to test, easier to regenerate from your content model.
Whatever format, run every template type through Google's Rich Results Test and the Schema Markup Validator after the rebuild. Not one page. One of each type: the article, the product, the FAQ, the org homepage, the breadcrumb. Templates fail as a set.
What survives, what silently breaks
| Signal | Common migration failure | What to verify at cutover |
|---|---|---|
| Canonical tag | Staging domain baked in; slash/case duplicates | Absolute, production URL, 200, self-referencing |
| Hreflang | Non-reciprocal; points to redirected URLs; bad codes | Bidirectional, final URLs, valid ISO codes, x-default |
| Structured data | Microdata scattered by re-rendered templates | JSON-LD present and valid per template type |
The reason to catch all three before launch rather than after is that Google won't tell you politely. It just quietly re-picks your canonicals, ignores your hreflang, and drops your rich results, and you find out five weeks later when someone asks why the German traffic fell off a cliff. Crawling the old site first and diffing it against staging is exactly the kind of thing a pre-migration crawl is for: it lists every canonical, every hreflang pair, and every schema block you currently have, so "did it survive?" becomes a comparison instead of a prayer.
So what would I actually do?
I'd treat these three as launch blockers, same tier as the 301 map. Not "post-launch cleanup," not "phase two." If the canonicals point at staging, don't cut over. Snapshot every one of these signals from the live site before you touch anything, rebuild against that snapshot, and re-crawl staging to confirm the labels made the trip. It's fifteen minutes of diffing against months of clawing traffic back.
Because here's the thing about moving into a building with no numbers on the doors. The furniture arrives fine. It's the mail that never finds you.