Measuring a Budget Host’s Migration Downtime Track Record Before You Switch

Every budget host publishes an uptime figure — 99.9%, sometimes 99.99% — and almost none publishes how long a migration or a restore actually takes. The SLA covers the platform staying up, not the hours you spend moving 80 GB of data to another provider because the platform keeps staying up while performing badly enough to leave.

99.9% allows 43 minutes of downtime per month. That figure covers unplanned outages only; scheduled maintenance, planned migrations and “emergency network work” are typically carved out by clauses that exclude anything announced 24 hours in advance. Read the exclusion list before you read the headline number, because the exclusions are where the real risk sits.

The comparison that matters is not uptime percentage but recovery time: how long does the host’s own maintenance and restore process take, measured against what its contract promises. Those two numbers rarely appear on the same page.

Turn the SLA into a number you can measure

Most SLAs offer credit rather than remedy: fall below 99.9% and you get a percentage of the monthly fee, often 10% to 25%, capped at one month. On a $6 plan that is $1.50 for a day-long outage. The credit exists to make the document look reciprocal, not to compensate you. Treat the SLA as a floor for the provider, and your own measured downtime as the real target.

Define the stopwatch before you start it

Migration downtime is not one number. It is the interval between the first lost request and the first correct response from the new host under full production load. Everything between — snapshot, transfer, DNS propagation, certificate issuance, restore verification — counts, and providers routinely quote only the transfer portion because it is the smallest.

• T0: last successful write on the old host
• T1: snapshot or dump completed locally
• T2: data resident on the new disk
• T3: services start, health check passes
• T4: DNS TTL expired, all traffic on new IP
• T5: first verified production write

Record T0 and T5 with timestamps from an external monitor, not from either provider’s console. Console clocks drift and panel events are written in local time. A cheap external check every 60 seconds gives you the honest interval, and it is the only evidence that survives a billing dispute.

Where the hours actually go

On a typical 40 GB disk at 1 GBit/s, a raw image transfer takes about 6 minutes. The same migration on a budget plan with shared I/O often takes 50 to 90 minutes, because the bottleneck is the host’s storage backend rather than the network. Disk throughput, not bandwidth, determines most migration time.

Stage	Fast host	Typical budget host	Slow host
Snapshot 40 GB	4 min	12 min	35 min
Transfer	6 min	15 min	40 min
Boot + services	2 min	5 min	15 min
DNS TTL (300s)	5 min	5 min	5 min
Verify	3 min	8 min	20 min
Total	20 min	45 min	115 min

Test the host with a restore, not a signup

The cheapest way to measure a host’s recovery track record is to ask it to restore something. Take a snapshot the day you sign up, destroy the instance, and restore from backup on the same provider. Time it end to end. If the provider’s restore takes 6 hours on day three, it will take longer on the day you actually need it.

Anything above 2 hours for a 40 GB restore on an entry plan is a warning. Above 6 hours means daily backups are useless for anything with a one-day RPO, because the window between “we know it broke” and “restore finished” is longer than the gap between backups.

Low TTLs buy back real minutes

Drop the DNS TTL on the records you may move from 3600 to 300 at least a day before the migration. That single change removes up to 55 minutes of tail latency, and it costs nothing. Do not go below 60 unless your DNS provider has a generous query allowance, since resolvers will hammer it.

Keep the old instance running for 72 hours after the cutover. Rolling back costs 10 minutes when the old box is warm and several hours when it has already been destroyed — and providers delete terminated instances quickly, sometimes within the hour on prepaid plans.

Backups without a premium plan

Host-side snapshot add-ons on budget plans run $1 to $5 per month for a 40 GB disk, and many include only daily granularity with a 7-day retention window. That is a reasonable price for convenience but a poor sole backup: it lives on the same infrastructure as the thing it protects, and a provider billing failure can lock you out of both.

Run a second copy off-host. A nightly tar | zstd piped to object storage costs roughly $0.02 per GB-month, so 40 GB of compressed archives with 7 daily and 4 weekly versions stays under a dollar. Script it, log the exit code, and alert when the job fails — silent backup failures are the norm, not the exception.

What to ask before switching

Ask for the last 12 months of incident history with durations, the restore time on your disk size, and whether migration assistance is included or billed hourly. A host that answers with numbers in under a day is showing you its operational hygiene. One that sends a link to a status page with no history is showing you the other thing.

Budget hosting is not the problem; unmeasured budget hosting is. Track your own T0-to-T5 on every migration and keep the log. Two moves in, you will have a personal track record that is worth more than any SLA, and you can pick a provider on recovery behaviour rather than on a percentage printed on a pricing page.