Reducing downtime during a hosting provider change starts long before the final DNS switch. The main goal is to make the old and new environments behave as similarly as possible, keep DNS changes predictable, and verify every critical service before traffic moves over. In most migrations, the longest interruptions happen not because the server is unavailable, but because DNS records, cache, mail routing, or application settings were not prepared in time.
If you are moving a website, application, or mailbox service to a new hosting platform, the safest approach is to prepare the target server first, lower DNS TTL values in advance, copy all data and configuration, and test the site using a temporary host name or local resolution. For websites managed through Plesk, Apache, or a similar control panel, you should also check virtual host settings, PHP version, database access, SSL certificates, and cron jobs before making the live cutover.
Why downtime happens during a hosting provider change
Downtime is often caused by a mismatch between what users expect and what the new environment is ready to serve. Even if the files are copied correctly, visitors may still see an old site, an error page, or a partially working application if DNS has not fully propagated or if backend services are missing.
Common causes include:
- DNS records still pointing to the old hosting server because the TTL was too high.
- Website files copied, but the database import was incomplete or used the wrong credentials.
- SSL certificates not installed on the new server before the cutover.
- PHP version, extensions, or Apache/Nginx rules differing from the previous host.
- Email MX, SPF, DKIM, or DMARC records not updated consistently.
- Application caches, CDN settings, or browser caches showing stale content.
- Missing redirects, broken absolute paths, or hardcoded server references inside the application.
The key to minimizing disruption is not only copying data, but also planning the DNS switch and live cutover as a controlled change window rather than a single DNS edit.
Plan the migration before you touch DNS
The best time to reduce downtime is before any traffic is moved. Prepare the new hosting account or server first, and make sure it is ready to accept live requests without manual intervention. In a managed hosting or control panel environment, this means confirming that the domain, website, database, mailboxes, and security settings are already configured.
Pre-migration checklist
- Review the current DNS zone and export all records.
- Confirm the new hosting package includes enough disk space, CPU, and memory.
- Set up the domain in the new control panel or Plesk subscription.
- Create the database and database user on the new host.
- Copy all website files, including hidden files such as .htaccess.
- Import the database and verify table count and content.
- Check application configuration files for database host, username, and password.
- Install or generate SSL certificates on the new server.
- Replicate email accounts, forwarding rules, and aliases if mail is part of the migration.
- Test cron jobs, scheduled tasks, and background workers.
If your website uses a CMS such as WordPress, Joomla, or Drupal, also confirm that the site URL, upload paths, and cache plugins are correctly adjusted for the new environment. For custom applications, review environment variables, API keys, and file permissions.
Lower DNS TTL values before the final cutover
One of the most effective ways to reduce downtime is to lower the TTL, or Time To Live, on important DNS records before migration day. TTL determines how long resolvers and caches keep a DNS response before checking again for updates. If your A, AAAA, CNAME, or MX records have a very long TTL, many users will continue reaching the old server long after you change the DNS.
Ideally, reduce the TTL to a short value such as 300 seconds or 600 seconds at least 24 to 48 hours before the migration. This gives recursive DNS resolvers time to refresh the record and shortens the period during which some visitors reach the old host and others reach the new one.
Records to review first
- A and AAAA records for the main website and subdomains.
- CNAME records used for www or app hostnames.
- MX records if email is hosted together with the website.
- TXT records used for SPF, DKIM, DMARC, verification, and security services.
- SRV or other service-specific records if your application needs them.
Remember that lowering TTL does not immediately affect all users. Some resolvers may still keep the previous value until it expires, which is why the TTL should be adjusted well before the live cutover.
Prepare the new hosting environment for a seamless switch
The new server should be ready to answer production traffic before the DNS change happens. In a hosting platform or Plesk environment, this means testing the full stack, not just the homepage. If your site depends on Apache rewrite rules, PHP-FPM, database connectivity, or object storage, each layer should be checked separately.
What to validate on the new server
- Website loads correctly over HTTP and HTTPS.
- SSL certificate matches the domain name and any required aliases.
- PHP version is compatible with the application.
- Apache virtual host or web server configuration matches the expected document root.
- Database connection works without timeouts or authentication errors.
- File and folder permissions allow uploads, cache writes, and logs.
- Mail sending and receiving work if mailboxes are being moved.
- Backup and restore features are available and tested.
- Error logs are accessible for troubleshooting after go-live.
If possible, avoid making application changes at the same moment as the DNS switch. A cutover is easier to troubleshoot when the new environment has already been validated with real data.
Test the site before you change public DNS
Testing the new host before users reach it is one of the best ways to catch hidden problems. You can do this in several ways, depending on your setup. Common approaches include using a temporary preview URL from the hosting platform, editing the local hosts file on your computer, or accessing the site via the server IP with the correct host header if your setup supports it.
Recommended pre-live tests
- Open the homepage, category pages, and key landing pages.
- Test login, search, checkout, contact forms, or any interactive feature.
- Upload a file and confirm it is stored correctly.
- Check server-side generated content such as feeds or PDFs.
- Verify redirects from http to https and from non-www to www, or the reverse.
- Inspect page source and ensure no old server addresses are hardcoded.
- Use browser developer tools to confirm there are no mixed-content warnings.
For e-commerce, membership, and business-critical websites, create a short test script so that every important workflow is validated in the same order each time. This makes it easier to compare the old and new site during migration.
Keep the old hosting account active during DNS propagation
After the DNS change, some visitors will continue to hit the old server until their DNS cache expires. That is normal. To avoid broken sessions or lost emails, keep the old hosting account active for a few days after the cutover. In many cases, keeping the old environment online for 48 to 72 hours is enough, but high-traffic or globally distributed sites may need longer.
During this overlap period, the old server should ideally either:
- Serve a maintenance notice with a clear message if updates are no longer accepted there, or
- Remain synchronized with the new server for content that might still be updated by users.
If the website allows user-generated content, form submissions, orders, or customer logins, you should decide whether to freeze content before the switch or implement a short synchronization window. The wrong choice here can create data inconsistency even if downtime is minimal.
Use a staged cutover for dynamic websites
Static sites are usually easier to move than dynamic applications. For sites with ongoing updates, a staged cutover often provides the best balance between availability and data consistency. In practice, this means separating content that changes frequently from content that can be copied ahead of time.
Typical staged cutover workflow
- Copy the full site and database to the new host.
- Set the new server to read-only or maintenance mode if needed.
- Lower DNS TTL values in advance.
- Schedule a final sync for files and database changes.
- Pause user activity on the old site if the application requires it.
- Run the final import or sync.
- Change DNS to point to the new server.
- Monitor logs, forms, and error reports closely.
- Keep the old host available until traffic has fully moved.
This process is especially useful for forums, stores, booking platforms, and membership sites where new data can be created at any time. If a maintenance window is acceptable, it is better to announce a short freeze than to risk data loss.
Update DNS records carefully
When the new host is ready, update the DNS records in a controlled way. The exact change depends on how your domain is configured. In many migrations, you will update the A record for the root domain and the www hostname. If you are also moving mail, you may need to change MX records and the related authentication records at the same time or shortly after.
Best practice for DNS switch and live cutover
- Change only the records that need to move.
- Do not remove old records until the new ones are confirmed.
- Keep TTL low during the first phase after the switch.
- Confirm the domain’s authoritative nameservers are correct.
- Verify DNS propagation from several networks or checking tools.
Be careful not to forget related subdomains. Sites often use separate records for app., mail., cp., shop., or api. If those services are still in use, they must be reviewed before the migration is declared complete.
Check SSL, redirects, and canonical URLs after go-live
After DNS points to the new host, the website may technically be live but still show problems if SSL or redirects are not aligned. These issues can make the site appear down even when the server is responding correctly.
Post-cutover checks
- Open the site over HTTPS and confirm the certificate is valid.
- Check that the browser does not show certificate warnings.
- Confirm the preferred hostname loads correctly, with consistent redirects.
- Inspect canonical tags if your CMS or SEO plugin uses them.
- Test forms, login pages, and password reset flows.
- Review logs for 404, 500, and permission errors.
If you use a reverse proxy, CDN, or security layer, make sure it is updated with the new origin server. A common issue after migration is that the DNS is correct, but the CDN still points to the old origin or caches outdated rules.
Handle email separately from the website when needed
Email often causes more confusion than the website itself during a provider change. If your hosting platform also provides mailboxes, be sure to review mail migration independently from the web migration. A website can go live successfully while mail still fails because MX records or authentication records were left behind.
Email migration checklist
- Move all mailboxes, aliases, and forwarders.
- Update MX records to the new mail server.
- Publish or update SPF, DKIM, and DMARC records.
- Check mail client settings for IMAP, SMTP, and port values.
- Test sending and receiving from external providers.
- Verify webmail access if your users rely on it.
If email continuity is critical, consider leaving the old mail service active during the transition or setting up forwarding temporarily. That reduces the risk of lost messages while DNS updates spread across the network.
Monitor the site closely during the first 24 hours
The first day after migration is the most important time to watch for issues. Even a well-planned hosting provider change can reveal unexpected problems once real traffic arrives. Monitoring should focus on availability, error rates, response times, database load, and user-facing functionality.
What to watch after the switch
- Server uptime and HTTP response codes.
- Error logs for Apache, PHP, and application-level failures.
- Database performance and connection errors.
- Form submissions and transactional emails.
- Search engine crawl errors, if the site is public.
- Traffic patterns from different regions while DNS propagates.
For managed hosting users, it is useful to keep the control panel open and monitor resource consumption, backup status, and security logs. A sudden spike in traffic or misconfigured process can be easier to resolve early than after it affects many users.
Common mistakes that increase downtime
Most long outages during a migration are avoidable. They usually come from skipping a verification step or trying to complete the move too quickly. The following mistakes are especially common:
- Changing DNS before the new site has been tested.
- Leaving TTL values high until the day of the switch.
- Forgetting to copy hidden files, certificates, or cron jobs.
- Not checking database import size and character encoding.
- Moving the website but forgetting mail, DNS, or subdomains.
- Switching hosts and making application changes at the same time.
- Shutting down the old server too soon.
A useful rule is to treat the DNS change as the final step, not the main task. The more work you complete beforehand, the less visible downtime users will experience.
Practical migration timeline example
Here is a simple timeline for a low-downtime website move:
- 3 to 7 days before migration: audit DNS records, prepare the new hosting account, and verify compatibility.
- 24 to 48 hours before migration: lower TTL values for key records.
- 1 day before migration: copy files, import the database, and test the site on the new server.
- Migration window: perform the final sync, freeze updates if needed, and change DNS.
- First 24 hours after migration: monitor logs, DNS propagation, forms, mail, and SSL.
- 48 to 72 hours after migration: confirm old traffic has stopped, then decommission the old host.
This approach works well for most sites because it creates enough overlap for DNS propagation while keeping the final cutover short and controlled.
FAQ
How long should TTL be before switching hosting providers?
For most migrations, a TTL of 300 to 600 seconds is a practical choice for records that will change during the cutover. Set it at least 24 to 48 hours in advance so caches have time to pick up the new value.
Can I avoid downtime completely when changing hosting provider?
In some cases, yes, especially for static sites or applications designed for replication and zero-downtime deployment. For many websites, however, the realistic goal is near-zero downtime rather than absolute zero. DNS propagation and active sessions can still cause short overlap periods.
Should I change DNS before copying the website?
No. Copy and test the website first. DNS should be changed only after the new server is ready and verified. If you point traffic to an untested host, users may see errors immediately.
Do I need to move email at the same time as the website?
Not always. If possible, handle website and email separately unless the migration plan requires both to move together. Separating them can reduce risk and make troubleshooting easier.
Why do some users still see the old site after DNS is changed?
Because DNS responses are cached by resolvers, ISPs, browsers, and sometimes CDNs. Even after you update the record, different users may continue reaching the old server until the cached data expires.
What should I check in Plesk after migration?
Verify the domain subscription, document root, PHP version, SSL certificate, mail settings, scheduled tasks, file permissions, and any Apache or web server directives. Also confirm the site opens correctly in both the browser and the control panel preview.
Conclusion
Reducing downtime when changing hosting provider is mostly a matter of preparation, timing, and verification. Lower DNS TTL values early, build and test the new environment before the switch, keep the old server online during propagation, and check all related services after go-live. If you treat the DNS switch and live cutover as a planned process rather than a single change, you can move websites with far fewer surprises and much less disruption for users.