The redirect map is the deliverable

A site that has been running for years is carrying something that cannot be rebuilt: a set of addresses other people have linked to, search engines have indexed, and readers have bookmarked. The content can be re-entered. The design can be redone. The addresses are the only part that took years and cannot be recreated by effort.

Most migration plans treat old URLs as cleanup, scheduled after launch. That ordering is what produces the pattern everybody in this industry has seen: a redesign ships, everyone is pleased with it, and six weeks later somebody notices that organic traffic is down by a third and nobody can say exactly when it started.

The first artefact of a migration is a list of every URL the current site serves. Not the ones in the navigation. Every one. Pull them from the CMS, the server logs, the existing sitemap, Search Console, and a crawl, then merge and deduplicate, because each of those sources knows about URLs the others do not.

Server logs are the source people skip and the one that finds the surprises: the PDF somebody linked from a government site in 2019, the old category path that still gets traffic, the query string a partner uses. A crawl only finds what the site links to. Logs find what the world actually requests.

Every URL gets a decision, and there are only three: it moves to a new address, it stays where it is, or it is retired. Retirement is a legitimate answer. What is not legitimate is a URL with no decision, because that is how a page becomes a 404 nobody chose.

Write the retirements down explicitly, with a reason. A year later somebody will ask why a page disappeared and the honest answer should not be that it was overlooked.

Prefer keeping the existing path where the new system can serve it. Every redirect is a hop, hops chain, and chains are where equity leaks. A migration that changes the URL structure because the new framework has an opinion about URLs is a migration that created work for itself.

A redirect map in a spreadsheet is a hypothesis. Verification turns it into a deliverable. Request every source URL against the deployed site, follow the redirect, and check three things: the status code is a single permanent redirect rather than a chain or a temporary one, the destination is the address the map predicted, and the destination itself returns 200 rather than another redirect or a soft 404.

Run it against a preview deployment before cutover and against production immediately after. The second run is the one that matters, because staging and production differ in exactly the ways that break redirects: trailing slashes, case sensitivity, a CDN rule nobody documented, a legacy rewrite still sitting in front of the origin.

A failure here is a blocker, not a snag. If the verification run finds broken entries at cutover, the correct response is to roll back, not to note it and continue.

One permanent redirect per old URL. No chains. No loops. Every destination returning 200. Retirements listed with reasons. A canonical tag on each new page that points at itself rather than at the old address. And a sitemap generated from the same source as the site navigation, so a route can never be added to the site and forgotten in the sitemap.

None of this is difficult. It is just work that has to happen before launch rather than after it, which is why so much of it does not happen.