Content Migration Done Right.
Nobody gets excited about content migration. It's the part of a website redesign that doesn't make the proposal deck, doesn't get its own slide in the kickoff meeting, and doesn't get the attention it deserves until something goes wrong. And then it gets all the attention.
Content migration is where large-scale web projects succeed or fail. You can pick the perfect CMS, nail the information architecture, build a beautiful front end, and still watch the whole thing collapse if migration gets treated as a lift-and-shift exercise that somebody will figure out later.
The data backs this up. A Search Engine Journal analysis of 892 website migrations found that the average site takes 523 days to recover its search traffic. 17% never recover at all. And that's just the SEO side. Factor in broken links, missing documents, orphaned pages, and content that doesn't fit the new templates, and you start to understand why Gartner reports that 83% of data migration projects fail or exceed their budgets and schedules.
Why Content Migration Goes Wrong
The root cause is almost always the same: migration gets planned as a technical task when it's actually a content strategy discipline with technical execution.
Here's what that looks like in practice. The development team builds the new site. Somebody says "now we need to move the content over." A content inventory gets started late. The team discovers there are 5,000 pages, not the 500 they assumed. Half are outdated, duplicated, or inconsistent in format. The PDFs alone number in the thousands. And nobody has a clear answer for what content maps to which template in the new system.
We hear some version of this story on nearly every project where migration wasn't planned from day one.
The other common failure is the "just migrate everything" approach. It feels safe because nobody has to make hard decisions about what stays and what goes. But migrating 10,000 pages when 6,000 of them are outdated or redundant means you've spent the budget moving dead weight. Your new site launches looking just as cluttered as the old one, and nobody can find what they need.
What a Well-Planned Migration Actually Looks Like
The organizations that get this right treat content migration as a workstream that starts at the beginning of the project, not the end.
Content audit first. Before anyone writes a line of code, inventory everything. Every page, every PDF, every media file. Categorize by content type, owner, last update date, and traffic. This is the foundation for every decision that follows.
Then decide what moves, what merges, and what retires. This is the hard part, and it requires people who understand the content, not just the technology. A good audit typically recommends migrating 40-60% of existing content as-is, merging or rewriting 20-30%, and retiring the rest. The percentages vary by organization, but the principle holds: not everything deserves a seat on the new bus.
Map content to templates before the migration scripts run, not during. The new CMS will have a defined set of content types and templates. Every piece of migrating content needs a home in one of them. If you're moving from an unstructured site to a structured CMS like Drupal, this is where you define how each field, heading, and media element translates. Skip this step and you'll spend the last two weeks of the project forcing square content into round templates.
Build migration scripts, then validate with real content. Automated scripts handle the bulk transfer, but they need to be tested against actual pages, not sample data. Run a pilot migration with a representative sample (we recommend 10-15% of total content) and check every element: formatting, links, media, metadata, and accessibility compliance.
And build the redirect strategy alongside the content mapping, not after launch. Every URL that changes needs a 301 redirect. Every one. This single factor does more to preserve search engine rankings than anything else in the migration playbook.
When the Scale Gets Serious
For smaller sites (a few hundred pages), migration is manageable with a solid plan and a competent team. When you're dealing with tens of thousands of pages, the complexity compounds in ways that aren't obvious until you're in the middle of it.
At Tactis, we managed one of the larger content migrations in the federal space: consolidating more than 40 Department of Justice websites, roughly 300,000 pages of content, onto a single Drupal platform. That project taught us things that don't show up in the standard migration playbook.
Content governance turned out to be as important as the migration itself. When you're consolidating multiple sites from multiple teams, you need clear ownership rules for the new environment before you start moving content. Who approves? Who publishes? What's the review cycle? Without those answers, you recreate the same fragmentation on the new platform that you were trying to escape from.
Accessibility had to be built into the migration process, not bolted on after. We've written about this before: retroactive accessibility fixes cost 10-30x more than building it right the first time. In a migration, that means every piece of content gets checked against WCAG 2.1 AA during the transfer, not after the site launches.
And at 300,000 pages, manual QA is a fantasy. Automated link checking, accessibility scanning, and content validation tools ran continuously throughout the process. There is no other way to do it at that scale.
The SEO Piece Nobody Wants to Talk About
Content migration and SEO are inseparable, but they're often managed by different teams who don't talk to each other until something breaks.
If your current site has pages ranking well for important search terms, and those pages move to new URLs without proper redirects, you lose that ranking authority. Search engines treat it as if the content disappeared and something unrelated appeared in its place. Recovery, as the Search Engine Journal data shows, averages over 18 months. Some sites never come back.
The safeguards aren't complicated, but they require discipline. Build a complete URL mapping before migration begins, covering every page that currently receives organic traffic. Implement 301 redirects at the server level (not through JavaScript or meta refreshes, which search engines handle differently). Preserve title tags, meta descriptions, and heading structures wherever possible. Submit updated sitemaps to search engines immediately after launch. And monitor search console data daily for the first 30 days post-launch. Crawl errors and ranking drops that get caught in week one are fixable. The ones that go unnoticed for three months are not.
Migration Is a Strategy Problem, Not a Technical One
Content migration rarely gets the spotlight in a redesign project. But it's the workstream most likely to determine whether your new website actually delivers on its promise.
The organizations that treat it as a strategic discipline from day one are the ones whose projects land on time and on budget. The ones that treat it as a late-stage technical task are the ones still explaining traffic drops to their leadership team a year after launch.
Planning a large-scale website migration? We've done this at 300,000 pages. If yours is starting to feel unwieldy, we're happy to share what we've learned.