Many government organization content migration starts the same way: someone draws a box labeled “old system” and another labeled “new system” and draws an arrow between them. The arrow is where the plan ends.

In practice, moving content for a government agency managing thousands of pages of regulatory guidance, program information, forms, and multilingual resources is the part of a modernization project most likely to go sideways. And when it does, it doesn’t just create technical problems. It puts inaccurate or missing information in front of people trying to access benefits, meet compliance requirements, or find the help they need.

A deliberate strategy, one that combines the right tools with clear decisions about what to migrate, how, and what to retire, is what separates a migration that improves the site from one that simply relocates its problems.

Know What Content Is Actually Worth Moving

Most agencies know they have a lot of content. Fewer know what that content is worth.

A content inventory tells you what exists. A content audit tells you whether it should exist, and in what form. Before migrating anything, every piece of content deserves an honest evaluation: 

• Is it still accurate? 
• Does anyone actually need it? 
• Can the intended audience understand it? 

Content that fails these tests shouldn’t be migrated. It should be updated, merged with related content, or retired.

This is also the moment to identify content that requires legal or policy review before it can be changed. Flagging those pages early and building that review time into the project schedule is far better than discovering them mid-migration when timeline pressure is highest.

Agencies that do this work seriously tend to find that a meaningful amount of their content can simply be cut, reducing migration scope, lowering cost, and producing a leaner site on the other end. That’s the payoff for doing the audit before the migration instead of after.

Build a Taxonomy Before You Move a Single Page

Content migration is a rare opportunity to fix structural problems that built up over years of ad hoc growth. Agencies that skip straight to moving content typically recreate the same organizational problems in a new system. Agencies that pause to develop a clear taxonomy come out with something fundamentally better.

A useful taxonomy for a government site covers several dimensions: content types (news article, program overview, regulatory guidance, form), audience tags (businesses, veterans, researchers, the public), topic categories aligned to policy areas, and lifecycle metadata indicating when content was last reviewed and when it needs to be reviewed again. These details form the foundation for site search, navigation, and content governance once the site launches. Getting them right before migration avoids retrofitting them afterward, which is harder and usually done worse under time pressure.

Match Your Migration Method to What You’re Actually Moving

Not all content should be migrated the same way. Treating it all the same wastes time and introduces errors that are hard to find and harder to fix.

Structured, high-volume content with predictable formatting (press releases, job postings, event listings) is generally a strong candidate for automated migration. Scripts can pull data from the existing CMS and map it to the new system’s content types with high accuracy and low manual effort.

Core program content needs a hybrid approach. Benefit descriptions, eligibility requirements, and how-to guides are usually the highest-traffic, highest-stakes pages on an agency’s site. Automated migration can handle the initial move, but human review should follow to verify accuracy and improve readability before anything goes live.

Legacy documents, PDFs, and content with complex formatting often need hands-on attention regardless of automation capabilities. These are also the pages most likely to have regulatory or policy review requirements. Building that review process into the migration workflow as a parallel workstream rather than a final check keeps it from becoming a bottleneck at the end.

Multilingual Content Requires More Than Moving Files

For agencies that serve multilingual communities, migration adds a layer that can’t be automated away. Translated content can’t simply be moved to the new site architecture and called done. Each translated page needs to be verified against the current English source, confirmed to be correctly mapped to its translated equivalent in the new structure, and reviewed for readability and cultural appropriateness alongside technical accuracy.

Agencies that skip this step tend to discover the problem when constituents report receiving outdated or incorrect information in their preferred language. By then, the damage is real. Building translation verification into the migration workflow as a standard step is the only reliable way to prevent it.

Governance Doesn’t Start After the Migration

The agencies that emerge from content migrations in the best shape treat the migration itself as a governance-building exercise. Content will keep aging. Policies will change. New programs will launch. Without clear ownership, defined review cycles, and workflows for retiring content that’s outlived its usefulness, a freshly migrated site starts accumulating the same problems that made the migration necessary.

The goal is a site that stays accurate, useful, and manageable long after launch day.

Forum One has worked with government agencies through every phase of complex content migrations, from audit and taxonomy development through the migration itself and the governance structures that follow. If your agency is planning a migration or trying to make sense of where to start, we’d like to help.