How to Move a Hosting Site to New Server Safely in 2026
Start with a full checklist, not the transfer
If you need to move a hosting site to a new server, start by reducing surprises. Check everything the site depends on: files, database, email, SSL, cron jobs, PHP version, and DNS.
For many Hostperl customers, the move starts because the current plan has reached its limit. If that sounds familiar, compare your options first with our shared, VPS, and dedicated hosting guide. It can save you from migrating twice.
Before you touch the new server, write down these details:
- Domain names and subdomains in use
- Current PHP version and extensions
- Database name, user, and charset
- Email accounts, aliases, and forwarders
- SSL certificate type and expiry date
- Any scheduled tasks or cron jobs
- DNS records that must stay unchanged
This is where a lot of migrations go wrong quietly. Miss an inbox or cron job, and the site may load while mail stops or reports fail in the background.
Prepare the destination server first
Set up the new hosting environment before you copy anything. If you are using Hostperl VPS hosting, confirm the operating system and panel version match the site’s needs, especially for PHP-based CMS installs and mail routing. You can review Hostperl VPS hosting if you need a cleaner target for the move.
On a managed or self-managed VPS, make sure the basics are in place:
- Create the hosting account or virtual host.
- Install the same or newer PHP version.
- Enable required modules such as mysqli, mbstring, and zip.
- Set up the database server and create an empty database.
- Install SSL or prepare for issuance after the cutover.
- Confirm backup storage exists before the move starts.
If you are migrating between control panels, check the workflow first. Our cPanel vs Plesk comparison and panel comparison guide are useful if your old and new servers do not use the same control panel.
Copy files, database, and mail in the right order
The safest sequence is files first, database second, mail third. That keeps the site consistent while you test it on the new server.
For a WordPress or similar CMS site, copy the web root and then import the database. If your site uses cPanel, the practical starting point is often the document root under /home/username/public_html. For Plesk, you will usually find the site in /var/www/vhosts/yourdomain.com/httpdocs. DirectAdmin users often see the site under /home/username/domains/yourdomain.com/public_html.
Use the transfer method that fits the source server:
- cPanel full backup: best when you want account settings, mailboxes, and databases together.
- Plesk subscription export: useful when the domain stays inside the same panel family.
- Manual rsync + database dump: best for clean VPS-to-VPS moves or mixed environments.
If you need a practical reference for account setup before migration, see how to set up a new hosting site in cPanel or Plesk. It helps you confirm the destination structure before the live switch.
For the database, export from the old server and import into the empty database on the new server. Then update the site configuration file with the new database credentials. In WordPress, that usually means checking wp-config.php. In other CMS platforms, the file name changes, but the rule does not.
Test the site before changing DNS
Do not point the domain at the new server until the site works on a temporary address or through a hosts-file test. That step saves time and protects revenue if the site handles orders, enquiries, or client logins.
Open the site using the server IP or temporary hostname and check:
- Homepage and a few deep pages load correctly
- Images, CSS, and JavaScript resolve without mixed-content errors
- Contact forms submit successfully
- Admin login works
- Database-driven pages display real content, not a blank error
If SSL is already installed, visit the site over HTTPS during testing. A migration that only works over HTTP is not finished.
For a tighter pre-launch checklist, pair this step with Hostperl’s uptime checklist. It is short, practical, and useful before a production switch.
Handle DNS, SSL, and email without breaking live traffic
DNS cutover is where most migration stress starts. Lower the TTL on your key records 24 to 48 hours before the move if you can. A TTL of 300 seconds is common for cutovers, though you can raise it again after everything settles.
Only update the records that need to change. In many migrations, that means the A record for the website and possibly www. Leave mail records alone unless the mail service is also moving.
If you are moving both the website and email, follow a proper sequence. Our SSL, DNS, and email setup checklist is a good companion guide. It keeps the website live while mailbox delivery is being verified.
SSL needs a quick check after DNS changes. Reissue the certificate if the new server uses a different control panel or validation path. For Let’s Encrypt, confirm the domain resolves to the new server before the renewal process runs, or validation may fail.
Email needs extra care. If MX records change too early, mail may bounce or land on the wrong server. If email is staying put while the website moves, keep MX, SPF, DKIM, and DMARC untouched until the mail migration is complete.
Check the common failure points after cutover
After DNS has propagated, test the site again from an external network. Then check the parts customers notice first: logins, forms, checkout, and email delivery.
Use this quick diagnostic list:
- 500 errors: usually PHP version, permissions, or missing modules
- Database connection errors: wrong credentials or database host
- Broken images or CSS: hard-coded old URLs or permission issues
- Email failures: MX, SPF, DKIM, or mail routing mismatch
- Slow pages: unoptimized PHP handlers, CPU limits, or no object cache
For speed tuning after the move, keep it simple first. Match PHP to the application, enable compression where appropriate, and remove plugins or extensions you no longer need. If you are on a VPS, make sure your web server is not swapping under load. That usually points to an undersized plan, not a site that needs more tweaks.
If the move is part of an upgrade, this is also a good time to confirm whether the site really belongs on shared hosting or needs more room. Hostperl’s VPS vs dedicated servers guide gives a clear operational view, not a theoretical one.
Use backups and a rollback plan before you announce the move
Every migration should have a rollback path. Keep a fresh backup of the old server until the new one has run cleanly for at least 24 to 72 hours. Do not delete the source account just because the homepage loads once.
A simple rollback plan looks like this:
- Keep the old server live.
- Preserve the old DNS zone and SSL details.
- Record the exact time of the DNS change.
- Save database exports and a file archive in two places.
- Know who will reverse the record if testing goes wrong.
If you are moving from shared hosting to VPS, this backup discipline matters even more. The move often includes different file paths, different PHP handlers, and new mail settings. Our shared hosting to VPS migration guide covers the handoff steps in more detail.
If you want a migration handled with real support behind it, Hostperl can help you plan the move, set up the destination server, and verify the cutover. Start with managed VPS hosting if you need room to grow, or review dedicated server hosting for heavier sites and email workloads.
Our team works with live migrations, DNS changes, SSL renewals, and panel-specific handoffs every day, so you are not left guessing after the transfer.
FAQ
How long should I keep the old hosting active?
Keep it active for at least 48 hours after the DNS change, and longer if your traffic comes from many regions or if email is still resolving to the old server.
Can I move a site without downtime?
Yes, if you copy the site first, test it on the new server, lower DNS TTL ahead of time, and switch only after validation. A short DNS overlap is normal.
What should I move first: files or database?
Move the files first, then the database, then update the configuration file. That sequence keeps the application consistent during testing.
What if my email is hosted separately?
Leave MX, SPF, DKIM, and DMARC records unchanged while the website moves. That keeps inboxes working while you complete the web cutover.
Do I need a VPS for every migration?
No. Small brochure sites may stay on shared hosting. If you need more control, better isolation, or a stronger mail setup, a VPS is usually the better landing point.
