How to Move WordPress from Shared Hosting to a VPS Without Losing Email or DNS
How to Move a WordPress Site from Shared Hosting to a VPS Without Losing Email or DNS
Moving WordPress from shared hosting to a virtual private server (VPS) can give you more control over PHP, server resources, and configuration. It can also disrupt email or send visitors to the wrong place if you treat the move as a simple file copy. The key is to separate the website from the services that already depend on your domain.
If you are researching how to migrate a WordPress site from shared hosting to a VPS, start by listing what the current host actually provides. A domain can use one company for registration, another for DNS, a third for email, and a fourth for WordPress. Those services do not need to move together.
1. Scope the move: separate the website from the services that stay behind
Write down where the WordPress files and database live, then identify the provider responsible for each related service. Check the domain registrar, DNS host, email provider, and any separate services such as a CDN or image storage. Your hosting control panel may display some of this information, but the domain’s nameservers and DNS records show where traffic is actually directed.
For example, a site might run on shared hosting while its DNS is managed through Cloudflare and its staff email is handled by Google Workspace. In that arrangement, moving WordPress to a VPS does not require moving the domain or email accounts. It usually means changing the records that route web traffic, while leaving the mail records intact.
Make a simple inventory before changing anything. Record the current web destination, nameservers, and any known mail-related records. If you are unsure whether a record belongs to email, ask the email provider or check its setup instructions rather than deleting it. A missing mail record can stop incoming messages even while the website looks fine.
2. Map dependencies that a basic site copy can miss
A WordPress backup may contain the site files and database but not every service the site relies on. Check scheduled tasks, outbound email settings, external storage, redirects, SSL arrangements, and any server-specific configuration. A membership site, for instance, may depend on a scheduled job to expire accounts, while a store may send order messages through an external SMTP service.
Review the hosting control panel and WordPress plugins for scheduled jobs. WordPress’s built-in task system may run when a visitor loads a page; a server cron job may instead call a specific script on a timetable. Record the command, frequency, and timezone for each job. If the VPS has no replacement cron entry, a task that ran every hour on the old host may stop after the move.
Check how the site sends email. Note whether it uses the hosting provider’s mail server, an SMTP plugin, or a transactional email service, and confirm which sender address the site uses. If the old host supplied the mail server, the same settings may not work from the VPS. Ask the email provider whether it restricts connections or requires a specific authentication method.
Also list external storage and server settings. A media plugin may store uploads in object storage instead of the WordPress uploads directory. The site may rely on a particular PHP version, PHP extensions, rewrite rules, or a setting in .htaccess. Keep a copy of those details; guessing after launch can turn a small compatibility issue into a long outage.
3. Prepare the VPS around the site’s actual requirements
Choose a VPS configuration that matches the site’s observed needs, then decide how it will serve web requests. Common choices include Apache or Nginx, but the right setup depends on the current site and the administrator’s ability to maintain it. Confirm the required PHP version and extensions against the site’s code, plugins, and theme before installing the production stack.
Set up the database, web server, and PHP handler, then configure file ownership and permissions so WordPress can read its files and write only where needed. Avoid making every file writable simply to silence an error. Restrict administrative access, enable a firewall, and arrange backups that include both the database and site files.
Test the VPS before transferring the live site. Confirm that the web server can serve a basic page, PHP runs correctly, and the database accepts a test connection. Document the installed versions and configuration files. That record gives you something concrete to compare if a plugin behaves differently on the new server.
4. Transfer files and database while keeping the live site unchanged
Create a complete copy of the WordPress files and database, and keep the original site available to visitors while you work. A migration plugin can package a site, while command-line tools or a host-provided backup can offer more control. Whichever method you choose, verify that the backup includes the database, uploads, themes, plugins, and any custom configuration files.
For a site with frequent changes, plan how to handle new orders, comments, or published posts created after the first copy. One option is to take an initial copy, test it privately, then repeat the database transfer during a short maintenance window. For a store, avoid accepting orders on both copies: duplicate or missing order data is harder to fix than a brief, announced pause.
Move the files and database to the VPS, then update the WordPress configuration with the new database name, user, password, and host where required. Keep a secure record of the original and new values. If the domain or file paths change, update the site settings carefully; a broad search-and-replace can damage serialized database data if it does not handle serialization correctly.
Do not point public DNS at the VPS yet. The old host should remain the public destination while you check the private copy, and the new server should not receive real customer activity until you are ready to cut over.
5. Test privately before changing public DNS
Use a hosts-file override on your computer or a temporary staging hostname to send your browser to the VPS without changing public DNS. A hosts-file override affects only the device where you add it, making it useful for checking the new site before other visitors can see it. Remove the entry after testing so you do not mistake the private route for the public one.
Test both the front end and the WordPress dashboard. Check the login page, a representative set of key pages, search, forms, uploads, redirects, and any checkout or member function the site uses. Submit a test form and confirm where the message arrives. If the site sends email, check delivery and spam placement; a successful form confirmation on screen does not prove that the email was sent.
Check scheduled tasks and any integrations that call the site from outside. A payment service, for example, may send a notification to a specific URL, while a monitoring service may expect a particular response. Confirm that HTTPS works on the VPS as well. A staging hostname might not match the production certificate, so test the final certificate plan before visitors are sent to the new server.
Review redirects and canonical URLs for the production domain. If the site has a high bounce rate, a broken landing page or redirect can make the problem worse; this guide explains what is a good website bounce and how to interpret the metric. The migration test itself should focus on specific failures, such as a form that returns an error or an upload that does not appear.
6. Cut over DNS with a plan for email and rollback
Before the DNS change, save the current records and note exactly which web records you intend to update. If the domain uses an A record for the website, change that destination to the VPS address. If a CNAME handles the web hostname, adjust that record as needed. Preserve the mail records, including MX records and any TXT records used for email authentication, unless you are deliberately changing email providers.
Lowering the DNS time to live (TTL) ahead of a move can help some resolvers pick up the new destination sooner, but it does not guarantee an immediate global change. Check the current DNS setup and provider guidance before editing records. If you use a proxy or CDN, confirm whether the origin address should point directly to the VPS and whether the proxy’s SSL mode matches the certificate installed there.
Choose a cutover window when you can watch the site and respond to problems. Make the planned web-record change, then check the domain from more than one network or DNS lookup service. Keep a written rollback instruction: restore the previous web destination, note who can make the change, and retain access to the old hosting account. Do not remove the old site while DNS caches may still send visitors there.
Email deserves a separate check during the cutover. Send a message from an outside account to an address at the domain, then reply from that address if possible. If mail stops, compare the current DNS records with the saved copy before making further changes. A web-server move should not require deleting mail records.
7. Confirm the new setup after launch
Once public traffic reaches the VPS, check HTTPS, key pages, forms, login, and any revenue-related workflow. Look at both WordPress and server logs for PHP errors, denied file access, failed database connections, or repeated requests to missing URLs. A site can appear normal on its home page while a plugin error quietly breaks the contact form.
Confirm that backups run on the VPS and that you know how to restore one. Check the backup destination and verify that a recent backup contains both the database and files. Set up monitoring for availability and certificate expiry, then confirm that email still flows in both directions. Those checks should happen before you cancel the previous hosting plan.
Keep the old hosting active until the new site has passed the checks you defined and the relevant DNS changes have settled. Retain a final copy of the old files and database according to your own retention policy. Once the VPS is serving the site, mail is working, and recovery steps are documented, you can decide when to close the old account without guessing what it still supports.
