How to Move a Website to a New Host: A Cheap VPS Checklist
How to move a website to a new host with a cheap VPS: verify a recoverable backup, test the new copy, plan DNS, and keep a rollback route.
Quick answer
To move a website to a new host, first confirm a recoverable backup, test the copied site on the new VPS, and keep the current host live until the new version passes your checks. Keep the current host live while you validate the new one. Do not treat a low monthly price or a successful file copy as proof that the site is ready to switch.
A migration is a sequence of gates
Use this checklist to compare a cheap VPS against the real work of moving a site. It is a planning method, not a promise of zero downtime: DNS caches, application behavior, mail routing, and provider tooling vary. For a WordPress site, the official Learn WordPress backup lesson says a complete backup includes both the site files and its database. A cPanel transfer has its own DNS and account-transfer behavior, so confirm the exact steps for your control panel and host.
| Gate | Evidence before you proceed | Stop if |
|---|---|---|
| 1. Inventory | List the site software and versions, files, database, scheduled jobs, mail, DNS records, certificates, and any external services. | You cannot identify where a required service or data set lives. |
| 2. Recoverability | Save a restorable copy of files and database outside the VPS you are replacing; record how you would restore them. | The backup is incomplete or has not been checked. |
| 3. Destination fit | Confirm the cheap VPS supports the needed OS, runtime, storage, network access, and management tasks. | A required feature, port, license, or support task is unclear. |
| 4. Private test | Load the copied site on a staging hostname or local test route before changing public DNS. | Core pages, forms, logins, uploads, scheduled work, or database writes fail. |
| 5. Cutover | Know which DNS records will change, what the old record TTL is, and who can restore the previous values. | You have no access to the DNS zone or do not know which records serve the site and mail. |
| 6. Acceptance | Check the public site, HTTPS, redirects, forms, important data, and monitoring after the switch. | Errors or missing data appear and the cause is not understood. |
Before copying: map the whole service
Write down more than the document root. Include the database, uploads, environment settings, scheduled jobs, email accounts or external mail provider, DNS records, certificates, and any integration that depends on the old server address. Mark each item as “copy,” “reconfigure,” or “not used.” This inventory is original planning guidance: it turns a vague migration into a list you can verify against the provider’s published plan and support scope.
For WordPress, do not count a files-only archive as a full site backup. Learn WordPress identifies both physical files and the database as parts that need to be backed up. Keep the copy somewhere separate from the VPS so a failed destination does not also take out the only recovery copy.
Build the destination while the old site still serves visitors
Set up the operating system and application stack on the new VPS, then transfer a copy of the site. Test with a temporary hostname, a hosts-file override, or the staging method supported by your stack. Do not put private credentials into a public test page. Compare representative pages and workflows with the current site: homepage, a deep URL, login, search, a form, an upload, and any checkout or write operation that applies.
If the site accepts writes, decide how you will handle changes made during the move. You may need a brief content freeze or a final database sync. Choose the method before the DNS change; otherwise, the old and new copies can diverge. This is a decision point, not a universal migration command.
Plan DNS as a separate step
List the exact records used for web traffic and keep mail records separate. A website move usually concerns the web address records; changing nameservers or mail-related records can affect other services. cPanel’s Transfer Tool documentation describes cases where its Live Transfer updates A records, nameservers, and mail routing, and warns that some DNS data may need manual handling. Those details apply to that cPanel feature, not automatically to every cheap VPS migration.
Check the existing TTL before scheduling a switch. Cloudflare’s DNS FAQ says its zone changes take effect globally within five minutes by default, while old answers can remain cached until the previous record TTL expires. That is Cloudflare’s documented behavior; other resolvers and provider setups may differ. Do not promise a fixed cutover time based on that number.
Use a rollback card
Before changing DNS, write this down where the operator can reach it:
- Previous values: copy the current web-related DNS record names, types, and values.
- New values: record the destination values you intend to publish.
- Checks: name the pages and actions that must work on the new host.
- Rollback trigger: define observable failures, such as repeated server errors, broken sign-in, failed writes, or missing content.
- Rollback action: restore the prior web-record values and keep both hosts available while caches expire and you investigate.
- Data rule: if visitors can submit changes, decide how to preserve writes made during the transition before switching back.
A DNS rollback does not undo data written on the new server, and cached DNS answers can mean different visitors reach different hosts for a while. Keep the old service and its data intact until the new host passes your acceptance checks and you have a plan for any writes made during the transition.
Compare the cheap VPS offer against the migration gates
Use the plan page and the provider’s written support terms to answer these questions before paying:
- Can you install and maintain the software versions your site needs?
- Are the required storage, network access, and database setup available in the selected plan?
- Does “managed” support include migration, or only specific server issues? Get the scope in writing.
- Can you keep the old host active during testing and DNS transition, and what would that overlap cost?
- Can you upgrade resources if measured usage shows a limit, and what steps or downtime does that require?
These questions form a migration-specific buying check: the cheap VPS must cover both the destination requirements and the time needed to prove the move. If the provider’s answer is missing, treat that item as unresolved instead of assuming it is included.
Go live only when the evidence is ready
Switch DNS after the private test passes, a recoverable backup exists, outstanding writes have a plan, and you can restore the prior records. Then check the public site from more than one network if possible, confirm HTTPS and key workflows, and watch application logs for errors. Keep the old host available until the new copy is accepted and you understand how to handle any data created during the cutover.
A cheap VPS can be a workable destination, but migration readiness is proved by these checks—not by the plan name or headline price.