Agency websites modernised without losing history

The old site still works, which is exactly why it is still there.

The problem

Agency websites end up on platforms that have passed end of life. The build was current when it was commissioned, then the vendor moved on, the framework had a major version and then another, and the CMS release the site depends on quietly stopped receiving patches. Through all of it the site did its job every day, which is the strongest argument anybody can make for leaving it alone.

The usual answer

So the risk accumulates without ever presenting a deadline. Every month adds a dependency that will not be patched and a feature that cannot be added without touching code nobody supports. Accessibility standards moved on and the templates did not. The people who understood the build have left, so a small content change becomes a change request with an estimate. Deferring only makes the eventual migration larger, because there is more to carry across every year.

How we approach it

We migrate onto a supported stack and carry the content model, the URLs and the compliance posture across with it. The content is inventoried first, because a migration is judged on what survives it: pages, documents, images, and the redirects that keep a decade of external links working. Content types are remodelled rather than copied, so the new site is structured instead of a flat import of the old one. Moving onto the Content Website Platform brings patching and accessibility handling with it. The old site stays live until the new one is accepted, so the cutover is a switch and not a gap.

What changes

An agency lands on current technology without losing the ten years of material the public already links to. The stack is supported again, the accessibility position is current, an editor can make a change without raising a ticket, and the next upgrade is routine work rather than another replacement project.