Every government CMS migration produces the same predictable failure pattern. The new site launches on schedule. The design team celebrates. Marketing announces the modernised digital experience. And within a week, the front office starts getting calls about pages that residents used to find easily and can no longer locate. The pages still exist. The URLs have changed. The search index has not been rebuilt. External links from Google, from bookmarks, from other agencies' websites now go to 404 pages.
This is not the CMS vendor's fault. It is not the design team's fault. It is a failure of migration planning that gives insufficient attention to the search and URL continuity requirements that residents depend on. This checklist covers the specific steps that preserve search integrity through a CMS migration. Work through each section in order. Skipping ahead is where most migrations lose search equity permanently.
When to start this checklist
Begin this checklist 90 days before your planned launch date. The pre-launch work (inventory, URL mapping, redirect planning, search platform selection) is the majority of the total effort and cannot be compressed into the last two weeks before launch without significant risk to search continuity.
Section 1: Pre-Migration Inventory (Weeks -12 to -8)
Complete URL inventory across all domains and subdomains
Crawl every domain, subdomain, and asset URL currently in use. Include every parallel system too: the payment portal, the employment page, the transparency portal, the archived legacy sites. The inventory should include every URL that has been publicly accessible in the last 24 months, because external links, search engine indexes, and resident bookmarks reference all of it.
Pull 24 months of web analytics for URL traffic data
Export Google Analytics or equivalent for the trailing 24 months. Identify pages by pageview volume, entry-page volume, and exit-page volume. High-traffic pages are the highest-priority URL preservation targets. Entry-page volume matters especially because entry pages are where external search engines are sending traffic to your site.
Extract search analytics from the current site
If your current site has any search analytics at all, export the top 500 search queries by volume and the top 200 zero-results queries. These datasets shape both your URL preservation priorities and your content strategy for the new site. A page that receives frequent search traffic must survive the migration.
Identify all inbound links from external sources
Use SEO tools (Screaming Frog, Ahrefs, or equivalent) to extract the list of external websites linking to your government site. Pay particular attention to inbound links from other government agencies (federal, state, or municipal), news sites, and community organisations. These links represent trust signals and traffic sources that break when URLs change without redirects.
Catalogue all PDFs, documents, and downloadable assets
PDFs and documents often have their own URL structure separate from web pages. They must be catalogued, migrated, and redirected as their own class of URL. Missing this step is one of the most common migration failures: web pages are preserved through redirects, but PDFs move to new URLs with no redirect, breaking every external link to the document.
Document current search feature set and behaviour
List every search-related feature the current site has: filter facets, autocomplete, advanced search options, PDF search, department-specific search. The new site should meet or exceed this feature set. Downgrading search functionality during a migration is a common source of user complaints that nobody predicted.
Identify all forms and interactive tools
Forms, calculators, address lookup tools, and interactive components often depend on specific URL paths and query parameters. They require migration testing separate from static content. Failure to migrate a permit application form URL correctly can block resident transactions on day one.
Section 2: URL and Redirect Strategy (Weeks -10 to -6)
Design the new URL structure with SEO in mind
New URL structure should be human-readable, consistent, and hierarchical. Avoid long ID-based URLs (e.g., /page.aspx?id=48291) in favour of descriptive paths (e.g., /services/permits/residential). New URLs should be shorter or equal to old URLs where possible to preserve or improve SEO signal strength.
Map every old URL to its new destination
Every URL in your pre-migration inventory needs an explicit destination on the new site: same URL preserved, 301 redirect to new URL, or 410 (gone) with a reason. The URL mapping is the most important artefact of the migration. It should be reviewed by the web team, the communications team, and the SEO consultant if one is involved.
Implement 301 redirects for every non-preserved URL
301 redirects preserve search engine ranking signals and prevent 404 errors for users following external links. The redirect implementation must be at the web server layer (not client-side JavaScript redirects, which do not preserve SEO signal). Test every redirect in the mapping before launch, not after.
Preserve URL structure for high-value pages where possible
Pages that receive significant external inbound links or high organic search traffic should retain their URLs when possible. A 301 redirect preserves most of the SEO value, but preserving the URL entirely eliminates all risk of signal loss. Make case-by-case decisions for your top 100 pages by inbound link value.
Plan for old-URL long-tail preservation
Some URLs are only used sporadically but represent important content: an archived meeting agenda from 2019, a historical zoning document, a superseded permit form. These should be redirected to appropriate current pages or, where truly obsolete, redirected to a documented archive index that explains the change.
Set up a 404 monitoring and remediation process
Even the most thorough URL mapping misses some pages. A 404 monitoring tool (Google Search Console, or a purpose-built 404 tracker) will surface post-launch 404 errors. Have a process ready to review these weekly and add missing redirects promptly.
Section 3: Search Platform Selection and Configuration (Weeks -8 to -4)
If your migration is an opportunity to upgrade website search from legacy CMS-native search to a proper AI Search platform, this is the phase to make that decision. The migration timeline provides natural cover for a search platform change: residents notice one change (the new site) rather than two (new site plus new search). Compare options at /compare/ if you're weighing this against your current vendor.
Evaluate whether to keep legacy CMS search or upgrade to AI search
Most government CMSs ship with basic keyword search that produces mediocre results even on well-structured content. If your current search is a major source of resident complaint, migration is the right time to upgrade. AI search is available on state contract vehicles that eliminate most of the additional procurement burden.
For new search platform: confirm crawl and indexing works pre-launch
The new search platform must be pointed at the new site and given time to index all content before launch. A first crawl typically takes 2–6 hours for a mid-sized government site. Additional configuration (relevance tuning, exclusion rules, filter facets) takes another 1–2 weeks. Budget the time.
Configure search to exclude staging and preview environments
During migration, staging and preview environments often accumulate URLs that should not be indexed for public search. Confirm that the search platform is configured to crawl only the live domain and to exclude any staging subdomains.
Implement filter facets and refinement options
For government sites with content across multiple departments, filter facets (by department, service type, document type, publication date) are the difference between usable and unusable search. Configure these based on how residents actually navigate your content, not how your organisational chart looks.
Test search for the top 100 pre-migration queries
Take the top 100 search queries from the pre-migration analytics and run them through the new search platform. Every query should return the same or better result than it did on the legacy site. Any query that regresses (returns worse or no results) needs configuration attention before launch.
Configure zero-results reporting from launch
Zero-results queries on the new site are your most valuable early feedback signal. Configure analytics from day one so the reports are available for review starting immediately at launch. Do not wait until week four to check what residents cannot find.
Section 4: Content Migration Quality Control (Weeks -6 to -2)
Verify content preservation for every page in scope
Compare old-page content against new-page content for accuracy. Automated tools can flag pages where content length has changed significantly, indicating potential content loss during migration. Manual review is required for pages containing structured data (tables, forms, embedded content) that migration tools often mangle.
Preserve or migrate all internal linking
Internal links from one page to another must be updated to reflect new URL paths. Legacy internal links that continue to point at old URLs will hit your redirect layer, which works but adds latency and creates a redirect chain. Direct linking to the new URL is preferable.
Test PDF and document accessibility on the new site
Migration is a common point at which PDFs lose accessibility features. Tagged PDFs that were properly structured on the old site may lose their tags during automated migration. Test a sample of migrated PDFs with a PDF/UA checker, or work through the [ADA PDF remediation checklist](/resources/checklist-ada-pdf-remediation/), to confirm accessibility features survived the move.
Confirm metadata preservation
Page titles, meta descriptions, structured data markup, and OpenGraph tags need to migrate to the new site. Missing metadata degrades SEO immediately and reduces click-through rates from external search engines. Verify metadata for at least the top 200 pages by traffic.
Verify multilingual content preservation
If your current site has translated content in any languages, verify that translations are preserved in the migration and that language selection continues to work correctly. Broken language switching after a migration is a common source of complaints from non-English-speaking residents.
Test forms and transactional pages end-to-end
Test every form on the site end-to-end: from search discovery, through form submission, to confirmation. Include tests with real payment processing for forms that involve fees. Payment integration is a common migration failure point that produces immediate revenue impact when it breaks.
Section 5: Pre-Launch Communication and Rollback Plan (Weeks -2 to 0)
Communicate the migration timeline internally
Every department that has staff answering resident questions needs to know when the migration is happening, what will change, and what the workaround is if something doesn't work at launch. Front-office staff, contact centre agents, and department communications leads should have a briefing packet 5 business days before launch.
Prepare launch-day communication for residents
A homepage banner or announcement on launch day explaining 'our website has been updated, here's what's changed, here's where to report issues' reduces confusion. Include a specific feedback mechanism so residents who encounter broken pages or missing content can report them directly.
Have a documented rollback plan
If the migration produces a critical failure on launch day (search returns nothing, key transactional pages don't work, PDFs fail to load), you need a documented procedure for reverting to the previous site. The rollback plan should include specific decision criteria for triggering rollback and technical steps for executing it.
Confirm search platform is fully indexed
Do not launch until the search index is complete. Launching with an incomplete index means residents search for content that exists on the site but cannot be found. This causes immediate user frustration and contact centre volume spikes. Verify index completeness before signing off on the launch.
Prepare launch-week analytics dashboard
Build a dashboard that tracks the metrics that matter in the first two weeks: 404 error rate, top search queries, zero-results queries, form completion rate, contact centre call volume. Review the dashboard daily for the first two weeks. Fast response to emerging issues prevents them from becoming systemic problems.
Section 6: Post-Launch Monitoring (Weeks 0 to +8)
Monitor 404 errors daily for the first 30 days
Set up daily 404 reports from Google Search Console and your web analytics. Any URL producing more than 5 404 hits per day is a missing redirect that needs to be added. Most missed URLs surface in the first 2 weeks; the volume of new 404s should approach zero by week 4.
Review search analytics weekly for the first 8 weeks
Weekly review of zero-results queries and top-clicked search results shows you what content residents are looking for and how well the new search is serving them. Trends emerge fast: any query that appears in zero-results for two consecutive weeks needs content team attention.
Compare pre- and post-launch traffic patterns
Compare traffic patterns to the equivalent period pre-launch. Significant drops in organic search traffic indicate SEO signal loss that needs remediation, usually through additional redirects or metadata fixes. A 5–15% drop in the first month is normal; a 30%+ drop indicates a systemic problem.
Track contact centre call volume for the first 60 days
Any call category showing a significant increase in the first 60 days post-launch may reflect content that residents can no longer find on the site. Route these call category increases to your web team for investigation.
Solicit and act on resident feedback
The launch-day feedback mechanism should produce a steady stream of reports about broken pages, missing content, and confusing navigation. Review this feedback weekly and act on it. Residents who report issues and see them fixed become advocates for the new site. Residents who report issues and see no response stop reporting.
The compounding value of getting migration right
A migration that preserves search continuity, redirects legacy URLs, and improves search quality creates trust in the new site immediately. A migration that breaks these things produces resident complaints that persist for months and require expensive remediation. The 90 days of planning this checklist requires is trivial against the alternative.
Related resources
Redesigning Your Government Website Without Fixing Search Is Just New Paint
Why search must be a first-class concern in every government website project.
SLED AI Search Procurement Checklist
52 vendor evaluation questions for any government AI search procurement.
Your Search Analytics Are Your Best Content Strategy Tool
How to use search data as a content strategy input, before and after migration.
AI Search Product Overview
How Keyspider AI Search works and how it integrates during a CMS migration.
Implementation & Onboarding
From contract to live in weeks, what Keyspider onboarding covers during a migration.
Planning a website migration in the next 12 months?
Our SLED team runs migration search continuity workshops for government agencies. We will review your URL inventory, redirect strategy, and search platform selection before you make procurement decisions that are hard to reverse.
Request a Migration Planning Session