Website Migration Checklist for UK Business Owners

Decide whether you need a full migration

Before agreeing to a website migration, decide exactly what is changing and what the business must keep working throughout the move. Record the reason for the change, the outcomes to protect and the alternatives considered before anyone starts moving pages or data. A migration is a business change, not simply a new website launch.

Choose the smallest change that meets the business need. A full platform or domain migration may be appropriate when the existing setup cannot support essential requirements or is being replaced. If the current platform can still meet those needs, a redesign or restructure on it may be an alternative. Where a specific part of the site is causing difficulty, a targeted improvement may be enough.

Consider each proposed change separately. For example, a domain change affects the addresses people use, while a restructure changes where visitors find information. Before combining changes, make sure the business can explain why each one is needed and how it will be checked.

List what must continue to work: routes to enquiries or purchases, important customer journeys, useful content, business records and search visibility. Consider who relies on each item and how you would notice if it stopped working. This gives the supplier and internal approvers a practical basis for setting the migration scope, rather than treating launch of the new design as the only measure of success.

Decision record: the business owner or project sponsor should write down the reason for moving, the alternatives considered and the chosen scope. The evidence to request is an agreed scope decision that names what is changing and what must be preserved. If the business cannot yet make that decision, pause the move and clarify the requirement first.

Set the scope, owners and approval process

Once you have decided what kind of change is needed, turn it into a written plan. Make clear what is moving, who is responsible for each part, what must be ready first and who can approve or pause the launch.

• Define the scope. The project lead should keep a list of pages and URLs, files, content, forms, data, integrations and customer journeys included in the move. Ask the relevant business owners to confirm what must be carried across and what can be retired. Evidence: an agreed scope list with exclusions and outstanding decisions recorded.
• Name an owner for each workstream. Assign a business or supplier contact for content, technical changes, data, integrations, testing and launch approval. For each task, record who completes it and who signs it off; these may be different people. Evidence: an ownership list with named individuals and approval responsibilities.
• Record access and dependencies. The project lead should check who can provide access to the current site, domain registrar, analytics, hosting and third-party services. Record internal reviews or supplier work that must happen before another task can start. Evidence: a dependency log showing the owner, status and next action for each item.
• Agree how decisions are made. Set out how requests to add, remove or change work are raised, assessed and approved. Identify the person authorised to accept a change and how its effect on the plan will be recorded. Evidence: a change log that links each approved change to the updated scope and responsibilities.
• Set the launch decision route. Name who has authority to approve the move, who can pause it and how unresolved issues are escalated. Make clear which checks need sign-off before the project can proceed. Evidence: a current plan with named approvers, open issues and a recorded go/no-go decision process.

The project lead should maintain the ownership and dependency log throughout the work, not just at the outset. If a key person, access permission or supplier input is missing, record the issue and agree who will resolve it before it blocks testing or launch.

Inventory the existing site and map its URLs

Build one inventory of the current site before deciding what moves. Include every current URL, then note its purpose, owner, intended action and destination. This gives the content owner and migration supplier a shared record to review, rather than relying on a list of pages alone.

Use a table like this and add a row for each URL or item. For every URL, record whether it will stay, move, be consolidated or be removed. If a page moves or joins another page, name the destination and check that it serves the same business purpose.

Record which kinds of change apply to this project. A domain change alters the site's address; a platform change can affect content, functionality and data handling; a redesign may keep URLs but change layouts or journeys; and restructuring changes page paths or how pages relate to one another. The inventory should capture the changes that apply to this project.

For a move that changes URLs, Google recommends mapping old URLs to their new destinations and using server-side permanent redirects where possible. ¹ Ask the content owner and migration supplier to review the inventory and map together. Before this work is signed off, request an approved map and an explanation for URLs that have no destination, including those intentionally removed.

Check data, access, backups and integrations

Before moving the site, establish what information must move, which connected services rely on it and who can make changes to each account. Ask the supplier for a written plan that names the responsible people, the checks they will complete and any dependencies that could delay the move.

• Business data owner and supplier: List the information to transfer or keep accessible, such as form submissions, customer records, product or service details and relevant files. For each type, record its source, destination, owner and how it will be checked after transfer. Evidence: a data transfer list with the agreed checks and any items that will not be moved.
• Integration owners and supplier: Identify connected services that apply to the business, such as payment, booking, email, customer management, analytics or fulfilment systems. Record who owns each account, what information passes between the site and service, and what must be tested after the change. Evidence: an integration list showing the owner, dependency, test and expected outcome for each connection.
• Business account owner and supplier: Confirm who controls access to the current and new site, domain, hosting and third-party accounts. Agree how the supplier will receive the access it needs, how the business will retain control, and when access that is no longer needed will be removed. Evidence: a handover record naming account owners and outstanding access actions. Do not put passwords in the migration checklist.
• Supplier, confirmed by the business data owner: Ask what will be backed up, where the backup will be held, who is responsible for it and how the business can verify it is complete. Agree how the supplier would restore the relevant information if a transfer or launch issue occurs. Evidence: a backup and recovery plan, plus confirmation that the agreed backup has been completed.
• Business data owner and supplier: Where a website change involves personal data and a supplier or other organisation, review and document each organisation’s role, the processing activities and the respective responsibilities. ² Evidence: the documented roles, activities and responsibilities, with unresolved points assigned to an owner.
• Business data owner and supplier: Confirm the data and integration plan together before launch. Evidence: one documented list of responsibilities, completed checks and outstanding dependencies, with an owner and agreed action for each open item.

Test the new site before launch

Do not treat a supplier’s completion notice as proof that the new site is ready. Ask business representatives to complete realistic tasks on the test site, record what happens at each step and sign off the results before launch.

• Test the customer journeys. The relevant business or service owner should try the tasks customers rely on: find key information, follow a call to action, submit an enquiry, or book or purchase where relevant. Check the expected confirmation appears and that any follow-up reaches the right person or team. Request completed test results showing the journey, outcome and tester.
• Check migrated pages and destinations. The content owner should compare important pages with the agreed inventory and URL map. Confirm content is accurate, moved pages lead to their intended destinations, and pages marked for removal or consolidation are handled as agreed. Request a record of checked URLs and any exceptions.
• Review links and media. Ask the content owner or supplier to check navigation, internal links, downloads and images on representative pages. Open downloads and follow links rather than relying on how the page looks. Record broken links, missing files or incorrect images as defects, with the affected page identified.
• Test forms and connected services. The business owner should submit test enquiries using realistic information; the supplier or integration owner should confirm where each submission appears and who receives any notification. Test other relevant connections, such as booking, payment or customer systems, using an agreed test process. Request evidence that information reached the intended system and that the expected response was triggered.
• Check analytics and tracking. The marketing or analytics owner should confirm that agreed tracking is present and that important actions can be identified in the intended reporting service. The supplier should explain how the check was carried out and flag anything that could not be verified.
• Review mobile use and accessibility basics. Business representatives should try key tasks on different screen sizes and with different input methods, including keyboard navigation. Check that important content and actions remain visible and usable, and that forms can be completed. Log any barrier with the page and task affected.
• Agree the defect process. The business lead and supplier should use one shared record to describe each issue, its impact, its owner and whether it blocks launch. Retest fixes rather than closing them on a status update alone. Request signed-off test results, a resolved-defect record and a list of remaining known issues, with an agreed decision on each before approval.

Use a go-live checklist before switching over

Do not switch the site over until the people responsible can confirm that the agreed launch checks are complete and know who can pause or reverse the change. Record the decision, any accepted risks and the evidence behind it so the business and supplier are working from the same plan.

1. Confirm the launch window and decision-makers. The launch approver records when the change is planned, who must be available to make decisions, and who has authority to proceed, pause or initiate a rollback if that option is available. Evidence: a readiness record naming the approver and the people to contact.
2. Check the release is ready. The content owner confirms the agreed content is present and approved. The migration lead checks the URL map and redirects against the agreed destinations. The relevant business or supplier owners confirm that integrations, access arrangements and backups are ready for the change. Evidence: completed checks, with unresolved items clearly marked rather than assumed complete.
3. Confirm dependencies and contacts. The launch lead checks that any supplier or third party needed for the change knows when it is happening and what they are being asked to do. Make sure the people coordinating the launch can reach those contacts, and that internal decision-makers are available. Evidence: a contact list showing each person’s role and agreed action.
4. Agree the contingency plan. The business approver and supplier identify what the plan covers, who can activate it and what conditions would prompt that decision. Confirm who will assess the issue, communicate the decision and carry out the agreed action. Do not assume a rollback is possible: record any limitations and the alternative response. Evidence: a written contingency plan and named decision-maker.
5. Check the monitoring handover. The person responsible after launch confirms what will be checked, who will review it and how problems will be raised with the supplier or relevant third parties. Evidence: a monitoring plan with named owners and a route for reporting issues.

Final go/no-go: the launch approver confirms that critical customer journeys work, launch-blocking issues are resolved, dependencies are ready and monitoring is in place. They record the decision and any accepted risks in the readiness record. If a critical check is incomplete or the right decision-makers are unavailable, pause and agree the next step rather than proceeding by default.

Monitor the site and resolve problems after launch

After launch, check the live site against the journeys and functions that matter to the business. Agree who will review each item, how often the team will review it and how findings will be recorded; set the monitoring period to suit the site and the level of change.

• Business owner — customer journeys: Test key routes such as finding a service, submitting an enquiry or completing a purchase. Check forms arrive in the right inbox or system, and confirm any automated replies work. Record the test result and retain evidence such as a test enquiry reference.
• Content owner — pages and links: Check priority pages, downloads and internal links on the live site. Review important old addresses against the URL map and confirm they reach relevant new pages. Log any that lead to an error or an unrelated destination, with the old address, intended page and observed result.
• Supplier or integration owner — connected services: Confirm that required systems still exchange the expected information, such as an enquiry reaching the customer management system or an order passing to fulfilment. Record what was checked and investigate missing, duplicated or incorrectly routed data with the relevant owner.
• Analytics owner — measurement: Confirm that agreed analytics records the intended visits and actions. Compare the available reports with the pre-move baseline, allowing for differences in measurement or reporting. Note anything that has stopped recording or changed unexpectedly.
• SEO or site owner — search: Review Search Console for indexing and search performance as part of monitoring. The Page indexing report shows the Google indexing status of URLs Google knows about in a Search Console property. ^{3, 4} Compare priority URLs with the migration map and investigate unexpected indexing statuses or changes in search performance; record the affected pages and ask the relevant owner to assess them.
• Business owner and supplier — issue log: Record each finding, its impact, accountable owner, agreed action and retest result. Keep the log and completed checks as evidence, and confirm that each fix has been retested before closing it.

Include search visibility in the post-launch checks alongside other business-critical outcomes. If a problem appears, document it and investigate the relevant page, redirect, content, technical setup or measurement with the appropriate owner. Continue reviews at the agreed cadence, and adjust them if the evidence shows further checks are needed.

Ask the migration supplier for clear evidence

Before signing off the migration plan, ask the supplier to make responsibilities, dependencies and evidence visible. The business should know who is doing each check, who approves it and what happens if a critical check fails.

• Inventory and URL map: Who owns the inventory and map, who reviews them on the business side, and how will you see approval? Ask for the reviewed map, including the planned action for pages being removed or combined and the destination for changed URLs.
• Data and backups: Who checks that required data has been transferred and that a usable backup is available? Ask for written confirmation of the checks and any limitations or unresolved issues.
• Testing: Who records test results and defects, and who signs off the business-critical journeys? Request the test record and issue log, including how fixes are retested.
• Launch: Who makes the go/no-go decision, and what evidence will they use? Ask for the launch readiness record and the agreed response if a critical check fails.
• Dependencies and monitoring: What does the supplier need from your team, and which third parties must be ready? Confirm who monitors the site after launch, how problems are reported and who checks redirects and important customer journeys.

Agree how often progress is reported and where decisions, evidence and open issues are recorded. If responsibilities or risks remain unclear, a migration review can help assess the scope before you commit to the move. Request a migration review.