Start with what people can reach today
A website migration might mean moving to a new platform, changing the site’s structure or adopting a new domain. Each can change the addresses people have saved, shared or found through search. Before building the new site, make a list of the existing pages and files that someone might try to open. Include prominent pages, less visible resources, downloadable documents and campaign pages that may still have useful links pointing to them.
Create a working spreadsheet with columns for the old address, what the page does, its planned new address and the person responsible for the decision. Your content list, website menu, analytics records and any available server reports can all help you find pages; no single source is likely to be complete. Ask colleagues which pages they send to customers or include in emails and printed materials.
For each old page, decide whether to keep it, combine it with another page or retire it. This is also a chance to spot content that is out of date. Do not remove a page simply because it is absent from the main navigation: a useful guide or form may still be reached directly.
Map each old address to a useful destination
A redirect sends someone who requests an old address to a different one. For a permanent move, use a permanent redirect where your hosting setup supports it. Match the destination to the visitor’s likely purpose, not merely to the nearest convenient page. If an old page explains how to book a repair, send visitors to the new repair-booking page rather than the home page. If two old pages become one clear guide, both can point to that guide.
Add these decisions to the spreadsheet before launch. Keep the old and new addresses in separate columns, and note exceptions that need a human decision. If a page has no suitable replacement, consider whether a helpful explanation should remain available at its old address. Otherwise, a genuine not-found response is often clearer than redirecting to an unrelated page. Make sure your not-found page offers a way back to useful content, such as navigation or search.
Keep redirects as direct as possible: old address to final address. A chain of several redirects makes problems harder to diagnose and can slow the journey. Check whether changes to trailing slashes, capitalization, file names or subdomains affect your site; the answer depends on its setup. If you are changing domains, plan how the old domain will remain available to serve redirects.
Build and check the new site before switching
Redirects protect incoming links, but they should not replace routine site maintenance. Update menus, buttons, image links and links within articles so they point straight to the new addresses. Review links in downloadable documents and frequently used email templates where practical. Check that each important new page has a clear title and that forms and downloads still work.
Test the redirect map in a staging environment if your setup allows it. Open a sample from every group of old addresses, including common pages, documents and unusual cases. Confirm that each lands on the intended page, not just that something loads. Test the full route a visitor would take: for example, follow an old link to a service page, then use its contact button and submit a test enquiry. Where access controls prevent public testing, arrange a check with the person managing the site.
Write down who will publish the new site, who will apply redirects and who can reverse or fix a change. Set aside a copy of the old address list and the redirect rules. A brief launch checklist helps a small team avoid relying on memory when several changes happen together.
Treat launch as the beginning of verification
Immediately after launch, test the live site rather than assuming that staging results carried over. Try old links from the spreadsheet, check navigation on both a phone and a computer, and verify key tasks such as finding opening hours, downloading a form or contacting the organization. Check that secure connections work on the old and new domains if both are involved.
Over the following weeks, review any available not-found reports, server logs or website measurement tools for addresses visitors still request. Group repeated problems by cause: a missing redirect, a typing mistake in an internal link or a resource that was overlooked. Fix the underlying issue, then retest. Keep an eye on messages from colleagues and customers, who may encounter links in places your inventory missed.
Retain the redirect map as part of the site’s documentation. It gives future editors a record of why an address changed and helps prevent an old destination from being moved again without a plan. A migration is easier to manage when every old link is treated as a visitor trying to complete a task.
