How to Test a Migrated Website Before Going Live

Before you point your domain to a new hosting environment, it is worth spending time on a full pre-launch check. A migrated website can look fine at first glance and still hide broken links, missing images, PHP errors, email delivery issues, or database inconsistencies that only appear under real traffic. A careful test before going live helps reduce downtime, protects SEO, and avoids the common “it works on the old server but not on the new one” problem.

If you are moving a site within a managed hosting platform or through a control panel such as Plesk, the safest approach is to validate the website on the new server using a temporary URL, hosts file override, or staging environment before changing DNS. The goal is simple: confirm that the site behaves correctly in the new environment, with the new PHP version, web server configuration, database connection, SSL certificate, and email settings.

Why testing a migrated website matters

Website migrations often involve more than copying files. A typical move can include databases, DNS records, PHP settings, cron jobs, mailboxes, caches, redirect rules, and application-specific configuration. Even small differences between the old and new hosting setups may cause issues.

Testing before going live helps you:

  • identify broken pages, forms, and menus before visitors see them;
  • check that images, CSS, JavaScript, and fonts load correctly;
  • verify that login, checkout, search, and other dynamic functions work;
  • confirm that the correct PHP version and extensions are enabled;
  • spot database connection errors, charset issues, or missing tables;
  • test SSL, redirects, and canonical URLs;
  • reduce SEO risks such as duplicate content or crawl errors;
  • avoid email disruption for contact forms and transactional messages.

For EU-based websites, testing is especially useful when you are moving between environments with different performance profiles, caching layers, or data handling rules. It also helps confirm that the new hosting platform is ready for traffic from multiple countries and browsers.

What to prepare before you test

Before checking the migrated site, make sure the new environment is complete and consistent. A good test starts with a clean setup.

Confirm the migration scope

Check whether all required components were copied:

  • website files and media uploads;
  • database exports and imports;
  • email accounts, aliases, and forwarding rules;
  • DNS records, if they are being moved or recreated;
  • SSL/TLS certificate;
  • cron jobs, scheduled tasks, and automation scripts;
  • application configuration files;
  • caches, session storage, and temporary directories.

Match the runtime environment

Compare the source and destination settings as closely as possible. In a Plesk or similar hosting control panel, review:

  • PHP version;
  • PHP handler type;
  • memory_limit, upload_max_filesize, post_max_size, max_execution_time;
  • Apache or Nginx configuration;
  • mod_rewrite or equivalent rewrite support;
  • database version and character set;
  • file ownership and permissions.

Many migration issues come from a mismatch in one of these settings rather than from the site content itself.

Prepare a safe testing method

There are three common ways to test a migrated website before DNS propagation:

  • Temporary URL provided by the hosting platform;
  • Hosts file override to point your local machine to the new server;
  • Staging domain or subdomain used as a test copy.

The hosts file method is often the most accurate because it lets you browse the live domain as if it were already on the new server, without changing DNS for everyone.

How to access the migrated site safely

Using a temporary URL

Some hosting platforms offer a preview URL or server hostname. This is useful for a quick visual check, but it can be limited because applications sometimes rely on the real domain name for links, cookies, and SSL. If your site uses a CMS, e-commerce plugin, or hardcoded absolute URLs, a temporary URL may not reveal every issue.

Using the hosts file

Editing the hosts file on your computer maps the domain to the new server’s IP address locally. This is one of the best methods for migration testing because it shows the site exactly as the browser will see it after the DNS switch.

Typical uses include:

  • testing WordPress, Joomla, Drupal, Magento, or custom applications;
  • verifying SSL certificate behavior on the actual domain;
  • checking redirects and canonical URLs;
  • testing login and session persistence.

Remember to remove the hosts file entry after testing so your computer resolves the domain normally again.

Using a staging subdomain

A staging subdomain such as staging.example.com is convenient for internal review, but it is not always identical to the live domain behavior. It is best for visual and functional checks, while domain-specific validation still requires testing with the real hostname.

What to check after migration

Once you can access the site on the new hosting environment, go through the main test areas systematically. The most efficient approach is to test from top to bottom: homepage, content pages, interactive features, backend functions, then performance and security.

1. Check the homepage and core pages

Open the homepage and a selection of high-value pages such as:

  • About page;
  • Services or product pages;
  • Contact page;
  • Privacy policy and legal pages;
  • blog or news listing;
  • important landing pages with SEO traffic.

Look for broken layout elements, missing images, incorrect fonts, and content that loads partially or not at all.

2. Verify navigation and internal links

Browse menus, footer links, category pages, and breadcrumbs. Pay attention to:

  • broken internal links;
  • links still pointing to the old domain or old paths;
  • missing anchor targets;
  • pagination errors;
  • mobile menu behavior.

If the site was moved from one environment to another, old absolute URLs are a common problem. Search and replace operations in the database may be needed for CMS-based websites.

3. Test forms and email delivery

Submit every important form on the site, including:

  • contact forms;
  • quote request forms;
  • newsletter signups;
  • checkout forms;
  • password reset forms;
  • support ticket or callback forms.

Check whether form submissions are received correctly and whether outgoing emails are sent from the new environment. If the hosting platform uses SMTP authentication, verify mailbox credentials, port numbers, and encryption settings. On managed hosting, it is also worth checking spam folder delivery and sender authentication records such as SPF, DKIM, and DMARC.

4. Test login, registration, and account features

If the site has user accounts, make sure the following work as expected:

  • registration;
  • login and logout;
  • password reset;
  • profile updates;
  • account dashboard pages;
  • role-based permissions.

Session problems can appear after migration if cookies, domain settings, or secure flags are not aligned with the new environment.

5. Review media, downloads, and asset loading

Open image-heavy pages, downloadable PDFs, JavaScript-driven components, sliders, and embedded videos. Check that:

  • images load from the correct location;
  • file downloads work;
  • lazy-loading does not break content;
  • CDN links are correct, if used;
  • cached assets are refreshing properly.

If the site uses a content delivery network, confirm that it is still pointing to the correct origin server.

6. Check database-driven functions

For dynamic websites, the database is often where hidden problems show up. Review:

  • blog posts and categories;
  • product listings and filters;
  • search results;
  • saved cart or order history;
  • admin reports and dashboards;
  • custom fields and repeating content blocks.

Character encoding problems, missing serialization updates, and broken foreign keys can affect content display or data integrity. If special characters appear corrupted, verify the database collation and application encoding.

7. Confirm SSL and redirects

Open the site using https and test the certificate. Verify that:

  • the certificate is valid and matches the domain;
  • there are no browser warnings;
  • HTTP redirects to HTTPS correctly;
  • www and non-www versions behave consistently;
  • old URLs redirect to the correct new locations.

Redirect chains can hurt performance and SEO. Keep redirect rules simple and check for loops, especially if the old and new servers have different rewrite configurations in Apache or Nginx.

8. Inspect robots, canonicals, and SEO signals

Before launch, confirm that the site is not accidentally blocked from indexing. Review:

  • robots.txt;
  • meta robots tags;
  • canonical tags;
  • sitemap.xml;
  • hreflang tags, if applicable;
  • structured data output.

It is common to leave a staging noindex rule in place too long. Make sure the production version is ready to be crawled when you go live. For an EU audience, also check that localized versions and alternate language pages point to the correct canonical URLs.

Performance checks before going live

A migrated site should not just work; it should also perform well. New hosting resources, server caching, and configuration changes can improve or weaken performance.

Measure page load speed

Test a selection of key pages with browser developer tools or a performance testing service. Focus on:

  • time to first byte;
  • largest contentful paint;
  • layout shifts;
  • render-blocking scripts and styles;
  • server response times.

If the site is slower than expected, check whether caching is enabled, whether image optimization is active, and whether the PHP version is appropriate for the application.

Review cache behavior

Clear application caches after migration and then retest. This includes:

  • CMS cache;
  • object cache;
  • opcode cache;
  • page cache;
  • browser cache if needed for local testing.

Sometimes a site only appears broken because stale cached files still reference the old environment.

Check server logs

Review error logs and access logs in your hosting control panel. In Plesk or similar platforms, logs often reveal issues that are not visible on the front end, such as:

  • PHP warnings and fatal errors;
  • permission denied messages;
  • 404 errors for missing assets;
  • rewrite rule failures;
  • timeout or memory limit errors.

A clean front-end view does not always mean the backend is healthy. Logs are one of the fastest ways to spot hidden migration problems.

Common migration problems and how to fix them

Broken images or CSS

This usually means the site still points to old paths or absolute URLs. Search the database and configuration files for the old domain, then update references carefully. Also confirm file permissions and case sensitivity, especially if the source and destination servers use different file systems.

Database connection errors

Check the database name, username, password, and host. If the database server changed, update the application configuration accordingly. Also confirm that the database user has the correct privileges.

Login sessions not working

This can happen if cookies are set for the wrong domain or if HTTPS is not configured consistently. Review session configuration, secure cookie settings, and base URL values in the application.

Forms not sending email

Confirm SMTP settings, sender address, and mail routing. If the hosting platform uses outbound mail restrictions, make sure the site is authenticated correctly. Test both transactional and contact form messages.

Redirect loops

These often appear when multiple redirect layers conflict, for example a CMS rule, an .htaccess rule, and a control panel redirect all trying to force HTTPS or a preferred hostname. Simplify the rules and test each change one at a time.

Recommended pre-launch checklist

Use this checklist before switching DNS to the new server:

  • site opens correctly on the new hosting environment;
  • homepage and main pages load without layout issues;
  • menus, links, and buttons work;
  • forms submit successfully;
  • emails are delivered;
  • database content displays correctly;
  • SSL certificate is valid;
  • HTTP to HTTPS redirect works;
  • www/non-www behavior is correct;
  • robots.txt and noindex rules are reviewed;
  • analytics and tracking scripts are present;
  • cron jobs and scheduled tasks are enabled;
  • logs do not show critical errors;
  • cache has been cleared and retested;
  • backup is available before the final cutover.

When to switch DNS

Switch DNS only after the migrated website passes your main checks. The ideal moment is when you have confirmed that the new server can handle normal traffic and that the content matches the live version.

If possible, lower the DNS TTL in advance so the final propagation happens faster. Keep the old hosting account active for a short period after the switch in case you need to compare behavior or recover missing data.

FAQ

How long should I test a migrated website before going live?

For a small website, a few focused hours may be enough. For a larger CMS, e-commerce site, or multilingual platform, it is better to allow a full testing window with time for fixes, rechecks, and stakeholder review.

Do I need to test on mobile devices too?

Yes. Responsive layouts, menus, forms, and interactive elements can behave differently on mobile browsers. Test both iOS and Android if your audience uses them heavily.

Can I test the site without affecting visitors?

Yes. Use a hosts file override or staging subdomain so only your device sees the new server. This is the safest way to validate the site before changing public DNS.

What should I do if the site works on the old server but not on the new one?

Compare PHP version, extensions, file permissions, database credentials, rewrite rules, and application configuration. Review the error logs first, since they usually point to the exact cause.

Should I keep the old hosting account after migration?

It is a good idea to keep it available for a short transition period. This gives you time to verify DNS propagation, compare logs, and recover any missed files or email.

Is testing the same for WordPress, Magento, and custom sites?

The principles are the same, but the checks differ. WordPress sites often need database URL updates and plugin compatibility checks. Magento and other e-commerce platforms may require deeper cache, index, and checkout testing. Custom applications may need more attention to environment variables and server-side dependencies.

Conclusion

Testing a migrated website before going live is one of the most important parts of a successful move. It reduces the risk of outages, protects user experience, and gives you time to fix configuration issues while the old site is still available. In a managed hosting or Plesk-based environment, a methodical test of files, database, SSL, forms, redirects, and logs will usually reveal any hidden problems before your visitors do.

If you treat migration testing as a required step rather than an optional one, the final DNS switch becomes much less stressful and far more predictable.

  • 0 Users Found This Useful
Was this answer helpful?