Moving Between VPS Tiers Without Losing Traffic: Downtime Budget and Cutover

Moving from a $5 tier to a $15 tier sounds like a five-minute job: copy the files, point DNS at the new IP, done. In practice the copy takes 25 minutes, the DNS change takes effect over four hours for a third of your visitors, and the old box is still serving traffic from stale data while the new one writes to a database nobody is replicating. The migration is not a copy problem, it is a schedule problem.

Plan the downtime budget before you plan the copy. Every migration has four contributors — freeze time, full copy, final delta, and DNS propagation — and they add up in a way that surprises people who only counted the copy. If the total exceeds your acceptable window, you change the design, not the effort. A realistic budget is 30 to 45 minutes for a small site and around two hours for anything with a database over 5 GB.

The downtime contributors, in minutes

Contributor	Typical minutes	Driven by
Pre-freeze warnings and session drain	5–10	Active users, checkout flows
Pre-sync pass (background, no downtime)	0	Runs while old box serves
Write freeze	2–5	How fast you can put the site read-only
Final delta copy	3–15	Data changed since pre-sync
Verification and smoke test	5–10	Checklist length
DNS TTL wait	0–60	TTL value set days earlier
Propagation tail	15–240	Resolver cache, not your control

DNS TTL is the largest single line

Your authoritative TTL controls how long resolvers may cache the old address, but it does not control what they do. A 300-second TTL means most resolvers re-query within five minutes, yet residential ISPs and mobile carriers routinely hold records far longer, and a small percentage of traffic can keep hitting the old IP for four hours or more. That tail is the line item that decides whether your maintenance window is realistic.

Drop the TTL to 300 seconds at least 48 hours before the move — ideally 72, since some resolvers honour the previous TTL for one more cycle. If your current TTL is 86,400 (one day), lowering it on migration day achieves nothing for anyone who already cached the record. The TTL change is the first task, not the last, and it is the cheapest minute you will spend on a budget VPS tier move.

Pre-sync pass versus final delta pass

The pre-sync runs while the old server keeps serving. Copy the bulk of the data — static files, uploads, logs you want to keep — and expect it to take 20 to 60 minutes depending on volume and disk throughput. Nothing is frozen, so users see no impact. This pass is about volume, and it is the only part of the migration that can be done comfortably in advance.

The delta pass runs after the write freeze and should only handle what changed since the pre-sync started. On a quiet site that is tens of megabytes and takes three minutes. On a busy WooCommerce store with 200 orders an hour it can be 500 MB of database and uploads, which takes fifteen minutes. Measuring the change rate over 24 hours tells you, in advance, which of those two cases you are in.

The decision table: is five minutes enough?

A five-minute window is achievable, but only under a narrow set of conditions: no database writes, low traffic, and a hosting setup where you can move the IP address rather than wait for DNS. Anything with user-generated content or orders needs a longer freeze because the delta pass and verification cannot be compressed safely.

Scenario	Freeze needed	Realistic window
Static site, no DB, <1k visits/day	0 min	5 min (DNS only)
WordPress, no e-commerce, <5k/day	3–5 min	15–20 min
WooCommerce, 100+ orders/day	5–10 min	30–45 min
Database >5 GB	10–15 min	45–90 min
Same host, IP re-point available	0–3 min	5–10 min

What breaks if you cut over before propagation completes

Split traffic is the predictable failure. Some visitors reach the new box and see the migrated data; others reach the old box and write orders, comments or uploads that the new server never receives. After you shut down the old box, that traffic turns into 502 errors for anyone still holding the old address — and for a few percent of visitors that lasts hours.

Worse is the write gap. If you freeze the old server, copy the delta, then unfreeze the new one, any writes accepted by the old server in that interval are lost silently. Nothing logs the loss on the new box. The mitigation is to keep the old server read-only but reachable, then compare row counts on the key tables after propagation settles before you retire it.

Rollback criteria you decide in advance

• Roll back if more than 2% of requests are 5xx for 10 minutes after cutover.
• Roll back if the database row count on orders differs from the frozen snapshot.
• Roll back if page response time doubles and stays there after cache warm-up.
• Do not roll back for a single failed plugin or missing image — fix forward.
• Rollback method must be tested: DNS back to the old IP with the old TTL still low.
• Rollback window expires six hours after cutover; after that, fix forward only.

Putting the budget together

For a WordPress site under 5,000 visits a day: TTL lowered 72 hours ahead, pre-sync at midnight, freeze at 01:00, delta and verification until 01:20, DNS switched, propagation tail monitored until 05:00. Total user-visible downtime is roughly 20 minutes for most visitors and up to four hours for the unlucky few hitting stale resolvers. Announce a two-hour window and finish inside it.

Before you start, confirm the new plan’s disk throughput and confirm whether the host can move the IP between tiers — a same-host upgrade that keeps the IP cuts the propagation tail to zero. Budget the copy, the freeze and the tail separately, then compare that total against what your users will tolerate at affordablevpsserver.com. A migration that fits the window is a maintenance note; one that overruns is an outage report.