A website migration is rarely just a technical switch. It can affect search rankings, enquiry forms, paid campaign landing pages, customer logins, analytics, email, billing and day-to-day operations. This guide to website migration process is for business owners and product teams who need to move a site without turning go-live day into a costly recovery project.
The safest migrations are planned around what the website does for the business, not simply where its files live. A five-page brochure site moving to better hosting has different risks from a SaaS product moving authentication, Stripe billing and a Supabase database. The principles are the same, but the level of testing should match the consequences of getting something wrong.
Start with the reason for the migration
First, define what is changing. You may be moving to a new host, replacing WordPress with a custom-built site, changing domains, consolidating several websites, or redesigning a marketing site while keeping the same CMS. Each route creates different work.
A hosting-only move may preserve URLs and page structure, making it relatively contained. A platform rebuild often changes templates, assets, forms, URLs and tracking. A domain change adds DNS, email and search-engine considerations. Combining all three can be sensible when the existing setup is holding the business back, but it increases the need for a controlled release.
Write down the commercial objective in plain terms. Perhaps the current site is slow, difficult to update, visually dated or unable to support lead capture properly. For a web app, the objective might be better performance, cleaner deployment, stronger permissions or a more maintainable architecture. That objective helps the team make good trade-offs when a feature, page or integration needs a decision.
Audit the current site before building anything
The existing site is the source of truth until the new one has been checked. Take an inventory before content is moved or templates are redesigned. This is where many migrations fail quietly: a high-performing service page is omitted, an old campaign URL stops working, or a downloadable resource disappears.
Record every indexable URL, its page title, meta description, heading structure, organic traffic, conversions and backlink value where available. Identify pages that generate enquiries or rank for valuable local and commercial searches. These pages deserve particular care, even if their design is being replaced.
Also audit the operational parts of the site. Check contact forms, CRM connections, newsletter sign-ups, live chat, booking tools, payment flows, login areas, embedded maps, cookies, analytics events and tag manager containers. If the site sends transactional emails, confirm the sending domain, templates and reply address too.
For larger sites, a migration spreadsheet is worth the effort. It should map every important old URL to its intended new URL, show whether it will be redirected, and identify the owner responsible for approving the page. It is less glamorous than a new homepage design, but it prevents expensive omissions.
Build the new site in a safe environment
Do not build directly on the live domain. Use a staging environment that is protected from public access and blocked from search indexing. This gives you space to review layouts, test integrations and resolve issues without customers or Google seeing unfinished work.
A good build phase covers more than visual approval. Test the site across current desktop and mobile browsers, including the browsers used by your actual audience. Check image compression, font loading, keyboard navigation, form validation, error states and responsive behaviour. A polished design that drops leads on mobile is not finished.
For a web application, test permission boundaries as well as happy paths. A standard user should not be able to access another customer’s data by changing a URL. Billing webhooks should handle failed payments and duplicate events. Database migrations need a rollback plan, particularly if the new release changes live customer records.
Performance should be reviewed before launch, not after complaints arrive. Optimised images, sensible caching, lean front-end code and properly configured hosting all matter. However, do not chase a perfect performance score at the expense of a useful feature or clear conversion journey. The right balance depends on what the site needs to do.
Plan redirects and preserve search visibility
Redirects are the backbone of a content or domain migration. When an old page has a relevant replacement, set a permanent 301 redirect from the old URL to the closest equivalent new URL. This helps users reach the right content and gives search engines a clear signal about the change.
Avoid sending every retired page to the homepage. That may look tidy, but it creates a poor experience and can confuse search engines. If there is no genuine replacement, returning a proper 404 or 410 response is often more honest. A small number of carefully handled retired pages is better than a blanket redirect rule.
Keep URLs stable where possible. Changing page slugs, site structure and domain at the same time is sometimes necessary, but every avoidable change creates another variable. If a service page already ranks and still serves the same purpose, retaining its URL can reduce risk.
The new site should also carry forward its essential SEO foundations: unique titles and descriptions, logical headings, canonical tags, XML sitemap, robots directives, structured data where relevant, and image alt text. Confirm that staging noindex rules are removed before launch. It sounds basic, yet a noindex tag left in production can wipe out visibility surprisingly quickly.
The website migration process on launch day
Choose a launch window that suits the business. For a local service website, a quieter period may be enough. For an ecommerce store, SaaS product or high-traffic campaign site, schedule the move when the right people can monitor it and support customers if needed.
Before DNS is changed, take a complete backup of files, databases, configuration and any uploaded content. Confirm who has access to the domain registrar, hosting account, DNS provider, analytics and third-party services. Launches stall when a critical login belongs to a former employee or agency.
Use this pre-launch checklist:
- Confirm the approved production build matches the staging site.
- Test forms, payment journeys, sign-in flows and key integrations with real test data.
- Validate 301 redirects for priority pages and check that there are no redirect chains.
- Check analytics, consent settings and conversion events are firing correctly.
- Back up the existing production site and document a rollback route.
Once DNS changes are made, test the live site on both the preferred domain version and any non-preferred variants. Confirm HTTPS is active, mixed-content warnings are absent, and the canonical domain resolves consistently. DNS propagation can vary, so avoid assuming every visitor sees the new version immediately.
Monitor the first days after launch
Go-live is the start of the verification period, not the finish line. Review server errors, form submissions, uptime, analytics and search console data closely during the first 48 to 72 hours. Test key journeys again on the live environment because production credentials, caching and DNS can expose problems that staging did not.
Watch for unexpected 404s. They often reveal old URLs from bookmarks, printed materials, email campaigns or external links that were not included in the original audit. Add targeted redirects where there is a clear destination, then keep the redirect map under version control or documented with the project.
Search performance may fluctuate temporarily after a substantial migration. That does not automatically mean something is wrong. What matters is whether pages are crawlable, redirects work, content remains relevant and indexing trends in the right direction. Avoid making frantic structural changes every day. Fix clear faults first, then give search engines time to process the new site.
A well-run migration is a practical piece of delivery work: clear scope, careful auditing, tested build, deliberate redirects and active post-launch support. If the site supports leads, revenue or customer access, treat its move with the same care as any other business-critical system. The result should feel uneventful to your customers, which is exactly the point.
