Governed Re-platforming: How to Migrate a Website Without Losing Your SEO — or Your Disclosures

Why re-platforms lose what they were meant to protect #

Most migrations are run as a technical project with an SEO checklist stapled to the side. That framing is the reason they fail — not at cutover, but in the weeks after. There are three silent losses, and they share one dangerous property.

You lose search equity. URLs change. Redirects are mapped for the obvious pages and missed for the long tail that quietly earned half your traffic. Internal links and structured data are rebuilt by hand, template by template, and the rebuild is never quite complete. None of this shows up on launch day, because launch day traffic is dominated by people typing your brand name. It shows up three weeks later, when the pages that used to rank for the queries you do not think to check have slipped two pages down, and the fall is now almost impossible to attribute to the migration that caused it. The pages that go first are rarely the ones anyone is watching: the deep guide that quietly earned links for a decade, the location page that owned a narrow query, the old campaign URL that still converted long after the campaign ended. Their traffic was never on anyone's dashboard, so its disappearance is not on the dashboard either.

You lose disclosure continuity. Sites that carry regulated, required, or governance content — product disclosures, terms, eligibility statements, investor material — re-key that content into new templates during a migration. Wording shifts. Placement changes. A required statement that lived in a fixed position is now rendered by a component that treats it as optional. This is not a question of what you must publish — your compliance function already owns that judgement, and it is not ours to make. It is a question of whether what they maintain survives the move unchanged. A re-platform that silently alters or drops content your compliance team relies on is an engineering and governance failure, and it is invisible until someone goes looking.

You lose publishing governance. The new CMS was very likely bought to fix publishing chaos — the un-reviewed edits, the inconsistent pages, the bottleneck where everything waits on one developer. But a platform does not install discipline; controls do. Migrate without encoding who can publish what, with what review, and the new system faithfully reproduces the old chaos in a nicer interface.

The common property is delay. Every one of these losses surfaces after cutover, in the window where causation is hardest to prove and the project team has already declared victory and dispersed. That delay is exactly why migrations are chronically under-governed: the failure is not at the dramatic moment everyone watches. It is in the quiet weeks no one is watching.

Governed re-platforming: migration as an engineering and governance discipline #

The fix is a shift in where you locate the work. A migration is not a move between two platforms. The value is preserved — or lost — in the control layer between them. Govern that layer with four controls, each engineered, testable, and auditable, and each replacing a manual step you would otherwise merely hope someone completed.

URL and redirect equity. Start with a complete inventory of every URL that carries value — not the top pages, every page with a link or a ranking. Build a one-to-one redirect map against it, and test parity: confirm, before and after cutover, that each old URL resolves to the right new one, that internal links and canonical tags point where they should, and that nothing value-bearing 404s into the dark. This is dull, exhaustive work, which is exactly why it is skipped — and exactly why it is the single largest source of post-migration traffic loss.

Completeness is the part that takes discipline, and it has a method. Your live sitemap is not the inventory — it is the optimistic version of it. The real inventory is reconciled from four sources: a full crawl of the existing site, the server access logs (which surface the URLs that still earn traffic and links but dropped out of the navigation years ago), the Search Console and analytics exports, and the backlink profile. Parity testing then checks each old URL for the failures that hide: a clean single redirect rather than a chain, a final destination that returns 200 rather than redirecting onward into a 404, and canonical and hreflang tags that resolve to live equivalents rather than back to the old domain. The work is mechanical — which is precisely why it can be automated, repeated, and proven, instead of done once by hand and hoped over.

Structured data as governance. Treat schema not as a per-page afterthought applied by hand, but as output your build generates and validates automatically. Make zero-error structured data a release gate: the site does not ship if the structured data does not validate. Schema applied manually drifts the moment the team is busy; schema generated at build cannot.

In practice that means the structured data is assembled from the same content the page is built from, by templates that are themselves tested, and that the pipeline refuses to ship a page whose schema fails validation. The payoff is not only a clean launch day; it is that the guarantee holds for every page published afterwards, because there is no human in the loop to forget. Rich-result eligibility stops being a campaign someone has to run and becomes a property the site cannot quietly lose.

Disclosure continuity. Treat regulated and required content as controlled artefacts that must survive the migration byte-for-byte unless your compliance function deliberately changes them. Diff the old against the new and surface every difference for sign-off. The control is not a legal opinion about what belongs on the page — it is a guarantee that what your compliance team maintains is not silently rewritten by a template.

The mechanic is a diff. Before cutover, snapshot the exact rendered content your compliance function relies on — the statements, their wording, and where they sit on the page. After the new templates render that same content, compare the two and route every difference to the people who own it for sign-off, so that a change is a decision someone made rather than a side effect of a template no one inspected. The control never asserts what a page should say; it only guarantees that nothing changed without someone choosing it.

Publishing governance, installed not lost. A re-platform rebuilds the publishing system anyway, which makes it the cheapest moment you will ever have to install governance: encode who can publish what, what review a change requires, and how a publish is recorded. Skip it and you will retrofit the same controls later, against a live site, at several times the cost.

Installing it is concrete work: define which roles may publish each kind of content, the review a change must pass before it goes live, and a record of every publish that cannot be edited after the fact. The result is that "who changed this page, and who approved it" is a question with a standing answer — not one reconstructed from memory months later when someone finally asks.

None of these is exotic. Each is the difference between a control and a hope — between an engineered step that can be tested and audited, and a manual one that depends on a tired person remembering on a Friday. That difference is the whole of what "governed" means here, and it is the whole of the game.

What "zero-loss" actually takes #

Australian Clinical Labs (ASX: ACL) re-platformed a high-traffic, content-heavy site the governed way, and the outcome shows what the discipline buys.

The starting point was the familiar bottleneck: Umbraco, a developer-gated, server-side .NET CMS where publishing meant waiting on engineering. The destination was a composable stack — a headless CMS feeding a statically generated site through an automated build-and-deploy pipeline on cloud edge infrastructure. The site went live on 14 January 2026 with zero downtime, after 94% of the content — 926 of 983 entries — was migrated within a sixty-day window.

The numbers that a board actually watches moved the right way through the migration, not after a painful recovery. Clickthrough from search rose 18.4%, from 3.8% to 4.5%. Average position improved by three places, from 14.7 to 11.7. Desktop Core Web Vitals went from failing to zero failures within five weeks. Structured data came through at 1,480 items with zero errors, generated automatically at build rather than hand-applied and hoped over.

And the governance was installed, not lost. Three editors now publish directly to the live site in under ten minutes, without waiting on a developer — a controlled, reviewable path, not an open door. The point is not that the new platform is faster in the abstract; it is that the migration preserved the rankings while replacing the bottleneck with a governed process. That is the combination most migrations promise and few deliver: you are supposed to come out ahead on both, and almost everyone trades one for the other.

What made the difference was sequencing the migration as a set of controls rather than a single leap. The sixty-day window was not a deadline to sprint against; it was the time the content needed to be moved deliberately, with the redirect map and the structured-data gate in place before the switch rather than patched in after it. By the time the site went live, the equity-preserving work was already done and tested — so cutover was the calm part of the project, not the cliff edge.

"Moving from Umbraco to Contentful changed what our team can do day-to-day. Publishing used to be fiddly, and things would break. Now it's a publish button, and it's live within minutes. For a small marketing team running a national healthcare brand, that's the difference between reactive and proactive."

— Michael Rothwell, Brand Manager, Australian Clinical Labs

Migration across brands and borders #

The hardest version of the problem is many domains, many markets, one cutover — and OFX (ASX: OFX) is the proof that even that can be done without loss.

OFX consolidated a set of legacy regional domains into a single global brand across six geographies — Australia, the United States, the United Kingdom, Canada, New Zealand, and Hong Kong. Consolidating domains is where equity goes to die: every legacy URL is a thread of accumulated authority, and a careless cutover snaps thousands of them at once. Here it held. Organic sessions grew 250%, and impressions roughly doubled and then some, from around three million to over seven and a half million.

Consolidation is the hard case because authority does not move for free. Each legacy domain had accumulated its own backlinks, its own rankings, its own history — and folding several of them into one means thousands of many-to-one redirects, cross-domain signals that all have to be re-pointed, and regional variants that must be told, unambiguously, which version serves which market. Done carelessly, that authority dilutes, or strands at domains no one visits any more; done as a governed mapping, it concentrates. Which is why brand-query traffic staying flat through the switch is the number that matters most: it is the measurement proving the threads were re-tied, not cut.

The signal that matters most is the least glamorous one: zero loss of organic traffic through the cutover, with brand-query traffic staying flat across the switch. Flat brand traffic through a migration is the tell that the redirect strategy preserved equity rather than gambled it — that the thousands of threads were re-tied, not cut. A 250% growth headline is the reward; the zero-loss cutover is the discipline that made the reward possible.

The leadership view: what to ask before you re-platform #

A re-platform is a board-grade decision dressed up as a technical project, and the people approving it rarely have the four questions that separate a governed migration from a hopeful one. Here they are.

1. Show me the redirect map, and show me how parity is tested. Not "we'll handle redirects" — the actual one-to-one map against a complete URL inventory, and the test that proves every value-bearing URL lands where it should before and after cutover.
2. How is structured data guaranteed at go-live? If the answer is "the team will apply it," it will drift. The answer you want is that schema is generated and validated at build, and that the site does not ship if it fails.
3. How do we prove every required disclosure survived the move unchanged? Not whether the content "was migrated" — whether a diff of the old against the new was reviewed and signed off, so nothing your compliance function maintains was silently altered.
4. What publishing controls does the new platform install? A re-platform that does not leave you with governed publishing has spent the cheapest opportunity you will get to install it.

A governed migration answers all four with artefacts, not assurances. Question one is answered by the redirect map itself and the parity report that shows it passing. Question two by a build that refuses to ship invalid structured data — a gate you can watch run. Question three by a signed content diff that names every change and who approved it. Question four by an audit log of who published what, and when. An ungoverned migration answers the same four questions with reassurance and a hope that the team remembered. The board's job is to tell those two apart, and the tell is simple: whether the answer is a document or a feeling. The difference between the two is the difference between a programme a board can sign on and a risk it has unknowingly accepted.

The Law-to-Code answer #

NETEVO's method is to turn the things organisations usually leave to hope into controls that can be executed, tested, version-controlled, and audited — the same discipline a patent attorney brings to a claim, applied to digital infrastructure. A re-platform is where that discipline pays for itself fastest. The redirect map, the build-time schema gate, the disclosure diff, the encoded publishing rules: each is a soft, manual step turned into a hard, testable one — and each is far cheaper to install while you are rebuilding than to retrofit against a live site afterwards.

And the controls outlast the project. They are not migration scaffolding to be discarded at go-live — they are the audit trail the site keeps producing afterwards: the standing answer to "can you prove nothing broke", ready the next time you change platforms, change templates, or simply have to show your work. That is the quiet compounding benefit of governing the migration rather than merely surviving it. You do not just keep the rankings and the disclosures you arrived with; you leave with a site that can prove its own integrity — which is worth more, the next time someone asks, than any single launch-day number.

Migration is not the moment to find out which of your controls were only ever good intentions. It is the moment to replace them with engineered ones — and to come out the other side with your rankings intact, your disclosures provably unchanged, and a publishing process your team actually governs.