A website migration is easier to manage when every critical check has an owner, an acceptance condition and a recorded result. Choosing the platform still leaves decisions about content, enquiries, account access and who responds when something goes wrong after launch.
This is a project planning template, not a performance report from a particular client migration. The actual deliverables, dates and access arrangements belong in the project proposal.
1. Start with what must keep working
“We need a new website” is not a complete brief. List the business processes that depend on it: enquiries, appointments, purchases, support requests and internal notifications. Give each process a real acceptance test. For a service company, a test enquiry should arrive with the right person and contain the necessary information.
Tell the implementer which services matter commercially, which campaigns link to existing pages and when an interruption would be especially costly. Traffic is only one prioritisation signal. A rarely visited page can still be important to a partner or an existing customer.
Record who can approve changes. Conflicting instructions from several stakeholders are a delivery risk even when the technical work is straightforward.
2. Name the people responsible
The client's decision-maker approves content, offers and business processes. They provide the necessary access and identify who receives test enquiries. They also decide which unresolved issues can wait and which should block launch.
The web implementer completes the agreed build, performs technical checks and keeps a record of defects and corrections. Work that depends on another developer or platform provider needs a named coordinator as well.
The search and measurement owner checks important URLs and agreed events, records a baseline and monitors the transition. In a small team this can be the same person as the developer. The responsibility should still be explicit.
The support owner handles post-launch issues. Agree a contact channel, availability and urgency categories before handover. “Let us know if there is a problem” leaves too much open when a form stops delivering enquiries.
3. Build an acceptance checklist
Google's migration guidance covers testing the new site, mapping old URLs to new ones, configuring redirects and monitoring traffic. It also explains that search rankings can fluctuate during a move. An unchanged ranking should therefore not be promised as a guaranteed launch outcome. Source: Google Search Central.
Assign an owner and status to each item:
- Content: important pages, images, downloads, contact details and language versions checked.
- URLs: the destination of each important old URL documented. Test a permanent redirect where a relevant replacement exists, rather than sending every removed page to the homepage.
- Search access: indexing settings, canonical URLs and internal links checked for the pages intended to go live.
- Forms: successful and unsuccessful submissions, confirmation, recipient and internal handover tested.
- Ecommerce: test orders, status changes and notifications checked using the agreed payment testing procedure.
- Measurement: the agreed event appears in the expected destination, is not counted twice and can be distinguished from real customer activity during testing.
- Rollback: the stop conditions, decision-maker and recovery procedure documented. A store must also account for orders received after the change.
Record evidence alongside the checklist: for example, the test time, the receiving team member's confirmation and any remaining defect. A tick without an explanation is harder to use during handover.
4. Define what the client receives
The domain, platform, analytics and content may sit in separate accounts. The handover list should name their administrators and the access the client receives. Credentials belong in an appropriate secure handover channel, not a public project document.
Ask for a list of subscriptions, renewal costs, required licences and available exports. Source code delivery, full site export and the ability to move to another provider vary by platform and agreement. Establish these points before choosing the system. Account access alone does not describe every contractual right or included service.
Practical handover material can include an account inventory, editing instructions, the accepted test checklist and an explanation of recurring tasks. Agree who keeps it up to date after the initial delivery.
5. Give the post-launch review a date
A useful sequence is an immediate launch check, operational checks in the first days and a later review using comparable reporting periods. The exact cadence should match the site's traffic and operational risk.
Search Console clicks and GA4 events answer different questions. A qualified enquiry additionally requires a business definition: is the request relevant, is the contact reachable and is it a unique enquiry? The receiving team or CRM usually needs to confirm this. More tracked form events do not automatically establish more sales.
Record known defects, the promised correction and its owner. Maintenance, extra features and campaign management may require a separate scope. Accepting the website does not automatically commission those services.
Frequently asked questions
Does a new website need a new domain?
Not necessarily. Start with the business reason. Changing design or platform and changing the domain are separate decisions.
Does choosing the platform solve migration?
No. Content, integrations, testing and account handover still need owners, including when a familiar platform is used.
Who approves the launch?
The named approver, using recorded feedback from the implementer and the people responsible for acceptance checks. Open issues should be visible before that decision.
Can unchanged traffic be guaranteed?
That is not a sound promise. Planning and checking reduce avoidable mistakes, but the implementer does not control every factor influencing search performance.
What should I bring to the first discussion?
Your current URL, important business processes, known problems, available measurement and the decision deadline. Agree the minimum necessary access separately before sharing it.
Explore Somos Media's web development service and our team and public project examples.