Migrating a Legacy Public Website Without Losing What Already Works

Public websites age in a particular way. Nobody decides to build a 2,000-page site with six navigation menus and PDFs that are the only copy of an important policy. It happens one reasonable request at a time, over ten or fifteen years, on a content management system that was the right choice when it was bought.

Then the platform reaches end of support, or accessibility rules tighten, or the site simply stops working on phones, and someone has to move it. The technology choice gets most of the attention. In our experience it is the smaller part of the job. The projects that go well are the ones that treat migration as a content and people problem first.

Start with an inventory, not a design

Before anyone sketches a new homepage, find out what actually exists. That means more than a sitemap:

• Every page and file, including the ones no longer linked from navigation but still reachable from search engines and old emails.
• Traffic per page over at least a year, so seasonal content (tax time, registration periods, winter services) is not mistaken for dead content.
• Inbound links from partner sites, printed material and QR codes. These are promises you made to the public.
• Owners. For each section, who is allowed to say "keep", "rewrite" or "retire"?

On a typical legacy site, a large share of pages get almost no visits, and a small set carries most of the traffic. That is good news: it means a migration can be an opportunity to shrink and simplify, not a like-for-like copy of everything.

Decide keep, rewrite or retire

Give every item one of three outcomes:

1. Keep — accurate, used, and fine as written. Move it largely as is.
2. Rewrite — still needed, but buried in a PDF, out of date, or written for the organization rather than the reader. This is where plain-language rewriting pays off.
3. Retire — duplicated, expired or unused. Remove it, and redirect its address to the closest useful page.

The rule that saves the most pain later: nothing is retired without a redirect. A broken link on a public site is a phone call to your service desk.

Automate the move, not the judgment

Copying pages by hand is slow, expensive and error-prone. Most legacy content management systems keep content in a database, which means pages, metadata and file references can be extracted, transformed to the new structure with a mapping workbook, and loaded in bulk with scripts. Automated link checking and accessibility scans then run across the whole result.

People are still needed, but for the decisions only they can make: how sections should be restructured, which content needs rewriting, and whether the new page answers the question the old one did. A good split is roughly machines move, humans decide.

Treat accessibility as a requirement, not a phase

Many older sites hold important information in scanned PDFs, image-only text and layouts that break when zoomed. A migration is the cheapest moment to fix this, because every page is being touched anyway. Aim for WCAG 2.2 Level AA from the first template, build it into the page editor so authors get warnings before publishing, and convert high-traffic PDFs into real web pages.

Protect search and the public's habits

Search engines and residents both remember your old addresses. Keep them working:

• Map every old URL to a new one and serve permanent (301) redirects.
• Keep page titles and key phrases stable for your most-searched services during the switch.
• Submit the new sitemap and monitor "page not found" reports daily for the first few weeks.

Launch once, then keep improving

Big-bang launches are often safer than they sound when the content has been migrated and tested in a staging copy of the live site, with real users testing real tasks. What matters is a rehearsed cutover: a freeze date for content changes, a tested rollback, and a short list of people who can approve fixes in the first week.

After launch, the work changes from moving content to keeping it healthy: every page with an owner and a review date, analytics that show what people search for and fail to find, and a regular clean-up so the new site does not slowly become the next legacy site.

The short version

A legacy website migration succeeds when you know what you have, keep what people use, redirect what you retire, automate the heavy lifting, and design for accessibility from day one. The new platform matters, but the discipline around it matters more.

VectorVue helps public and private organizations plan and deliver website and intranet migrations. If you are facing an end-of-support platform, we are happy to talk through your options.