A website migration moves a site from one platform, domain or structure to another, and the whole risk is in the gap between the old site going dark and the new one being found. A website migration plan template exists so that gap is planned rather than discovered: every old page inventoried, every new page mapped to it, every redirect written and tested before the switch, the content and the features moved with an owner and a date, and a launch day that is a checklist rather than an event. This page is that template, in the six parts a small business can work through in a spreadsheet, and it is the shape of the migration record Stagenix keeps.
Parts one and two: the inventory and the page map
The inventory is every address on the current site with what it is, whether it brings visits or enquiries, and whether it is kept, merged or dropped. It comes from the sitemap, the analytics and a crawl, and it is longer than anyone expects because of old blog posts, category pages and PDFs. The page map is the inventory with a second column: the address on the new site that each old one becomes. Kept pages map to their new address; merged pages map to the page that absorbs them; dropped pages are marked dropped and left to return a proper not-found rather than redirected to the home page. The page map is the plan; everything else is execution.
Parts three and four: redirects, content and features
Every changed address in the page map becomes a permanent redirect, written into the new site before launch and tested against the whole map, with chains collapsed to one hop. Content moves with an owner: who is exporting it, who is checking it landed with its images and its formatting, and who is signing it off. Features do not move; they are set up again on the new platform, and each one (booking, forms, shop, members) gets a line with a person and a date. The project plan is those lines in order with a date against each, and it is the document that turns a migration into a project rather than a weekend.
Parts five and six: launch day and the weeks after
Launch day is a checklist: the domain pointed at the new site, the staging block on indexing removed, the redirects verified against the page map, the forms sent and received, the analytics and the search console seeing the new site, the new sitemap submitted, and the old one left in place for a while so search engines find the redirects. The weeks after are a watch: the search console's not-found and crawl reports, the traffic to the pages that mattered, and the enquiry count against the month before. A migration is finished when the watch shows the site is found, not when the switch is thrown.
Questions people ask about website migration plan template
How long does a website migration take?
For a small site, the planning takes longer than the move: an afternoon on the inventory and page map, a day or two on content and features, and a launch that is an hour if the checklist was done. The watch afterwards runs for weeks.
Do we need to keep the old site running?
Keep the old domain and its redirects indefinitely. The old platform can be closed once the redirects live on the new site and the search console shows the move settled, typically after a few weeks.
What is the single commonest migration mistake?
Launching with the staging site's block on indexing still in place, so the new site is live and invisible. It is one line on the launch checklist and it is missed constantly.