After switching hosts, the safest next step is not to assume everything is working just because the website loads. A DNS cutover can look successful from one device or location and still hide issues in email delivery, SSL, caching, database connections, cron jobs, or application configuration. In a managed hosting environment, a structured post-migration check helps you catch problems early, reduce downtime, and confirm that the new platform is handling live traffic correctly.
Use the checklist below to verify the site, DNS, email, and server-side services after the final switch. It is written for common hosting stacks such as Plesk, Apache, PHP, MySQL, and typical control panel workflows used by European hosting customers.
Confirm that DNS changes have fully propagated
Even after you update the domain to point to the new host, visitors may still reach the old server for a while because DNS caches do not update everywhere at the same time. This is normal during a live cutover, but it means you should verify the domain from multiple networks and locations before you declare the migration complete.
What to check
- Verify that the domain resolves to the correct IP address.
- Check the A and AAAA records if you use both IPv4 and IPv6.
- Confirm that www and the root domain point to the same target if that is your intended setup.
- Review MX records if email is hosted on the same platform or elsewhere.
- Check TXT records used for SPF, DKIM, DMARC, verification, or third-party services.
If you manage DNS through a control panel, make sure the zone file on the new host matches the live DNS configuration. A common issue after migration is that the website works, but mail or verification records were not copied correctly.
Test the website on the new hosting platform
Once DNS points to the new server, open the site in a private browser window and test the most important pages. Do not limit the test to the homepage. Dynamic sites often fail only on specific templates, forms, or secure checkout pages.
Core web checks
- Homepage loads without broken layout or missing images.
- Main navigation works on desktop and mobile.
- Key landing pages return the correct content.
- Internal links, buttons, and menus are functional.
- Forms submit correctly and send notifications.
- Search, login, and account areas work if applicable.
- Downloads, PDFs, and media files open correctly.
Also test the site with and without www, and confirm that any redirects behave as expected. A misconfigured redirect can create a loop, force the wrong canonical host, or break secure cookies.
Check HTTPS, SSL certificate, and redirect behaviour
After a host switch, SSL is one of the most common sources of hidden problems. A certificate may be installed, but it may not cover all hostnames, or the site may still redirect through the old server path. Make sure the full HTTPS flow is clean.
Verify the secure connection
- The SSL certificate is valid and not expired.
- The certificate matches the domain names in use.
- There are no browser warnings about mixed content.
- HTTP redirects to HTTPS if that is your standard policy.
- Redirects from non-www to www, or the reverse, follow a single clean chain.
If you use Plesk, review the domain’s SSL/TLS settings and the hosting configuration for the site. For Apache-based setups, check that rewrite rules are not causing extra hops. A clean redirect path should usually be one or two steps, not several chained redirects.
Validate application and database connectivity
Many sites migrate successfully at the file level but still fail because the application cannot connect to the database or is using outdated credentials. This is especially important for CMS platforms, custom PHP applications, and e-commerce stores.
Database-related checks
- The application connects to the correct database server.
- Database credentials in configuration files are up to date.
- Tables and data migrated fully, without truncation or character set issues.
- Stored procedures, scheduled queries, and triggers work as expected.
- Database-driven features like search, cart, or user profiles function properly.
If you moved from one managed hosting environment to another, compare the PHP version and database engine version on both sides. A site can behave differently after a switch if it relied on legacy PHP functions, strict SQL modes, or specific character encoding settings.
Review server-side logs for hidden errors
Logs are one of the fastest ways to confirm whether the new environment is healthy. A page may appear normal in the browser while the server is still reporting warnings, deprecated functions, missing files, or permission issues.
Logs worth checking
- Web server error log
- Access log for unexpected 404 or 500 responses
- PHP error log
- Application-specific logs
- Mail logs if the platform handles outbound mail
In Plesk, you can usually access domain logs from the control panel. Look for repeated 500 errors, permission denied messages, missing include files, and timeout warnings. A small number of warnings may be harmless, but repeated errors indicate a configuration issue that should be fixed before traffic increases.
Confirm file permissions and ownership
When files are transferred to a new host, permissions may change. This can break uploads, cache directories, log writing, or plugin updates. Shared hosting and managed hosting platforms often use strict ownership rules, so a site can fail only after specific actions like submitting a form or generating a cache file.
Typical permission checks
- Web root files are readable by the web server.
- Writable directories such as cache, uploads, and temp folders are correctly set.
- Configuration files are protected and not publicly writable.
- Ownership matches the expected system user in the control panel.
If the platform uses Apache with PHP-FPM or a similar handler, incorrect ownership can trigger 403 or 500 errors even when file paths look correct. Check the exact error message rather than assuming the issue is DNS-related.
Test email delivery and mailbox access
Email is often the most overlooked part of a host switch. Even if your website is live, users may not receive password resets, contact form messages, invoices, or order notifications if mail records and SMTP settings were not handled correctly.
Email checks after migration
- Send a test message from the website contact form.
- Confirm that outbound messages arrive in inboxes, not spam.
- Test incoming mail if mailboxes were migrated too.
- Check webmail login if your hosting plan includes it.
- Verify SPF, DKIM, and DMARC records.
- Confirm that the site uses the correct SMTP host, port, and authentication.
If mail is handled separately from the website host, make sure the DNS still points mail-related records to the right provider. A successful website cutover does not automatically mean email is safe.
Verify analytics, tracking, and third-party integrations
After a switch, scripts and integrations may fail because of changes to domain paths, certificate trust, firewall rules, or content security settings. These issues are easy to miss during manual browsing, but they can affect reporting and business workflows.
Common integrations to test
- Analytics tags and event tracking
- Tag managers
- Payment gateways
- CRM forms and lead capture tools
- CDN and image optimization services
- Chat widgets and support tools
- Webhooks and API endpoints
Open your browser developer tools and watch for blocked resources, failed requests, or mixed-content warnings. If a service uses allowlists or callback URLs, update them to match the new host if needed.
Check cron jobs, scheduled tasks, and background processes
Scheduled tasks are easy to forget, but they are critical for CMS maintenance, order processing, backups, newsletter sends, cache cleanup, and import/export jobs. A migration can break them if paths, PHP versions, or environment variables change.
What to verify
- Cron jobs still exist on the new platform.
- Task paths point to the correct site directory.
- PHP CLI version is compatible with the application.
- Scheduled emails, queues, and background workers run on time.
- Logs show successful completion, not repeated failures.
For managed hosting environments, confirm whether cron jobs are configured in the control panel or through a separate scheduler. If the site depends on background processing, test it manually after the switch rather than waiting for the next scheduled run.
Inspect redirects, canonical URLs, and SEO signals
A host migration should not damage search visibility. After DNS cutover, make sure search engines and users are seeing the correct version of the site. This is especially important for websites that changed server location within Europe or adjusted their technical setup during migration.
SEO and crawlability checks
- Canonical tags point to the live domain.
- Robots.txt is accessible and correct.
- Sitemap.xml loads without errors.
- No accidental noindex headers are present.
- Old URLs redirect properly to their new equivalents.
- Important pages return 200 status codes, not soft 404s.
Use a crawler or a simple URL checker to spot inconsistent status codes. If you changed from HTTP to HTTPS, or from one host name to another, review the entire redirect map. Broken redirects can slow indexing and cause temporary ranking drops.
Compare performance before and after the switch
New hosting often improves speed, but not always by default. A fresh platform may still need tuning for PHP workers, caching, compression, image handling, or CDN integration. After migration, compare key performance metrics with the previous environment.
Performance areas to review
- Server response time
- Time to first byte
- Page load time on mobile and desktop
- Cache hit rate if you use server caching
- Database query response time
- Resource usage in the control panel
If the site feels slower after the move, check whether the new server has different limits, a different PHP handler, or a cache layer that still needs warm-up. Also review image sizes, plugin load, and any heavy front-end scripts that may now be easier to identify.
Monitor error rates for at least 24 to 72 hours
Do not assume the migration is complete the moment the site passes a few quick tests. Some issues only appear under real traffic, at specific hours, or when background tasks run. Continuous monitoring is essential after a DNS switch and live cutover.
Monitor for these symptoms
- Intermittent 404, 403, 500, or 502 errors
- Slow page loads during peak hours
- Email delays or bounce messages
- Form submissions not reaching the destination
- Unexpected redirects from certain browsers or regions
During this observation period, keep the old hosting account available if possible. If a DNS cache still sends some visitors to the previous server, the old site should either remain in sync or display a clear maintenance message so users are not confused.
Use a practical post-switch checklist
Before you close the migration ticket, complete a final structured review. A checklist makes it easier to confirm that the site, mail, and background tasks are all stable on the new host.
Recommended final checklist
- Domain resolves to the new IP address.
- HTTPS loads without browser warnings.
- Homepage and main templates render correctly.
- Forms, login, and checkout work as expected.
- DNS records for email and verification are correct.
- Logs show no repeated server or application errors.
- Cron jobs and scheduled tasks run successfully.
- Analytics and third-party integrations still fire.
- Redirects are clean and intentional.
- Backups are enabled on the new platform.
If you use Plesk, it is a good idea to confirm the domain’s hosting settings, PHP version, SSL status, and mail configuration in one pass. For Apache-based websites, re-check rewrite rules, .htaccess behavior, and directory permissions.
Common problems after switching hosts
Some issues appear again and again after a live migration. Recognizing them quickly can save time and reduce impact on users.
Frequent post-migration issues
- Site still opens on the old server: DNS has not fully propagated, or local cache is stale.
- Mixed content warnings: Resources are still loaded over HTTP.
- Broken forms: SMTP settings, API keys, or mail records are wrong.
- 500 errors: PHP version, permissions, or rewrite rules need adjustment.
- Missing images or downloads: File paths or ownership are incorrect.
- Slow admin area: Database performance or cache settings need tuning.
When troubleshooting, change one thing at a time and test again. That makes it easier to identify whether the issue is DNS, application configuration, or server-level behavior.
FAQ
How long should I monitor the site after switching hosts?
At minimum, monitor it closely for 24 to 72 hours. For busy sites, keep an eye on logs and key functions throughout the first week because DNS caches and traffic patterns can expose delayed issues.
Why does the site load on my device but not for other users?
Different networks cache DNS for different lengths of time. Your device may already use the new host, while some visitors still resolve the old one. That is why it is important to keep the old environment available for a short transition period if possible.
What is the most common mistake after a host migration?
One of the most common mistakes is checking only the homepage and not testing forms, login areas, SSL redirects, mail delivery, and cron jobs. Another frequent issue is forgetting to update DNS records beyond the A record.
Do I need to change anything in the control panel after the cutover?
Often yes. Review domain settings, SSL status, PHP version, mail configuration, and scheduled tasks in the control panel. In Plesk, these settings may need to be confirmed even if the files and database migrated correctly.
Should I keep the old host active for a while?
Yes, if possible. Keeping the old host active briefly helps catch late DNS propagation and gives you a fallback if something critical was missed. Make sure it does not conflict with the live site or send duplicate mail.
Conclusion
After switching hosts, the real work begins with verification. A successful DNS cutover should be followed by careful checks of DNS propagation, SSL, website behavior, database connectivity, email delivery, scheduled tasks, logs, redirects, and performance. When you test the site from the user’s point of view and the server’s point of view, you reduce the risk of hidden problems reaching visitors.
In a managed hosting environment, a structured post-migration review is the fastest way to confirm that the new platform is stable and ready for production traffic. If something does not look right, fix it before you remove the old host or close the migration window.