How to Move Hosting Sites Without Downtime in 2026
Start with the safest migration plan
If you need to move hosting sites without downtime, do the prep work before you touch DNS. Most failed migrations are not caused by the new server. They happen because email, SSL, or DNS timing was checked too late.
For shared hosting customers, agencies, and small teams, the cleanest approach is to stage the site on the new account, test it on a temporary URL or hosts file, then switch traffic only after you have checked login pages, forms, and mail delivery. If you are moving from shared hosting to a VPS, Hostperl can help you map the right plan first through Hostperl VPS hosting.
- Lower DNS TTL at least 24 hours before the cutover.
- Copy files, databases, and email accounts before the final switch.
- Keep the old service live until the new site is confirmed healthy.
Check what must move before the cutover
Every site has four moving parts: files, database, email, and DNS. Leave one behind and you create the kind of issue customers notice first, usually a missing contact form or a mailbox that stops syncing.
Start by listing the current platform. A cPanel account needs a different handoff than Plesk or DirectAdmin, and each panel stores mail and SSL details in different places. If you are still choosing a panel for the destination server, this internal guide on cPanel, Plesk, or DirectAdmin is worth reading before migration day.
- Confirm the document root, database name, and PHP version.
- Export the database and note any cron jobs or scheduled tasks.
- Record DNS records for the domain, subdomains, MX, SPF, DKIM, and DMARC.
- Check mailbox size if email is hosted with the site.
Hostperl support teams see the same pattern every week: people copy the website and forget the mail or DNS records. A good migration checklist keeps that from happening.
Prepare the destination hosting environment
Before you import anything, make sure the new environment matches the old one closely enough to serve the site. That means PHP version, database version, web server settings, and enough storage for growth, not just the current folder size.
If you are moving to managed hosting or a fresh server, a practical launch path is usually shared hosting for simple WordPress sites, or a VPS for sites that need custom PHP extensions, larger databases, or isolated mail handling. Hostperl’s shared hosting works well for smaller CMS sites, while larger or multi-site moves usually fit better on managed VPS hosting.
For Linux-based servers, check these basics first:
- Available disk space and inode headroom.
- PHP extensions required by the application.
- Database version compatibility, especially for WordPress, Laravel, or older plugins.
- Mail service status if you host inboxes on the same server.
If the site is customer-facing and time-sensitive, build a test subdomain such as staging.example.com and point it to the new server while the public domain stays live elsewhere.
Copy files, databases, and configuration in the right order
Move the site files first, then the database, then the configuration that connects them. That order reduces confusion when you test the site before the domain points across.
For WordPress, export the database from the old host and import it into the new one, then update wp-config.php with the new database credentials. For cPanel users, the built-in backup tools or a full account backup often save time, especially if you want to follow a consistent handoff path. We have a step-by-step cPanel migration checklist that covers the details Hostperl support usually asks for.
Watch permissions closely. A copied site can still fail if uploads folders are owned by the wrong user or if cache files from the old server carry over with bad paths.
chown -R www-data:www-data /var/www/example.com/public_html
find /var/www/example.com/public_html -type d -exec chmod 755 {} \;
find /var/www/example.com/public_html -type f -exec chmod 644 {} \;Use those commands only when your stack uses www-data and the site expects standard Apache or Nginx ownership. On panel-managed servers, follow the panel’s recommended ownership model instead of forcing a generic Linux setup.
Test the site before you switch DNS
Testing is where a clean migration becomes a safe one. Open the site on the new server using a temporary hosts file entry or a private staging URL, then click through the pages that make money or receive enquiries.
Check the obvious pages first: home page, login form, checkout page, contact form, search, and any uploads workflow. Then send a test email from the site if it has notifications or order receipts. If delivery matters to you, read our guide on shared hosting vs VPS for email deliverability before deciding whether mail should stay with the site or move separately.
- Do images load from the new path?
- Do forms submit and send mail?
- Does the admin panel open without mixed-content warnings?
- Are there any broken links or 500 errors?
If the SSL certificate is already installed on the new server, the browser should show a clean HTTPS lock on the staging test. If not, fix SSL now, not after the DNS change.
Handle DNS and SSL with care
DNS is usually the last step, but it is the step clients notice first. Lower the TTL on the A, AAAA, and MX records before the move, then update the zone only after the destination is ready.
For most moves, keep the old server live for at least 24 to 48 hours after the DNS update. That gives slow resolvers time to catch up and cuts down on support tickets about intermittent access. Our SSL, DNS, and Email Setup Checklist for Hosting Customers is a practical companion if you are managing the cutover yourself.
Before you switch:
- Confirm the A record points to the new web server.
- Update MX records only if mail also moves.
- Check SPF, DKIM, and DMARC after the move.
- Renew or reissue the SSL certificate if the host name changed.
If the domain uses Cloudflare or another proxy layer, make sure it is not masking an old origin IP after you update the record. A quick browser test from a mobile network can help expose stale DNS caching.
Move email separately if delivery matters
Email is the part most likely to break quietly. A website can look fine while mail disappears into a queue, lands in spam, or fails because the new server is missing authentication records.
When moving shared hosting mailboxes, migrate the inbox contents, recreate aliases, and confirm SMTP settings in the mail client. If the site uses cPanel mail, use the email setup guide for email on shared hosting in cPanel as a reference for client-side configuration.
For business sites, separate the mail cutover from the web cutover if you can. That gives you one smaller problem at a time, and it makes troubleshooting much easier if receipts or contact forms fail later.
Use a rollback plan before you cut traffic
A rollback plan is not pessimistic. It is the difference between a short incident and a long support case.
Keep the old hosting account active until you have confirmed that the new site serves correctly, mail flows, backups exist, and the admin area works from more than one network. If the new server shows unexpected database errors or the wrong PHP version breaks a plugin, you can point DNS back to the old IP while you investigate.
A simple rollback checklist looks like this:
- Save the old DNS records before editing anything.
- Keep a fresh backup of the original site and database.
- Record the time of the DNS change.
- Know who will verify the site if you need to revert.
For larger migrations, especially if you are comparing larger plans, this comparison of VPS vs Dedicated Servers helps you avoid moving twice.
Common problems after a migration
Most post-move issues fall into a few repeatable categories. The good news is that each one has a quick diagnostic path.
- Site loads but admin login fails: check cookie domain, HTTPS redirects, and cached application URLs.
- Forms submit but no email arrives: verify SMTP settings and mail authentication records.
- Old content appears: purge application cache, CDN cache, and browser cache.
- Database errors: confirm the database host, username, password, and table prefix.
- SSL warnings: reissue the certificate for the correct hostname and make sure the new IP answers on port 443.
If you are on a panel-managed environment and the issue looks like a service mismatch rather than an application problem, ask the host to check Apache or Nginx logs, PHP-FPM status, and mail queue health. That is the kind of operational support Hostperl customers expect, and it saves time compared with guessing from the browser alone.
If you want help to move hosting sites without downtime, Hostperl can handle the practical parts that usually slow teams down: plan selection, migration timing, DNS checks, and post-cutover verification. For many customers, the right starting point is either shared hosting for smaller sites or Hostperl VPS hosting for custom stacks and heavier traffic.
Our support team works with real launches, not lab setups, so you can move with a clear rollback path and fewer surprises.
FAQ
How long does a typical hosting migration take?
A small shared hosting site may take under an hour once backups are ready. Larger sites take longer because email, DNS propagation, and testing add real time.
Should I move email at the same time as the website?
Not always. If delivery is critical, move the website first and email second so you can isolate problems faster.
Can I move a site without changing the IP right away?
Yes. You can lower TTL, test on a temporary URL, and point DNS only when the new server is fully checked.
What if my site uses cPanel or Plesk?
Use the panel’s backup and restore tools where possible. They preserve account structure better than manual file copying.
When should I choose a VPS instead of shared hosting for a migration?
Choose a VPS if you need custom software, stronger isolation, more control over mail, or enough room to grow without repeated upgrades.
