A website migration starts before anything is moved
A safe migration begins by identifying what the current site depends on. The website files and database are obvious, but the domain can also control email, verification records and third-party services. Analytics, Search Console verification, SSL, scheduled tasks, forms and payment integrations may depend on configuration that is easy to miss if the job is approached as a file transfer.
Our website migration service costs £399. It covers a complete pre-migration backup, DNS cutover, a 301 redirect map where URLs change, SSL and email reconfiguration, testing of key pages after the move and 14 days of aftercare.
The exact migration method depends on what is changing. Moving only the hosting infrastructure is different from changing the domain name or replacing the platform. Keeping that distinction clear reduces unnecessary changes and makes faults easier to isolate.
Moving a website to a new host
When the public URLs are staying the same, the main task is moving the site's infrastructure while keeping the domain pointed at the live environment until the replacement is ready.
Google Search Central recommends preparing and testing the new hosting environment before the DNS switch. After the change, traffic and crawling should be monitored on both old and new infrastructure, and the old hosting should not be shut down until traffic has moved away from it.
DNS timing matters. Records can be cached according to their Time to Live value, so different users may briefly reach different servers while a change propagates. Google recommends considering a lower TTL before the move when appropriate. That is one reason the old and new environments need to coexist during cutover rather than cancelling the original account first.
If you are changing host because you want us to manage the replacement environment, see Managed WordPress Hosting. If the current host is suitable but needs technical management, Hosting Support may avoid a migration altogether.
Protecting SEO when URLs change
A domain change, platform rebuild or URL restructuring adds another layer because search engines need to understand where each old page has moved.
Google recommends creating a mapping between old and new URLs and using server-side permanent redirects such as 301 or 308 redirects where possible. Redirecting every old page to the home page is not a substitute for mapping equivalent content and can be treated as a soft 404 when the destination is irrelevant.
We include a 301 redirect map in migrations where URLs change. Internal links, canonical URLs and XML sitemaps also need to reflect the new structure. For a domain move, Search Console configuration may need updating as well.
Google states that permanent redirects do not themselves cause a loss of PageRank, but it also warns that significant site moves can produce temporary ranking fluctuations while pages are recrawled and reindexed. For that reason, our migration process is designed to protect existing search signals, but we do not describe a domain or URL migration as a guarantee that rankings will never fluctuate.
A separate SEO audit can help when a migration is part of a larger restructure rather than a like-for-like technical move.
What we test before and after cutover
A migration is not complete because the home page loads. Testing needs to cover the parts of the site that users and search engines actually rely on.
- Pages and assets: key templates, images, CSS and JavaScript should load from the intended production URLs.
- Forms and transactional functions: contact forms, logins and other important interactions should still work in the new environment.
- HTTPS: the certificate and redirects should produce the intended secure URLs without mixed-content problems.
- Redirects: old URLs should return the correct permanent redirect and lead directly to the relevant replacement page.
- Email configuration: DNS changes must preserve the records used by the organisation's mail service where those records are within the migration scope.
- Crawling and indexing controls: temporary staging restrictions such as noindex directives must not accidentally remain on the live site.
That last point is particularly important. Google explicitly warns site owners to remove temporary crawling or indexing blocks when a new hosting environment goes live. A technically successful move can still create a search problem if production pages remain marked as staging content.
Backups, DNS and the cutover
We take a full pre-migration backup before changing the live environment. That gives the move a defined recovery point rather than relying on the old hosting account continuing to behave as expected.
The National Cyber Security Centre recommends keeping backups of data organisations need to operate and knowing how that data can be restored. For a website migration, the relevant backup normally needs to include the site data and configuration required to reconstruct the application.
The DNS cutover is then made only after the destination has been prepared. SSL is configured, email-related records are accounted for and the new site is checked again after public traffic begins reaching it. If URLs have changed, the redirect map is tested against the live responses rather than assumed to work because the configuration file was accepted.
We include 14 days of aftercare so issues associated with the move can be addressed after cutover. The complete migration service is £399.
Host migration, domain migration and platform migration
The word migration covers several different jobs. A host migration can keep every public URL identical while replacing the server beneath the site. A domain migration changes the hostname and requires search engines and users to be directed from the old address to the new one. A platform migration can also change URL paths, templates, application behaviour and server requirements.
Combining unrelated changes increases the number of possible causes when something goes wrong. Google advises changing one major thing at a time where practical, such as moving domain and redesigning the site as separate changes rather than combining them unnecessarily.
That principle is useful beyond SEO. If a site has been redesigned, moved between platforms, changed domain and switched hosting simultaneously, an error in checkout or email can be much harder to trace. A controlled migration preserves as many known-good components as possible while the infrastructure change is verified.
For an existing WordPress site that only needs a better-managed hosting environment, see Managed WordPress Hosting. For a broken site that needs attention without a planned migration, see Emergency Website Fix.