VPS Buying Guides
Move WordPress from Shared Hosting to a VPS: Migration Checklist
Move WordPress to a VPS by preparing and testing the destination before switching traffic, then controlling writes during the final data copy. The difficult part is keeping the database, uploads, scheduled jobs, and incoming requests consistent—not merely copying a folder. A careful migration can reduce disruption, but no generic checklist can promise zero downtime.
This workflow assumes your public domain stays the same. It is a migration plan rather than a universal installer: hosting permissions, database tools, and plugin behavior vary. Keep access to both hosts and retain a verified backup until the new site has passed acceptance checks.
1. Inventory what must move
- WordPress files, themes, plugins, uploads, and database.
- PHP version and extensions required by the site.
- Web-server rules, redirects, scheduled jobs, and cache settings.
- Email delivery, contact forms, payment callbacks, and other integrations.
- DNS records for the website and any separate mail or verification services.
Do not assume mailboxes move with WordPress. Changing a website address record is different from changing nameservers, and an unnecessary nameserver switch can affect unrelated services. Record the existing configuration and decide exactly which records the website cutover requires.
2. Select a destination with operational headroom
Budget RAM for PHP, the database, and the operating system, then reserve capacity for backups and maintenance. Allocate disk space for uploads, logs, temporary exports, and growth. Our WordPress VPS RAM guide offers a starting framework. Compare the network from your main audience before deciding between regions.
Prepare the destination OS, firewall, HTTPS configuration, and application stack. Verify an administrator login and console recovery path. If you need a baseline, use the Ubuntu security guide. Clarify who maintains the stack after migration; a VPS does not automatically include WordPress administration.
3. Rehearse the restore before changing public DNS
Make a consistent database export and a copy of the required files. Restore them into the destination and check permissions and configuration. The WordPress migration handbook explains configuration and URL considerations. If a temporary domain is used, avoid blind text replacement in serialized database values; use a WordPress-aware migration method.
For a same-domain move, a local hosts-file override or an HTTP client’s address override can test the destination while preserving the hostname. For example, replace the example domain and documentation IP below with your real values:
curl --resolve example.com:443:203.0.113.10 \
-I https://example.com/This checks the destination’s HTTPS response for the chosen hostname. It does not validate the whole application. The destination needs a valid certificate for that domain; arrange certificate issuance before cutover, for example through DNS validation where supported. Do not bypass certificate errors as a substitute for fixing them.
4. Test the actions that matter
- Open the homepage, several older posts, and an image-heavy page.
- Check permalinks, redirects, search, and administrator access.
- Submit a controlled test form and verify delivery.
- Test commerce or membership functions in their sandbox modes.
- Confirm scheduled jobs will run on only the intended active site.
- Check that the test environment will not send duplicate emails or production webhooks.
A successful homepage request is not enough. Record the result of each test so you can repeat the same checks after traffic moves. Protect any public staging copy from unauthorized access and search indexing.
5. Plan the final sync and DNS cutover
If you lower a DNS TTL, do it far enough in advance for the previous TTL to expire from caches. Lowering it at cutover does not instantly remove previously cached answers. Proxied records can behave differently; consult your DNS provider’s settings and the Cloudflare TTL reference if applicable.
For a site receiving comments, orders, or uploads, define a short write-freeze window or an application-specific replication plan. Take the final export and file delta after writes stop, restore them, then change only the required website records. Review both A and AAAA records: an old IPv6 destination can leave some visitors reaching the wrong server.
6. Keep a data-aware rollback plan
Monitor both hosts during the transition. Some visitors may still reach the old destination. Keep it in a state that cannot accept conflicting writes. If the new site has already accepted orders or uploads, simply pointing DNS back can lose those changes. A rollback must account for new data before traffic returns to the old application.
Repeat the acceptance checks through public DNS, inspect logs, and verify backups on the VPS. Remove migration archives from public web directories. Retire the old hosting only after traffic and integrations have settled and your recovery copy has been verified.
Migration FAQ
Can I cancel the old host immediately?
Keep it available through the validation period. DNS caches, missed integrations, and rollback needs can outlast the initial switch.
Will a VPS make every WordPress site faster?
No. It gives you control over resources and configuration; inefficient plugins, queries, or external services still need attention.
Prepare your next WordPress host
Compare current TudCloud plans and choose a region, memory budget, and disk allocation that support the complete site. Read the server launch checklist before putting production traffic on the new VPS.