Website Migration Checklist

Four moves that get treated as one

What makes a migration go badly is that "moving hosts" hides four separate jobs, none of which happens on its own. Where to move to is on the web hosting guide. This page is the move itself.

The four parts, and what a forgotten one looks like
The move	What it is	When it is missed
Files	Pages, images, themes and plugins	Obvious. The site is missing or broken
Database	Content, settings, users and orders	An install screen, an error, or a site that works only because it still reads the old server
Email	The mailboxes, wherever they genuinely live	Mail stops arriving and nobody gets a bounce
DNS	Where the site and mail are. This is the switch	Either nothing changes, or everything changes at once

Decide which are in play first. A brochure site has no database, and mailboxes at Microsoft 365 stay where they are. When mail is moving, email migration covers it. New to DNS? Read DNS management first.

Pre-flight, days before the move

All of this happens while the site still works and nobody is waiting on you.

A backup you have actually restored

Download the files, export the database, then open what you got: a truncated export looks the same as a good one in a listing. Until you have seen it come back, you have a download, not a backup. See website backups.

An inventory of what is on the domain

Subdomains: a blog, a shop, a staging copy, something an agency set up.
Anything the server runs on a timer.
Redirects, usually in a configuration file rather than anywhere visible.
Forms, which send through the server's own mail system.
Verification records in your DNS, and the certificate and the names it covers.

Where the email really lives

Answer this before touching a record. Look up the domain's MX records: they name the server that accepts mail. If they point at your current host, the mailboxes are on the machine you are leaving and email is part of the move.

A lower DNS time-to-live

Lower the value on the records you are about to change, the bare domain and the www one, and leave the mail records alone (DNS management explains what the value means). The catch is that the reduction itself travels at the old value: a record currently remembered for a day has to be lowered more than a day ahead, or it buys you nothing. Put the original value back once the new site has been live and quiet.

Save every DNS record as text, SPF, DKIM and DMARC included. That is your undo button. Check now that you can log in to the registrar, the old host and wherever the DNS lives.

The two rules

Keep the old service running until the new one is proven

The old host stays paid and untouched until the new site has been live and quiet for a week. One extra billing period buys you a one-record undo.

Never move hosting and transfer the domain in the same session

A transfer changes who controls the records and can leave you unable to edit DNS halfway through. Move the hosting, let it settle, then do the domain transfer.

The website migration checklist, in order

Set up the new hosting and point nothing at it

The new server exists and the internet has no idea.
Copy the files

All of them, including the hidden configuration files carrying your redirects.
Move the database and reconnect it

Import the export, then point the site's configuration file at the new database. The dangerous version of this mistake still works: if the file names the old server, the site looks perfect until you cancel.
Rebuild the surroundings

PHP version, scheduled jobs, redirects, permissions. None of it travels with the files.
Plan the certificate for straight after the switch

Many hosts will not issue the certificate until the domain points at them, so expect to request it straight after the switch rather than before. See SSL certificates.
Test the new site properly

Covered below. Do not rush it.
Freeze the old site

Anything written to the old server from here is stranded.
Change only the records pointing at the web server

The bare domain and the www one. Leave mail and verification records alone.
Verify, then wait

Both checklists are below.

Changing the web records is where nameservers deserve a warning. Handing the whole zone to the new host is quicker, and it is how mail gets lost: the receiving host builds a default zone with its own mail records. If you must, recreate every record from your saved copy first.

Proving the new site before anyone can see it

Your host's temporary address is fine for a glance, but a site behaves differently under its own name. The better test is your machine's hosts file: only your computer treats the new server as real. Then click:

One page of every kind: home, an interior page, a news post, a product page, the checkout. Unstyled pages or missing images mean a path has gone.
Every form, and confirm the message arrives, spam folder included. Forms send through the server, so a form that silently stops is the commonest complaint after a move.
The admin login, one edit saved and reloaded, and a few deep URLs including one that used to redirect.
The error log. Read it rather than assuming it is empty.

The cutover, and the window where both servers are live

During the overlap both servers answer, so nothing goes dark. The danger is data, not downtime: an order landing on the old server stays in a database you are about to abandon.

How to freeze the old site

Freezing means nothing is written to the old server between your final export and the moment the last visitor moves across.

Name a quiet hour and tell whoever posts, sells or takes bookings that the old site is read-only from then on.
Stop the old site taking money: maintenance mode, or the payment method switched off, so a checkout cannot complete on the machine you are leaving.
Export the database again after the freeze, not before it, and import that copy. Anything written between the two exports is otherwise gone.
If you cannot freeze at all, switch at your quietest hour and reconcile afterwards: compare the old admin and inbox against the new site before you cancel.

Verify immediately after the switch

Work through this the moment the new server answers, then again later that day:

The site loads with and without the www prefix, and one redirects to the other.
The connection is secure with no warning, and the certificate covers both versions of the name.
No mixed content: a secure page pulling an image over an insecure connection gets flagged.
Forms send and arrive, and mail works both ways: one in from an outside account, one out.
Deep pages load, not only the homepage, and an old redirect still redirects.
A made-up URL gives your own 404 page, and logins work.

If something is wrong and you cannot fix it in a few minutes, put the old address record back. That is why the old host stays paid.

Cancelling the old host, a week later

Take a final full backup of the old account before you close anything, files and database both, and keep it somewhere that is neither hosting account. Many hosts delete everything the moment an account closes, so whatever you saved by then is all you get.

Cancel the hosting only. Your domain registration is a separate line item, and cancelling the wrong one is how people lose the name. Domain expiration explains what happens then.

Two ways this goes wrong

These account for most of the calls we get after somebody else's migration.

Email vanished because the mail records were replaced wholesale

The nameservers were switched, the new host generated its own mail records, and mail now lands in a mailbox nobody has opened. Senders get no bounce, so it surfaces when a customer asks why you never replied.

The site half moved because the database was forgotten

The files copy easily, so the site appears, with stale content or an install wizard. The expensive version is subtler: it works beautifully, on the old server's database.

If you would rather not do this yourself

If you are moving because the site is slow, read the hosting guide before you buy anything. A faster server does not fix a slow site. Otherwise, AldoMedia has been building and maintaining websites for Western New York businesses since 1999. We are an independent authorised reseller, not the operator of the platform. What we add is the sequencing and the testing. Ring 716-771-2536 or tell us what you are moving.

Move My Site to AldoMedia Read the support pages

Common questions

Website migration questions

How long does a website migration take?

The copying is the short part, often a single session. The calendar is longer: you lower the DNS time-to-live a day or two ahead, then leave the old host running a week afterwards.

A customer ordered on the old server during the cutover. Where is it?

In the old site's database, and nothing forwards it to the new one. Before you cancel the old account, open its admin and copy across anything that arrived after the switch: orders, form messages, comments, new accounts.

Do I have to move my email when I move my website?

Only if the mailboxes sit on the account you are leaving. Check the domain's MX records. If they point at the old host, mail is part of the move. If they point at Microsoft or Google, leave those records alone.

Can I transfer my domain to a new registrar at the same time?

You can, and it is the easiest way to turn a routine move into a bad week. A transfer takes days and can leave you unable to edit DNS midway. Move the hosting first, prove it, then transfer.

How do I know the migration worked before I cancel the old host?

Give it a week of ordinary use, not a day. A week covers what only runs on a schedule: a Monday newsletter, a weekend booking, a month-end job. Then back up the old account and cancel.

Related guides and services

Web Hosting

Where you are moving to, and whether the plan or the site made things slow.

Read the hosting guide

DNS Management

The records this checklist depends on, and what each does before you edit it.

About DNS management

Email Migration

For when the mailboxes are moving too, and why that needs its own day.

About email migration

Also useful: shared hosting and WordPress hosting, or all of the guides.