Pre-Migration Smoke Tests: 11 Checkpoints to Verify on a New Budget VPS Before You Cut DNS

Why the DNS cut is the wrong time to find out

A DNS change propagates unevenly, and reverting takes as long as the original switch. Everything that can be verified on the new box under its temporary hostname should be verified before the record changes, because after the cut every discovery costs live traffic. The eleven checkpoints below take about 90 minutes on a fresh instance and catch the failure modes that account for most budget-VPS migrations gone wrong.

Work through them in order against the IP address directly, using curl --resolve or an /etc/hosts entry rather than the domain. Compare results side by side with the current host from the provider comparison shortlist so a regression is visible immediately rather than a week later.

Checkpoints 1-3: kernel, disk and memory truth

1. Kernel and virtualization. Run uname -r and systemd-detect-virt. Confirm the kernel supports what your stack needs, and note whether you are on KVM or a container. Containers hide sysctl knobs, so test one write such as sysctl -w net.core.somaxconn=2048 before planning any tuning.

2. Disk reality. Compare df -h with the advertised capacity. A 40 GB plan reporting 36 GB usable is normal after filesystem overhead; a 40 GB plan reporting 24 GB means thin provisioning or an image larger than expected. Confirm the filesystem type with lsblk -f and check inode count, which bites on mail and cache-heavy apps.

3. Memory available. Read MemAvailable in /proc/meminfo, not MemTotal, and add swap if the plan lacks it. On a 2 GB box create a 1 GB swapfile with fallocate -l 1G /swapfile and set vm.swappiness=10. Verify that the swap survives reboot before you need it under load.

Checkpoints 4-5: storage throughput and network path

4. I/O sanity. Run fio with a 4K random mix and a 1M sequential write. Thresholds: 4K random write p99 under 12 ms and sequential write above 200 MB/s for the budget tier. Anything slower than 80 MB/s sequential suggests network storage or a shared node with a saturated backend, and database imports will take 10x longer than on the old host.

5. Network path and MTU. Check mtr -rw -c 50 to your main monitoring location and to one user region. Look for a hop with more than 2% loss, and test MTU with ping -M do -s 1472. A path that works only at 1400 MTU will break HTTPS handshakes to some clients and VPN tunnels unexpectedly. Record the baseline RTT so post-cut latency comparisons are measured, not remembered.

Checkpoints 6-7: services and TLS

6. Service start and restart. Enable every unit with systemctl enable --now, reboot, and confirm each one is active without manual intervention. Check that your app binds to 0.0.0.0 or the correct interface rather than 127.0.0.1, and that firewall rules from the old host were transferred with the ports your users actually need.

7. TLS certificate issuance. Request a real certificate from the staging or production ACME endpoint against the temporary hostname, not a self-signed placeholder. Confirm that port 80 is reachable for HTTP-01 and that renewal works with certbot renew --dry-run. Test both the apex domain and the www hostname, plus any subdomain used for API or mail.

Checkpoints 8-9: data integrity and cron

8. Data integrity. Import a recent database dump and compare counts: rows in the five largest tables, checksums of critical files, and the newest record timestamp. A dump that restores without errors can still be three days stale. Verify that file permissions and ownership match, since a silent 403 storm at 2 am after cutover starts here.

9. Scheduled work. List cron and systemd timers with systemctl list-timers --all and crontab -l, then force-run the three jobs that matter most. Confirm timezone with timedatectl, because a host set to UTC while your reports assume local time shifts every daily job by hours. Check mail delivery for cron output too.

Checkpoints 10-11: egress allowance and rollback

10. Bandwidth accounting. Reset your egress counter, serve 5 GB of real traffic, and confirm it matched the provider’s usage panel. A 10% gap is normal; a 40% gap means compressed or pre-compression counting and your included transfer is smaller than advertised. Also confirm the plan’s overage price from the invoice rather than the page.

11. Rollback path. Write down the reverse DNS change, the exact TTL you will use, and the snapshot name of the old host. Keep the old box running for at least 14 days after cutover. Set TTL to 300 seconds 48 hours before the cut, then raise it back afterward, and pre-create the new snapshot so a restore is a two-minute action rather than an hour.

Pass criteria and what to do with failures

The table below pairs each checkpoint with a pass line. Treat a failure on checkpoints 4, 8 or 11 as a hard stop; everything else is fixable without delaying cutover. Fixing a kernel or swappiness setting takes minutes; fixing a storage tier or corrupt dump does not.

Schedule the cut only after a clean sweep

Plan the DNS change for a low-traffic weekday morning rather than a Friday, and keep the old host answering during the transition window. Monitor the new box for 24 hours after the cut with the same checks you ran before it, since the load profile changes once real traffic arrives. Then run the smoke tests again on day seven to catch anything that only fails under sustained traffic.

If a check fails at step four or eight, replace the node rather than tune around it. Providers with local NVMe and transparent transfer accounting are listed in the budget VPS plans reviewed on the main site, and switching before the DNS cut costs an hour instead of a weekend of rollback work.