Why website migration matters more than most people realise
Moving a website from one hosting provider to another sounds straightforward on the surface. You copy files, move a database, update DNS, and the site appears on a new server. In practice, website migration involves several interconnected systems that must work together after the move. Getting any one of them wrong can cause the site to go offline, break email delivery, or erase months of SEO work in a matter of hours.
For small businesses in the UK, a poorly managed migration can mean lost enquiries, damaged search rankings, and weeks of recovery work. The good news is that most of these problems are preventable with proper preparation. This checklist walks through the technical areas that matter most when migrating a business website, from hosting evaluation through DNS changes, email continuity, SEO protection, and redirect handling.
What makes website migration risky
Website migration is not a single task. It is a sequence of dependent changes that affect your hosting environment, domain configuration, email routing, and search visibility simultaneously. When one part of the process goes wrong, it tends to cascade into others.
Common problems include DNS changes that take longer than expected, causing intermittent site access. Email configuration getting overlooked, leading to lost messages during the transition window. Search engines serving outdated URLs because redirects were not set up correctly. And backups that turn out to be incomplete or corrupted when you actually need them.
The risk is compounded by the fact that many of these issues are not immediately obvious. A site may load for some visitors but not others depending on their ISP and cached DNS records. Email may appear to work but messages may quietly fail to reach their destination. These silent failures can continue for days before someone notices.
Pre-migration preparation
Before touching anything technical, take inventory of the current setup. Write down the current hosting provider, server type, control panel access details, domain registrar, and all services associated with the domain. This includes not just the website but email accounts, any subdomains in use, SSL certificate details, and third-party services that send email from your domain.
Create a full backup of the website. This means all files, the database if one exists, email data if mail is stored on the server, and any configuration files you may have modified. Store this backup somewhere outside the current hosting environment. If the migration causes data loss, an off-server backup is your only recovery option.
Set a clear migration window. During this time, avoid publishing new content, processing transactions, or making significant changes to the site. A quiet period reduces the risk of data divergence between the old and new servers during the transition.
Choosing a new hosting provider
The new hosting environment must be capable of running your website properly. If the site uses WordPress, check that the new server supports the PHP version your theme and plugins require. For custom PHP applications, verify the available PHP modules, MySQL version, and any server-level configuration your application depends on.
Ask the new host about their uptime guarantees, backup policy, and how they handle SSL certificate provisioning. Many UK hosting providers offer managed WordPress plans that handle technical details automatically. If your site uses a custom LAMP stack, a VPS or dedicated server may be more appropriate than shared hosting.
If the site is built on WordPress and you want to avoid rebuilding everything manually, it is worth reading a detailed guide to WordPress migration that covers SEO protection. That article goes further into the specific steps for preserving search rankings during a host change.
DNS migration and what to expect
The Domain Name System connects your domain name to your server's IP address. When you change hosting providers, you update DNS records to point to the new server. The most common record changed during migration is the A record, which maps your domain to an IP address.
DNS changes do not happen instantly. Every DNS record has a Time to Live value, which tells other servers how long to cache that record before checking for an update. Before making DNS changes, reduce the TTL values on your A records and any related records to 300 seconds or lower. This tells the internet to check for updates more frequently. Make this change at least 24 hours before the migration window so that most cached records expire with the old, longer TTL.
After updating DNS, propagation can still take anywhere from a few minutes to 48 hours depending on the ISP, the record's new TTL, and how deeply the old IP is cached in global DNS servers. During this propagation window, some visitors may reach the old server while others reach the new one. This is normal and expected behaviour.
Email configuration during migration
Email is frequently the part of a migration that gets overlooked until messages start going missing. If your business email uses the same domain as your website, the MX records that route incoming mail must remain pointing to your email service provider throughout the transition.
Before migrating, document the current MX records exactly. Common email providers like Google Workspace, Microsoft 365, and third-party SMTP services each have their own MX record configurations. If you are using the current hosting provider's mail servers, switching those MX records prematurely will cause email to bounce or disappear.
A practical approach is to keep MX records pointing to your email service throughout the migration and update them only after the DNS propagation for the website has fully settled. Test email sending and receiving thoroughly before pointing MX records anywhere new.
Verify that the new server can send outbound email properly. Many hosting providers block outbound SMTP on port 25 to reduce spam, which can break your site's ability to send transactional emails, contact form submissions, or newsletter notifications. If your site relies on PHP's mail() function or a custom SMTP configuration, test it after migration to confirm messages are being delivered.
Protecting SEO during a website move
Search engines index your site's URLs. If those URLs change without proper handling, the search engine loses the connection between the old address and your content. The result is lost rankings, missing pages in search results, and reduced organic traffic that can take months to recover.
The primary tool for SEO protection during migration is the 301 redirect. A 301 redirect tells browsers and search engines that a page has moved permanently to a new location. When implemented correctly, most of the ranking signals from the old URL transfer to the new one.
Before making any changes, export a complete list of URLs from your current site. Crawl the site using any accessible tool or request a sitemap from your current host. For WordPress sites, the sitemap is typically available at /wp-sitemap.xml. Map each URL to its new equivalent. If a page has no direct equivalent, redirect it to the nearest relevant page or the site's homepage rather than leaving it to return a 404 error.
Update internal links where possible. After migration, go through the site and update any hardcoded URLs that point to the old domain. This applies to navigation links, image URLs, stylesheet paths, and links within content. Internal links that still point to the old domain will not pass SEO value through redirects and can cause mixed content warnings if you have moved from HTTP to HTTPS.
If the migration includes switching from HTTP to HTTPS, make sure the new hosting environment has a valid SSL certificate installed and configured. Force all traffic to use HTTPS. Search engines treat HTTP and HTTPS versions of the same site as separate entities, and failing to redirect between them can split your search signals across two versions of the site.
Setting up redirects correctly
Redirects are most effective when they are one-to-one. Each old URL redirects to exactly one new URL. Redirect chains, where URL A redirects to URL B which redirects to URL C, dilute ranking signals and add unnecessary latency. If possible, map each old URL directly to its new destination.
On Apache servers, redirects are typically managed through the .htaccess file. A common redirect for an entire domain looks like this:
RewriteEngine On
RewriteCond %{HTTP_HOST} olddomain.co.uk [OR]
RewriteCond %{HTTP_HOST} www.olddomain.co.uk
RewriteRule (.*) https://www.newdomain.co.uk/$1 [R=301,L]For Nginx servers, the equivalent configuration uses a return directive in the server block. Always test redirects after setting them up. Use a browser's developer tools to check that the HTTP status code for redirected URLs shows 301, and verify that the final destination URL is correct.
Keep redirect rules in place permanently. There is a common misconception that redirects can be removed once search engines have reindexed the site. Removing redirects causes any remaining indexed URLs to return 404 errors, which over time removes them from search results. Unless you are confident that every possible URL has been reindexed and updated by search engines, leave the redirects in place indefinitely.
Post-migration verification checklist
Once the site is live on the new server and DNS has propagated, work through a systematic verification process. This is not optional. Problems caught early are much easier to fix than problems that have been live for a week.
- Site loads correctly: Visit the domain from a device that has not accessed it recently, or use an incognito browser window. Check that all pages load, images display, and forms function.
- SSL certificate is valid: Look for the padlock icon in the browser address bar. If the site shows a security warning, the SSL certificate may not be installed correctly on the new server.
- Redirects are working: Test the most important URLs from the old site against your redirect map. Confirm they return a 301 status and land on the correct new page.
- Email is functioning: Send a test message to the domain address and confirm it arrives. Check that any contact forms on the site send emails correctly.
- No mixed content errors: If switching from HTTP to HTTPS, check the browser console for warnings about insecure content being loaded on a secure page.
- External services are updated: If the site uses Google Search Console, Google Analytics, any CDN, or third-party APIs, update the domain references in each service.
Common mistakes that cause problems after migration
Redirecting to the homepage instead of the relevant page is a frequent error. When a page has no direct replacement, it is tempting to redirect everything to the homepage. This confuses visitors and dilutes SEO value by creating redirect loops that point many different URLs to the same destination.
Forgetting to update the site address in the database causes issues on WordPress sites. If the site URL is stored in the database and still references the old domain, assets will fail to load and links will point to the wrong address. Many migration plugins handle this automatically, but it is worth verifying after the move.
Missing file permissions after uploading files to a new server can cause unexpected errors. PHP files that are not readable by the web server will produce errors. Uploaded files that are not writable can break image handling and form submissions.
Not monitoring error logs after migration means silent failures go undetected. Check the server's error log regularly for the first few days after migration. Unexpected errors, missing files, and configuration mismatches often surface there before they become apparent to site visitors.
When to bring in a technical specialist
Some migrations are straightforward. A simple static HTML site moving to a new shared hosting account may require only file transfer and DNS update. But if the site uses a database, custom code, email accounts with stored data, multiple subdomains, or serves significant traffic, the complexity increases considerably.
A technical specialist can handle the full migration sequence, verify each component after the move, and troubleshoot problems that emerge during the transition window. If your business depends on the website for enquiries or sales, the cost of professional help is usually much lower than the cost of extended downtime or lost search rankings.
If you want a practical review of your current setup before deciding whether to migrate, you can get in touch with details of the hosting environment, what the site runs on, and any issues you are currently experiencing.
What matters most when moving a website
A website migration is ultimately a coordination exercise across several technical systems. The parts that receive the least attention, like email configuration and internal link updates, often cause the most disruption after the move. The parts that receive the most attention, like the visual appearance of the site on the new server, rarely cause problems at all.
Taking the time to document the current setup, verify backups, map redirects, and test everything systematically is not the exciting part of a website project. But it is the difference between a migration that goes smoothly and one that costs weeks of recovery work. If the technical steps feel unfamiliar or the site is business-critical, working with someone who has managed migrations before can reduce the risk considerably.