Website Migration Steps You Shouldn’t Miss: The Complete Checklist

Taking the right steps during a website migration can help you avoid downtime, broken pages, or losing your search rankings. Website migration might mean changing your hosting provider, moving to a new domain, switching CMS platforms, or updating your URLs.

Each type of migration comes with its own risks. Moving to a new host usually means transferring files, databases, email, and DNS. Changing your domain or URLs also requires setting up redirects, updating canonical tags, and doing extra SEO work.

The guide covers all website migration steps and processes, starting with backups and staging and ending with the DNS switch-over and the checks carried out after the launch. It also explains how to migrate a website without losing your SEO ranking or leaving visitors stranded on the old server.

What Is Website Migration?

Website migration means moving or making big changes to your website’s hosting, domain, platform, URL structure, or technical setup. The main goal is to move your site while keeping its content, features, traffic, search rankings, and user experience safe. Not every migration involves the same work. Moving hosts with unchanged URLs is much simpler than changing domains and platforms together.

Types of Website Migration Explained

A hosting migration moves the website to another server or provider. Domain migration changes its primary web address.

Platform migration moves the site between systems such as different CMS platforms. Structural migrations alter URLs or information architecture. Some projects combine several changes, which increases testing and SEO requirements.

If hosting resources are the problem, compare current VPS hosting plans before planning the move.

 

Pre-Migration Checklist: What to Prepare

Don’t start by copying files right away. First, make a record of your current site so you know exactly what needs to be moved.

Take a Full Website Backup

Create independent copies of the website files and database before making server changes.

For a Linux-hosted site, you can archive the document root and export a MySQL or MariaDB database:

tar -czvf website-backup.tar.gz /var/www/html

 

mysqldump -u user -p db_name > database-backup.sql

Keep at least one copy outside both the old and new production servers.

Inventory URLs, DNS, Email, and Configuration

Record everything your current environment depends on before migration.

Include:

• DNS records

• SSL configuration

• PHP version

• Database version

• Cron jobs

• Mailboxes

• Redirects

• Environment variables

• SMTP settings

• Third-party integrations

• API allowlists

• Current sitemap

• Important URLs

Don’t assume your email will move automatically with your website. You may need to move mailboxes, MX records, SPF, DKIM, and other email settings separately.

Choose the New Hosting Environment

When selecting your new server, take into account what your website currently needs and the extent of its expected growth. You should check the support for the CPU, RAM, storage, bandwidth, the operating system, database compatibility, backup options, and the requirements for the control panel. 

A site outgrowing shared hosting may fit well on VPS infrastructure, while consistently resource-heavy websites may benefit from dedicated server hosting.

Create a Staging Environment

Plan how you’ll test the new environment before you change your public DNS. You can use a staging hostname or map the real production domain to the new server through your local hosts file. Make a list of everything you need to test, like forms, logins, search, payments, images, redirects, APIs, and database updates.

Record Your SEO Baseline

If you’re changing your URLs or domain, write down your current SEO stats before you begin.

Export:

• Organic traffic

• Indexed pages

• Top landing pages

• Rankings

• XML sitemaps

• Canonical URLs

• Important backlinks

• Search Console coverage data

This gives you a starting point to spot any problems after you launch.

Website Migration Steps: The Complete Process

Step 1: Build the New Server Before Touching Production

Set up the new environment while your old website is still live. Install the required web server, runtime, database software, extensions, control panel, security tools, and application dependencies. Configure storage and permissions before transferring production data. HostSailor’s guide to migrating from shared to VPS hosting also recommends matching software versions before the cutover.

Step 2: Transfer the Website Files

For Linux-to-Linux migrations, rsync is usually preferable because it can efficiently repeat transfers and preserve file metadata.

rsync -avz -e ssh /var/www/html/ user@new-server:/var/www/html/

You can also use scp for a simpler copy:

scp -r /var/www/html/ user@new-server:/var/www/html/

When setting up a dynamic website, carry out the first transfer early and carry out another synchronization close to the cutover.

Step 3: Export and Import the Database

Export the database from the old server:

mysqldump -u user -p db_name > database-backup.sql

Copy the dump to the new server, then import it:

mysql -u user -p db_name < database-backup.sql

Afterward, check the number of tables, app connections, character encoding, and database users. For large or busy sites, you might need a short maintenance window or a replication plan to make sure new data doesn’t get split between the old and new servers.

Step 4: Update Configuration Files and Environment Variables

Make sure that the application settings which refer to the old server are checked.

This may include:

• Database hostnames and credentials

• .env files

• WordPress wp-config.php

• Cache paths

• Upload directories

• API allowlists

• Cron jobs

• SMTP details

• Absolute URLs

• File permissions

Make sure that you don't substitute the secrets of your live server with those from your test environment without first checking.

Step 5: Test the New Server Before DNS Cutover

On your computer, direct your website's domain to the new server's IP address.

For Linux or macOS:

sudo nano /etc/hosts

Add a temporary line such as:

203.0.113.10 example.com www.example.com

Now your own browser can load the new server while everyone else continues using the old one.

Test:

• Homepage and navigation

• Login and logout

• Forms

• Search

• Checkout

• Images

• Downloads

• Database writes

• Email notifications

• API integrations

• Redirects

• Scheduled jobs

Don’t move forward until the new environment works just like your live site.

Step 6: Perform the Final Synchronization

If visitors can create content, place orders, upload files, or otherwise change data, new information may appear after your first transfer. Run a final file synchronization shortly before cutover.

For dynamic databases, choose a brief content freeze, maintenance window, or replication strategy appropriate to the application. The goal is to ensure the new environment contains every important change before traffic moves.

Step 7: Switch DNS and Keep the Old Server Running

Update the required A, AAAA, or other DNS records to point to the new infrastructure. Google describes the DNS change as the actual start of a hosting move when URLs remain unchanged. It recommends monitoring both old and new server traffic before shutting the original environment down. Don’t cancel your old hosting right away.

Going Live: DNS, SSL, and SEO Cutover

Lower DNS TTL Before the Move

TTL controls how long recursive DNS resolvers may cache a DNS answer. Lower the TTL before you migrate, if your DNS provider lets you. With a shorter TTL, DNS servers will pick up the new record faster after you switch. Do this well before you launch. Lowering the TTL right before changing the IP won’t clear out records that are already cached.

Update DNS and Monitor the Change

After changing DNS, verify which IP address is being returned:

dig example.com

 

dig @1.1.1.1 example.com

You can also inspect the authoritative DNS chain:

dig example.com +trace

Keep an eye on the logs for both servers. As cached DNS records expire, more requests will start going to the new server.

Reissue or Install the SSL Certificate

The HTTPS certificate must work correctly on the new server before the migration is complete.

If you use Let’s Encrypt with Nginx:

sudo certbot --nginx -d example.com -d www.example.com

If you are already using a commercial certificate, then securely migrate its certificate chain and private key. HostSailor also provides SSL certificate options.

Add 301 Redirects Only When URLs Change

A migration that involves only hosting and which keeps the existing URLs does not require site-wide redirects. When your domain or URL structure changes, set up a direct mapping from the old pages to the new ones and use permanent 301 or 308 redirects.

Do not send each removed URL to the homepage; instead, each redirect should be directed to the nearest relevant replacement when one is available.

Check Canonicals, Robots, and Noindex Rules

You do not need a new robots.txt simply because the website changed servers.

Rather, make sure that any restrictions from your test site have by accident been carried over to your live site.

Check for:

• Temporary noindex tags

• Blocked robots rules

• Incorrect canonical URLs

• Old internal links

• Old hreflang URLs

• Outdated sitemap URLs

These checks are especially important if you’re changing your domain or URL structure.

Post-Migration Checklist: Confirm Everything Works

Test Pages, Forms, and HTTP Status Codes

Go through your site both as a regular user and as an admin.

Test:

• Navigation

• Login and logout

• Forms

• Payments

• Search

• Images

• Downloads

• Email notifications

• API integrations

• Scheduled jobs

Check important responses directly:

curl -I https://example.com

Look for unexpected 404, 500, redirect loops, or mixed HTTP/HTTPS behavior.

Monitor Search Console and SEO Performance

If URLs changed, create an XML sitemap containing the final URLs and submit it through Google Search Console. Do not use Google's old sitemap ping endpoint. It has been deprecated.

Monitor:

• Indexed pages

• Organic impressions

• Organic clicks

• Crawl errors

• Redirect errors

• Canonical selection

• Top landing pages

• Server logs

Compare results against the baseline recorded before migration. It’s normal for your rankings to change temporarily after big domain or URL changes while search engines adjust to the new setup.

Complete Basic Server Hardening

Before considering the migration finished, patch the new server and remove unnecessary services. Review SSH access, backups, firewall rules, monitoring, and exposed ports. If you manage the server directly, HostSailor’s guide to configure firewall rules provides a useful starting point.

Keep this step focused on making the new environment production-ready rather than turning the migration into a full security project.

Common Website Migration Mistakes to Avoid

Changing Too Many Things at Once

The difficulty in troubleshooting is increased when host moves, domain changes, the CMS is replaced, the site is redesigned, and the URLs are rewritten at the same time. Google recommends separating major changes where practical. If something goes wrong, you need to know which change caused it.

Transferring the Domain When You Only Need New DNS

Changing hosting providers does not require transferring your domain registration. You can leave the domain with the same registrar and simply change the DNS records that point to your website. A domain transfer is a separate process and should only be done when you actually want to change registrars.

Forgetting Email During the Migration

A website can work perfectly after migration while email stops completely.

If the previous host also handles email, check:

• MX records

• SPF

• DKIM

• DMARC

• Mailboxes

• Aliases

• SMTP credentials

If necessary, treat the migration of your email as a separate step.

Shutting Down the Old Server Too Early

This is one of the easiest ways to create avoidable downtime. DNS caches do not all refresh simultaneously. Some visitors may continue reaching the old IP while others already use the new one. Keep your old hosting active until your logs show that most traffic has stopped going to it.

Forgetting a Rollback Plan

Know how you will reverse the migration before changing anything public.

Keep:

• The old server

• Original DNS values

• Current database backups

• File backups

• Previous configuration

• A clear rollback trigger

If something critical goes wrong, you should be able to restore your site without scrambling to figure it out on the spot.

The Bottom Line

A successful website migration follows a simple order: document your current setup, build and test the new server, move your data, and only switch traffic when everything is working. Keep your old server running during the DNS switch. If you change URLs, set up redirects carefully and keep an eye on Search Console after the move.

The safest migration is also one you can reverse. Keep verified backups and document your original DNS configuration before launch. If you would rather have help planning the hosting side, HostSailor’s team can help you choose the right VPS environment and prepare for the move.

Frequently Asked Questions About Website Migration Steps

How long does a typical website migration take?

A small hosting migration can take several hours once the destination is prepared. Complex sites may require days or weeks of planning and testing. Search engines can take longer to fully process migrations that introduce new URLs or domains.

Will migrating my website hurt my SEO rankings?

Not necessarily. A hosting migration with unchanged URLs should have limited search impact if the new server remains accessible and performs correctly. URL-changing migrations may produce temporary fluctuations while search engines recrawl and process redirects. Google recommends careful URL mapping and permanent redirects.

Do I need to migrate my email accounts separately?

Sometimes. If email is hosted by the same provider as your website, mailboxes and settings may need a separate transfer. Check MX records, mailbox data, aliases, SPF, DKIM, and SMTP details before cancelling the original hosting service.

Can I migrate a website myself without hiring a developer?

So, provided that you are willing to take on the responsibility of hosting panels, DNS, files, databases, SSL, and some basic troubleshooting. Migrations involving Managed WordPress or cPanel would be simpler. Complex e-commerce sites, those with high traffic, or custom applications generally call for experienced technical support.

How much does a professional website migration cost?

There is no universal migration price. Cost depends on website size, databases, email accounts, platform complexity, URL changes, server configuration, required downtime, and whether SEO monitoring is included. A simple hosting transfer costs far less than a full domain and CMS migration.