Migration Backup Seems Stuck — What’s Happening

Seeing your migration sit on the same stage for a while can be worrying, but it’s usually normal — especially for larger accounts. This article explains what’s happening during that wait and how to tell genuine progress from a real problem.

Why the backup stage takes time

Before anything is transferred, your old host has to build a complete backup of your account. For a large account — lots of files, big databases — that takes minutes to tens of minutes. The system deliberately waits for the backup to be genuinely finished before moving on.

How completion is detected

The migration watches the backup file and only proceeds when it has reached a sensible size and stopped growing. This two-part check prevents a half-built backup from being transferred and restored — which would corrupt your site. So a pause here is the system being careful, not failing.

Signs it’s working normally

• The account is large (gigabytes), so a longer wait is expected
• The status is still running with no error
• It hasn’t exceeded the per-account time ceiling

Signs something’s actually wrong

• The status flips to failed with a reason
• It exceeds the time ceiling for the account size
• The old host reports backups are disabled

What to do

For a large account, give it time — it will move on once the backup completes. If it fails or clearly exceeds a reasonable window, note the error and we can raise the time ceiling or investigate the old host. See the ‘source pull failed’ and ‘large account’ articles for specifics.

The backup stage, demystified

Before any data moves, your old host must package your entire account into a single backup archive. For a large account that’s gigabytes of files plus database dumps being compressed into one file — a genuinely time-consuming operation that depends on your old host’s speed and current load. A long wait here reflects the size of the job, not a fault.

How the system avoids restoring a half-built backup

The migration watches the backup file and only proceeds when two conditions are both met: the file has grown past a sensible minimum size for an account that size, and it has stopped growing across consecutive checks. This two-part test is what prevents a still-building archive from being transferred and restored — which would produce a broken site. So the deliberate waiting is a safety feature.

Telling normal from genuinely stuck

Signs it’s working normally

• The account is large, so a longer backup time is expected
• Status is still running with no error flag
• It hasn’t exceeded the per-account time ceiling

Signs of an actual problem

• Status flips to failed with a stated reason
• It exceeds the time ceiling appropriate to the account size
• The old host reports backups are disabled or quota is full

What to do while it builds

For a large account, the right action is usually to wait — it will advance once the backup completes and stabilises. There’s no benefit to cancelling and restarting; that just discards progress and begins the backup again. Let it run.

If it does fail

If the stage ends in a failure, the reason tells you the cause. A timing-related failure on a big account means the time ceiling needs raising — ask us and we’ll extend it, then retry. A ‘backups disabled’ or ‘quota full’ message points at the old host, where the account either can’t create backups or has no room to store one; freeing space or enabling backups on the old side resolves it.

Why patience here is correct, not passive

It can feel wrong to ‘just wait’ when a migration sits on the backup stage, but for a large account, waiting is the right action. The old host is methodically packaging gigabytes of files and database dumps into one archive — a real, time-consuming job. Interrupting it by cancelling and restarting only throws away progress and begins the same long backup again. Letting it finish is both the fastest and the safest course.

The two-part completeness test, explained

The system protects you from a half-built backup with a two-part test: the backup file must grow past a sensible minimum size for an account of that size, and it must stop growing across consecutive checks before being accepted. Only when both are true does the migration proceed to transfer. This is why a backup can’t be grabbed mid-build and restored as a corrupt, partial site — the deliberate waiting is a safety feature working exactly as intended.

Reading the situation correctly

Healthy, in-progress signs

• The account is large, so a longer backup time is expected
• Status remains running with no error flag
• The per-account time ceiling hasn’t been exceeded

Genuine-problem signs

• Status changes to failed with a stated reason
• The time ceiling appropriate to the size is exceeded
• The old host reports backups disabled or disk quota full

Resolving a real failure

If the stage ends in failure, the reason names the cause. A timing-related failure on a large account means the per-account time ceiling needs raising — ask us and we’ll extend it, then retry. A ‘backups disabled’ or ‘quota full’ message points at the old host: the account either can’t create backups or has no room to store one. Freeing disk space or re-enabling backups on the old side clears it, after which a retry succeeds.

The bottom line

For a large account, a long backup stage is the system being careful, not stuck. Give it the time the account’s size warrants. Only treat it as a problem when you see an explicit failure or it clearly exceeds a reasonable window for its size — at which point the error reason tells you precisely what to fix.

What’s next

• Migrating Very Large Accounts
• “Source Pull Failed” — Causes and Fixes
• How Long Does a Migration Take?

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.