The first part of this series dealt with the decision: when a legacy CMS has crossed from inconvenient to unsustainable, whether to repair, rehost, or replace it, and how to build a business case that holds up under scrutiny. Say that work is done. The evidence points to a move, the target architecture is chosen, and the budget is approved.
Now the risk changes shape. A replatform can be strategically right and still go wrong in execution, taking organic visibility, integrations, or editorial workflows down with it. The difference between the two outcomes is almost never the platform. It is how carefully the migration itself is planned and run. What follows is the execution half: moving content without treating it as a copy job, protecting search through the transition, and getting the security and operational groundwork right before cutover rather than after.
Content Migration Is Harder Than It Looks
Call it content migration and people picture pages moving from one system to another. The reality is heavier. Any given content item can carry fields, taxonomies, relationships, media references, metadata, permissions, revision history, localization, structured data, and URL rules, and a fair number of those will turn out inconsistent or undocumented once you start pulling them across.
So the work is transformation, not copying, and that is where the effort actually goes.
What Happens After a CMS Migration
Content Inventory Comes First
Before content moves anywhere, the organization has to understand what it actually has. That means knowing which pages still draw traffic, which assets carry usage rights, which content types are duplicated, which pages should be merged, archived, rewritten, or retired, and which URLs hold links or search visibility worth protecting.
Migrating everything feels safer, but it usually just relocates years of clutter into a clean platform.
A content inventory is what makes deliberate decisions possible. It also reveals the true scope of the work, which rarely matches the estimate offered during vendor discussions.
Mapping the Old Model to the New One
Legacy fields and templates rarely line up cleanly with a modern content model.
A single large rich-text field may need to become several structured components. Old taxonomy values need normalizing. Relationships need new identifiers. Required fields in the destination may have no equivalent in the source at all. A practical mapping process pins down each piece: source field, destination field, transformation rule, relationship behaviour, URL logic, expected result, and the person responsible for reviewing it.
Trial Migrations Expose Reality
A realistic migration sample gives you evidence that no planning document can.
Run one and the problems surface on their own: broken references, content in formats nobody expected, character encoding issues, missing metadata, assets that fail to move, transformation errors, performance limits. The point is not to prove the first script works. It is to find out where it breaks while breaking things is still cheap.
Structured as a sequence, the work runs from content audit and URL and metadata audit through model mapping, transformation design, media migration, trial migration, delta strategy, cutover, and rollback.
SEO Preservation Cannot Be Left Until Launch Week
A CMS migration can sharpen performance, architecture, and editorial workflows and still do real damage to organic visibility. Google does not care why you replatformed. It reads URLs, redirects, canonicals, internal links, structured data, sitemaps, response codes, page speed, and content, and nothing else. Handle those signals carelessly during the move and search equity built over years can drain away in a few weeks.
URL Mapping Is a Core Migration Asset
Every legacy URL you keep should point to the destination that genuinely matches it. That does not mean dumping thousands of old pages onto the homepage. Search intent and the relationships between pages still count, and the redirect should honour them. Watch for chains too, since every extra hop between old URL and final destination adds friction for crawlers and users alike.
Canonicals, Links, and Sitemaps Need Parity
The new site needs canonical signals that stay consistent. Internal links should point straight at the new URLs. Sitemaps have to reflect the new structure, though the old URLs can stay useful for a while as a way to monitor the transition.
Staging environments have to be kept out of the search index entirely. Robots.txt on its own will not do it when sensitive or duplicate staging content is sitting there publicly accessible.
Monitoring Continues After Cutover
Launch is the beginning of search validation, not the end. Indexed pages, crawl errors, search queries, traffic, redirects, and Core Web Vitals need to be watched after cutover. Unexpected declines require investigation before temporary issues become established patterns. Google’s documented migration controls include thorough testing, complete URL mapping, server-side redirects, updated internal links, sitemap management, Search Console verification, continued redirect retention, and active post-launch monitoring.
Security, Accessibility, and Operations Shape the Real Outcome
A replatform changes far more than how content reaches the page. It resets who can publish, how systems talk to each other, where data lives, how problems get caught, and what happens when something has to be undone. None of it shows up in the editor, and all of it is part of what you are buying.
Governance is where it starts, because every step needs an owner. Who creates, who reviews, who approves, who publishes, who archives, who can pull the lever on a rollback. And above that, who owns the business domain, the editorial process, the build, and production support. Privacy is the other thing a migration drags into daylight. Migrations have a way of exhuming things like dead fields, expired records, retention rules whose origin nobody can name.
And recovery only counts if you have proven it. A backup nobody has restored is a guess with a filename. Rollback belongs at the start of the build, not the Friday before launch, and it runs on real mechanics: pre-cutover backups, restore points, release switching, cache controls, DNS planning, thresholds agreed in advance. QA has to cover all of it: content correctness, SEO parity, regression, accessibility, performance, recovery, not just whether the homepage loads.
A CMS Migration Is Never Just a CMS Migration
Get the diagnosis right, and the migration is mostly execution. Get it wrong, and no amount of new technology saves the outcome.
Trew Knowledge helps organizations assess legacy CMS environments, define the right target architecture, plan complex content and platform migrations, protect search visibility, and build secure digital platforms that can evolve over time. Connect with Trew Knowledge to turn CMS modernization from a high-risk software replacement into a structured, business-led transformation.
