Guide Migrations & Transfers

How to roll back a migration that went wrong

Rolling back is simple if the old hosting is still running, which is exactly why you should never cancel it early.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

If something is clearly wrong after switching DNS to a new server, the correct response is usually simple: point DNS back at the old server, which is exactly why it should never have been cancelled in the first place. A rollback is not a failure of the migration process — it is the process working as intended, because the whole reason to keep the old hosting running for a week is to make this option available if it is needed.

This is only possible if the old hosting is still active

Everything in this guide assumes the old account has not been cancelled yet. If it has already been closed, rolling back is not an option, and you are instead debugging the new server directly with visitors watching — which is precisely the scenario the standard order of operations exists to prevent.

Step 1 — Work out what is actually wrong

Before rolling back, spend a few minutes confirming the problem is genuinely with the new server rather than something else entirely — a browser cache showing a stale page, a single visitor's own network issue, or an unrelated fault that would exist regardless of which server is live. Rolling back for a problem that was never caused by the migration wastes time and delays a fix that was never going to come from switching servers.

Signs that a rollback is the right call:

The site is showing errors, is unreachable, or key functionality (forms, login, checkout) is broken specifically on the new server.
The issue affects multiple visitors, not just your own machine or browser.
You do not have a quick fix and visitors are actively affected right now.

Step 2 — Switch DNS back to the old server

Change the nameservers or the relevant record — usually an A record — back to what they were pointing at before the migration. If you noted the old values before switching, as recommended in any thorough migration checklist, this is a straightforward reversal rather than a guessing exercise.

Do not skip noting the old DNS values before you ever switch in the first place

Before changing DNS during any migration, write down the current nameservers or record values. It costs a minute and is the only thing that makes a fast rollback possible later without contacting the old host to ask what they were.

Step 3 — Expect the same propagation delay in reverse

A rollback spreads at the same speed the original change did, governed by the same TTL. If you lowered the TTL before the original switch, the rollback will also be quick — another reason lowering it in advance is worth doing even on a migration you expect to go smoothly.

Step 4 — Fix the new server properly, without time pressure

With the old site live again, the new server is no longer visitor-facing, which means you can diagnose and fix the actual problem calmly. Common causes worth checking first:

Database credentials in the configuration file not matching what was actually created on the new server.
A missing .htaccess file, which is hidden by default in most FTP clients and easy to leave behind during the copy.
A PHP version mismatch between the old and new hosting, which can surface as errors that did not exist before.
An incomplete database import, particularly for very large databases — see migrating a very large website if size was a factor.

Step 5 — Test thoroughly before trying again

Do not switch DNS a second time until the new server has passed a full test pass while running privately, via a hosts file entry — see testing a migrated site before going live. A second failed switch is far more disruptive to your own confidence and your visitors' experience than taking an extra day to be certain the first time.

What if the old hosting has already been cancelled?

Then rolling back is not available, and the priority shifts to fixing the new server as quickly as possible with the tools you have: your most recent backup, your database export, and whatever logs the new host provides. This is the scenario the standard advice — keep the old hosting running for a week — exists specifically to avoid, and it is worth remembering for next time even if it cannot help this time.

We keep this option open by default

When we handle a migration for you — included free with our hosting plans — we never advise cancelling your old hosting until we are confident the move has fully settled. Get in touch if you would like a migration managed this way from the start.