Lower the DNS time to live a week ahead, copy and test the site at the new host before switching anything, then move the domain and keep the old account running for a month.

Where the outage comes from

People assume a migration means the site is down while it moves, in the way a shop is shut while it relocates.

That is not how it works. Both copies exist simultaneously, and the only question is where the domain points.

The outage, where there is one, comes from the gap between changing that pointer and the change taking effect everywhere, during which some visitors reach a server that is no longer serving the site.

That gap is controlled by a setting you can change in advance, which is why a well-planned migration is invisible and a rushed one is not.

Lower the time to live first

The single step that separates the two outcomes, and it has to happen before anything else.

Your domain's records carry a time to live: how long other systems are told to remember the answer before asking again. It is commonly set to hours or a day.

Which means that after you change where the domain points, some visitors continue reaching the old server for that whole period.

Lower it to a few minutes about a week before the move, so that every system caching your records has picked up the shorter value by the time you switch.

Then the cutover propagates in minutes rather than a day, and you can reverse it just as quickly if something is wrong.

Raise it again a week afterwards, once things are settled.

The order that works

The fourth is the one that gets skipped under time pressure, and it is the step that finds the problems while they are still cheap.

Test before the domain moves

You can reach the new copy without pointing the domain at it, which is what makes the whole approach possible.

Most hosts provide a temporary address, and you can also override the lookup on your own machine so that only you see the new server while everybody else sees the old one.

Use that to walk the whole site: every page type, the forms, the checkout, the login, and anything that connects to another system.

Look for the things migrations break: images with hard-coded addresses, database connection settings, file permissions, and anything referring to the old host by name.

Fix them there, while the live site is still serving customers from the old server and nothing is at risk.

The database is what moves twice

The complication that catches people, and it is the same problem as staging.

You copy the site, spend two days testing, and during those two days orders arrive and content is edited on the old server.

Switching the domain then makes the older copy live, and those two days are lost.

The remedy is to copy the database again immediately before the cutover, after any final changes, and to put the site into a read-only or maintenance state for the few minutes that takes if it accepts orders.

For a brochure site with no transactions, this rarely matters. For a shop, it is the whole plan.

A worked example

A business moved hosts and lost about eighteen hours of availability, which they were told was normal.

Their time to live had been set to a day, and nobody had changed it, so the switch propagated slowly and a proportion of visitors reached a server where the account had already been closed.

The second time they moved, four years later, they lowered it to five minutes a week ahead, copied and tested the site over a weekend, and switched on a Tuesday morning.

The cutover took under ten minutes to propagate and nobody outside noticed.

They kept the old account for six weeks, which they used twice to retrieve a file nobody had realised was missing.

The difference between the two migrations was one setting changed a week early.

Do not close the old account

The cheapest insurance in this whole process.

Keep the previous hosting running for a month after the move, paid, untouched.

It costs one month of a small fee and it means that anything discovered missing, and something usually is, can simply be retrieved.

It also means a genuine reversal is possible if the new host turns out to be worse, which is a decision you can only make after a few weeks of real use.

Businesses that cancel immediately to save the month are the ones who find, three weeks later, that a folder of documents was never copied.

Email is the harder half

Worth separating, because it is where migrations actually go wrong for small businesses.

Website files are copied. Mailboxes contain years of mail that has to be transferred, and messages arriving during the switch can land on either server.

Plan it separately: transfer mailboxes before the cutover where the host offers a tool, keep both accessible during the transition, and check for mail that arrived on the old server afterwards.

Where possible, move email to a separate provider entirely rather than tying it to whoever hosts the site, which makes every future migration a website-only job.

That is the change worth making while you are already moving things.

The counter-case

Not every migration needs this much care.

A small brochure site with no transactions, no email on the domain, and a handful of visitors a day can be moved on a quiet afternoon with a short outage that nobody experiences.

Managed platforms also handle much of this internally, and their own migration tools frequently produce a cleaner result than a manual copy.

There is also a risk in over-planning a small move to the point where it never happens, leaving a business on hosting it has outgrown because migration feels daunting.

Scale the plan to what the site does. If it takes money, follow the sequence. If it does not, lower the time to live and get on with it.

The sequence

  1. Lower the time to live a week ahead.
  2. Take your own backup.
  3. Copy and test at the new host first.
  4. Plan email separately.
  5. Re-copy the database immediately before switching.
  6. Switch on a quiet weekday morning.
  7. Keep the old account for a month.

Step one is the difference between an invisible migration and an eighteen-hour one, and it takes two minutes a week beforehand.

Whether to move at all is covered in a server in Toronto for customers in Surrey.

Frequently asked questions

Does migrating mean the site goes offline?

No. Both copies exist at once, and the only question is where the domain points. The outage comes from the gap between changing that and the change taking effect.

What is the single most important step?

Lowering the DNS time to live to a few minutes about a week before the move, so the cutover propagates in minutes rather than a day and can be reversed just as quickly.

How do I test the new server before switching?

Use the host's temporary address, or override the lookup on your own machine so only you see the new server while everybody else still reaches the old one.

What about orders arriving during the migration?

Copy the database again immediately before cutover, and put the site into a maintenance state for the few minutes that takes. For a brochure site it rarely matters.

Should I cancel the old hosting straight away?

No. Keep it running for a month. Something is usually discovered missing, and one month of a small fee is the cheapest insurance in the process.

What is the hardest part?

Email. Mailboxes hold years of mail and messages arriving during the switch can land on either server. Consider moving email to a separate provider while you are at it.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Planning a host move?

Lower the DNS time to live this week, before anything else. That one setting decides whether anybody notices.

Start a Conversation