Migration is where a content platform project meets everything the organization has published for the past decade, and it is the phase most likely to produce a visible, public failure — because unlike the rest of the work, its mistakes are indexed by search engines and bookmarked by customers.
It is also the phase most often planned as though it were a data transfer. It is not. A migration onto an AI-enabled platform is a restructuring exercise: the value of the destination comes from structured, owned content, and copying unstructured pages into it reproduces the old problems in a more expensive system.
Migration is not a copy
The instinct is to move everything and sort it out later. It is worth resisting for two reasons.
First, a page-for-page copy carries the old content model across, and the old content model is usually "a page with a body field". Retrieval, reuse, and any assistant depend on structure, so a lift-and-shift arrives at the new platform having bought none of the benefit that justified it.
Second, volume is the enemy of quality here. Everything moved is something that must be reviewed, owned, and kept current. Content nobody will vouch for should not be indexed at all — it does not extend coverage, it produces confident wrong answers that crowd out correct ones.
The useful framing: a migration is an opportunity to publish less, better. Organizations that take it report the archive decision as one of the highest-value outcomes of the whole programme, and it costs nothing in licensing.
Inventory, then triage
Every migration starts with a complete list of what exists — URLs, titles, owners, last-modified dates, traffic, and inbound links. Most of that is obtainable from the current platform, analytics, and a crawl, and assembling it is a day or two rather than a workstream.
Then triage every item into one of four outcomes:
- Migrate and restructure. Content that earns its place, remapped into the new content types with real fields rather than a body blob.
- Consolidate. Several near-duplicate pages that should become one maintained record. This is where most of the quality gain lives.
- Archive but redirect. Content that should no longer be published but whose URL has traffic or inbound links. The page goes; the URL keeps working.
- Retire. No traffic, no links, no owner, no value. Confirm rather than assume — a page with modest traffic may be the one a regulator or a major client uses.
Traffic alone is a poor criterion. A procedure used twice a year by the people who must not get it wrong outranks a blog post with a hundred times the pageviews.
Preserve URLs, and where you cannot, redirect deliberately
This is the part with public consequences. Every URL that changes without a redirect discards the search equity accumulated against it and breaks every external link and bookmark pointing at it.
The order of preference is simple and worth holding to:
- Keep the URL unchanged. Always the cheapest option. "We are restructuring anyway" is a weak reason to change an address that works.
- If it must change, redirect permanently from old to new, one hop, to the specific replacement page.
- Where there is no direct replacement, redirect to the closest genuinely useful page — not the homepage. A homepage redirect is a soft failure that tells the visitor nothing and tells a search engine that the old page had no successor.
- Only where nothing is relevant should a URL return "gone" — and that should be a decision, not an omission.
Three mechanical points cause most of the damage when missed. Redirect chains — old to intermediate to new — compound over successive migrations and should be collapsed so every source resolves in one hop. Query strings and tracking parameters must survive the redirect, or campaign attribution silently breaks. And a redirect map is only trustworthy if it is tested against the real inventory: take the full list of old URLs, request each one, and assert that it returns a single permanent redirect to a page that itself returns success.
Restructure as you go, once
Content is easier to restructure while it is being touched than afterwards, and a second pass rarely gets funded. As each item moves, split the body into the fields the new model defines, apply the taxonomy, and record an owner and a review date.
That last pair is what distinguishes a migration that improves the estate from one that relocates it. A record with no owner and no review date arrives at the new platform already on its way to being stale — see content lifecycle management for what happens next, and governance for who is accountable for it.
Where volume makes manual restructuring impractical, AI assistance helps with exactly the tractable parts — proposing field splits, suggesting taxonomy terms, drafting summaries — with a person reviewing. It cannot decide whether a statement is still true, which remains the expensive part.
Planning a migration? Schedule an AI CMS consultation — the inventory and triage are worth doing before the platform decision is final, because they frequently change it.
Choosing a cutover approach
Three patterns, each with a real trade-off:
- Big-bang. Everything moves at once. Simplest to reason about, shortest period of running two systems, and the least forgiving — problems surface at maximum scale with everyone watching. Reasonable for smaller estates with a clean inventory.
- Phased by content area. One section at a time, with redirects routing each as it lands. Lower risk, longer duration, and it requires the two systems to coexist convincingly — including navigation and search that span both, which is more work than it sounds.
- Parallel run. The new platform serves a subset of users or is available alongside the old one before the switch. Safest, most expensive, and it needs a firm end date or it becomes permanent.
Whichever is chosen, decide the rollback position before cutover and confirm it is genuinely available. "We would roll back" is not a plan if the old platform's content has already been decommissioned.
Verify after cutover, not before
The pre-launch checklist is the easy half. What matters is the week afterwards, and the checks worth running are specific:
- Walk the full old-URL inventory and confirm every entry resolves in one hop to a working page. This catches the redirect that was written but never tested.
- Watch server logs for not-found responses and treat each distinct one as a missing redirect until proven otherwise. Real traffic finds URLs no inventory captured.
- Confirm the sitemap describes the new estate and does not still list retired URLs.
- Check indexing and search-console coverage over the following weeks. A migration's search impact is not visible on day one.
- Re-run retrieval against a fixed question set. If the platform has an assistant or semantic search, migration changed its corpus — quality must be re-measured, not assumed. Quality assurance covers the method.
- Confirm permissions on the new platform as several roles. A migration is a common moment for access to become quietly more permissive than it was.
Expect a temporary dip in search performance even when the migration is executed well; search engines take time to recrawl and reconcile. Knowing that in advance prevents a well-run migration being judged a failure in week two.
What to leave behind deliberately
Two things are worth naming because they are usually carried across by default and should not be. Old redirect chains from previous migrations should be resolved to their final destinations rather than inherited. And legacy content types that exist because a previous platform required them — a "landing page" type that differs from "page" only in history — should be consolidated during the move, since they will otherwise complicate the content model permanently.
How LABUSA runs migrations
We treat the inventory and triage as the first deliverable and the redirect map as a tested artefact rather than a spreadsheet, because those two are what determine whether a migration is invisible to your audience or memorable for the wrong reason.
Because an AI-powered content platform derives its value from structure, we restructure during the move rather than after it, and we are direct about which content should not make the journey. Where Drupal is the destination, our Drupal development and managed hosting packages cover the build and the hosting alongside the migration itself.
Frequently asked questions
How much of our content should we expect to migrate?
Fewer items than you have, and it varies enormously with how long the estate has existed and how often it has been reorganised. The useful discipline is requiring an owner for anything that moves — that single rule tends to shorten the list considerably.
Will we lose search rankings?
Some short-term movement is normal even with a correct redirect map, because search engines need time to recrawl. Sustained loss usually traces to changed URLs without redirects, redirect chains, or content that was consolidated more aggressively than the audience expected.
Can the migration be automated?
The mechanical parts, largely — extracting, mapping fields, moving files. The decisions cannot: what to keep, how to restructure it, who owns it. Those are the parts that determine whether the destination is better than the origin.
Should we migrate first or restructure first?
Restructure as part of migrating. Moving unchanged with the intention of restructuring later means paying to review everything twice, and the second pass rarely happens.
What about content in other systems?
Not everything needs to move. Content that is well maintained where it lives can often be retrieved in place, which avoids a migration entirely — provided its permission model can be honoured at query time.
Related reading
- How to Implement an AI-Powered CMS — where migration sits in the wider sequence.
- AI CMS Implementation Challenges — the failure modes around it.
- How to Choose an AI CMS Solution — extending rather than replacing avoids a migration entirely.
- AI Content Lifecycle Management — keeping the migrated estate current.