Website migration plan: a checklist and the questions to answer first
A website migration is any move that changes where or how your site is delivered: a new platform, new hosting, a new domain or a redesign with new URLs. It affects more than design: addresses found in Google, campaign forms, commercial integrations and team access. This page is a migration plan you can follow, a questionnaire to answer before choosing a launch date, and a checklist for the weeks after. It is written for whoever owns the website in a business, with or without a technical background.
Website migration questionnaire: answer these before you plan
Most problems we see in a migration come from a question nobody asked early enough. Write the answers down, even if some are 'I do not know yet': that is a useful answer too, because it shows what to find out first.
- What is changing: platform, hosting, domain, design, language versions, or several of these together?
- Which pages bring visits or enquiries today? Search Console, analytics and your inbox can all tell you.
- Will any URL change? If so, who decides where each old address should point?
- Where do forms, bookings, newsletters and payments send their data, and who reads it?
- Who controls the domain, DNS and email records, and who can change them on launch day?
- Who approves content, and what is the date after which nothing new is added to the old site?
- What would make you roll back, and who takes that decision?
Step 1: build a useful content inventory
This is the website content migration plan in its simplest form. Collect current pages, downloadable files and contact points. Compare the list with visits, searches and enquiries when those records are available. An older page that barely appears in navigation may still bring customers. Mark what will be retained, rewritten, merged or removed and assign someone to approve each decision.
Step 2: map old addresses to destinations
For changing URLs, Google recommends mapping destinations and using relevant redirects. Do not indiscriminately redirect old pages to the homepage. Your migration table should contain the previous URL, destination and reason. Review internal links, language references and canonical addresses as well. Test examples before applying rules to the complete list.
- Service pages and articles that receive visits.
- Campaign pages and links in external profiles.
- Images or documents with shared links.
- Addresses that should continue to return a genuine not-found response.
Step 3: rehearse the operational journey
A launch can look correct while enquiries still go to an old mailbox. Test the form, delivery, CRM and reply. If DNS changes, identify email records and other services on the domain. Decide who can change each system and when they should intervene. Keep the previous configuration and define a clear condition for rolling back.
Step 4: monitor after publication
Check priority pages, indexability and the sitemap. Compare errors, enquiries and traffic with the previous period while considering seasonality and campaigns. Search fluctuations can occur; redirects do not justify promising zero loss. Keep a record of checks, discovered problems and decisions so the team can follow the outcome.
- Priority pages open correctly and are not blocked from indexing by mistake.
- The new sitemap is submitted and old URLs redirect where the table says they should.
- A test enquiry reaches the right person, and a reply works.
- Errors and enquiries are compared with the same period before the move.
Frequently asked questions
What is a website migration plan?
A written plan that says what is moving, where each old URL will point, who tests what, when the launch happens and how to go back if something fails. It can be one page long for a small site.
What should a website migration questionnaire cover?
What is changing, which pages bring visits, whether URLs change, where forms and email go, who controls the domain and DNS, who approves content and what triggers a rollback. The questionnaire above is a starting point you can adapt.
How do I plan a website content migration?
Start with an inventory of pages, files and contact points, then mark each as keep, rewrite, merge or remove. Assign one person to approve each decision before anything is copied.
Should I change domain and platform together?
It may be necessary, but increases the number of variables. Separate changes where practical and document the intended effect of each.
When can I shut down the old site?
Distinguish the old application from addresses and redirects that must still work. The plan depends on infrastructure and the transition period.
Will a migration affect my Google rankings?
Search positions can fluctuate during a move, even when it is well prepared. Mapping URLs, redirecting them properly and monitoring afterwards reduces the risk, but we cannot promise that nothing changes.
Reference documentation
A note from ArqWeb
This guide organises checks and decisions for a common situation. Implementation depends on the website, access and systems involved. We can assess your situation if you need help applying these steps.
Let's look at your situation.
Tell us what you need and what you have already. We will reply with next steps and a proposal suited to the work.
Discuss my requirements