The single most important habit in migration is testing your migrated site on the new host before you point your domain at it — because it is the one thing that guarantees the cutover sends visitors to a working site rather than a broken one. Every migration that ‘went wrong’ publicly is really a migration where someone cut over first and tested afterward. Reverse that order, and problems are caught while they are still invisible to the world. This guide shows you exactly how to test thoroughly before going live.

You will learn why pre-cutover testing is the linchpin of a safe migration, how to view the new site privately while your domain still points to the old host, a full checklist of what to test, how to spot the classic migration problems, testing behind-the-scenes things like email and forms, and how to decide the site is genuinely ready to go live. By the end you will know how to verify a migrated site so the cutover holds no surprises.

Why testing before cutover is the linchpin

Testing the migrated site before cutover is the linchpin of a safe migration because of a simple sequencing truth: whatever state your new site is in when you cut over, that is what visitors immediately get. If it is broken and you cut over, visitors hit the breakage; if it is verified working and you cut over, visitors hit a working site. Testing first is what ensures the latter.

The reason this works so well is that before cutover, your domain still resolves to the old host, so the new site is invisible to the public while you test it. Every problem you find and fix in this window has zero public impact — the world is still being served the perfectly functional old site. You have a private staging period, built into the migration, in which to catch and fix everything.

So the entire safety of the cutover rests on this: use the private pre-cutover window to verify the new site fully, so the switch is a flip to a confirmed-working destination. The migrations that fail publicly are the ones that inverted this — cutting over to an untested site and discovering the broken images or database error only once real visitors were hitting it. Test first, switch second, and you eliminate the single biggest source of visible migration failure.

Viewing the new site privately

To test before cutover, you need a way to see the new site specifically, while your domain still points to the old host. There are a few standard methods, and the best one shows you the site exactly as it will behave under your real domain:

• Hosts-file preview (best): edit your computer’s hosts file to map your domain to the new server’s IP, so only your machine sees the new site under your real domain, while everyone else still sees the old — the truest preview.
• Temporary URL: many hosts provide a temporary address that serves your new site directly, letting you check it without touching DNS.
• Staging environment: if you built the migrated site in a staging area, test it there before pushing live.
• Raw server IP (limited): visiting the server’s IP can work for simple sites but often misbehaves with domain-based links, so it’s a rough check at best.

The hosts-file method is the gold standard because it makes your computer resolve your real domain to the new server, so you see the site under its actual domain name — catching URL and link issues that a temporary URL or IP might mask, since those show the site under a different address. Whichever method you use, the goal is the same: a realistic, private view of the new site to test thoroughly before any of the public is routed to it. This private view is what makes pre-cutover testing possible.

The full testing checklist

With a private view of the new site, work through a thorough checklist rather than a glance at the homepage — the classic mistake is checking the front page loads and assuming everything else is fine. Test the breadth and depth of the site: load a range of pages and posts (not just the homepage) and confirm their content is correct and complete; check that images load and display; and confirm styling and layout look right everywhere.

Then test the interactive elements: click internal links to confirm they resolve correctly (not back to the old site); submit a contact form and confirm it works and the submission arrives; try logging in to any account or admin area; and if you have e-commerce, add an item to the cart and run through checkout. Check any dynamic features, search, filters, or special functionality the site has.

So the checklist spans visual (pages, images, styling), navigational (internal and key external links), and functional (forms, logins, checkout, dynamic features) — a genuine click-through of everything that matters, across a representative range of the site. This thoroughness is what turns ‘the site loaded’ into ‘the site works,’ and it is the difference between catching a broken checkout or missing images now, privately, versus discovering them from angry visitors after cutover. The more comprehensively you test here, the fewer surprises the cutover holds.

Spotting the classic migration problems

Certain problems recur after migrations, and knowing their signatures lets you spot and diagnose them quickly during testing. The most common is missing images or broken styling, which almost always means the URL search-and-replace was incomplete — the site is still trying to load assets from the old location. The fix is to run (or re-run) a proper database search-and-replace to update stored URLs.

Another classic is the ‘Error establishing a database connection’ full-page message, which after a migration nearly always means the config file (wp-config.php) has wrong database credentials — check the name, user, password, and host against the new database. Links pointing back to the old site are again a stored-URL problem (search-and-replace). A white screen or internal server error often points to a file-permissions problem or a configuration issue on the new host.

So as you test, read the symptoms: missing images or broken styling to stale URLs (search-and-replace), a database-connection error to wrong config credentials, links back to the old site to stored URLs, a white screen to permissions or configuration. Recognising these signatures turns testing from ‘something is wrong’ into ‘this specific thing is wrong, and here is the fix.’ Catching and diagnosing them now, privately, is exactly what the pre-cutover window is for — each one fixed here is a public disaster averted.

Testing behind-the-scenes things

Beyond what you can see, test the behind-the-scenes functionality that a visual click-through misses but that matters enormously. Email is the biggest: if your site sends email (contact-form notifications, order confirmations, password resets) or you use email on your domain, confirm it works — though note that some email routing depends on DNS that only takes effect after cutover, so plan to re-test email immediately post-cutover too.

Test forms end to end, not just that they display: submit them and confirm the submission actually arrives where it should. Test any integrations the site has — payment gateways (with a test transaction), analytics tracking, third-party services, APIs — since these can break in a migration through changed configuration or keys. Check that scheduled tasks, if any, are set up on the new host.

So the behind-the-scenes testing covers email flow, form delivery, integrations, transactions, and any automated processes — the functional plumbing that a visitor-facing click-through does not reveal but that is essential to the site actually working. Some of this (especially anything DNS-dependent like email) needs re-testing right after cutover, but verifying as much as possible beforehand, and knowing what to re-check after, ensures the invisible parts of your site work as well as the visible ones. A site that looks perfect but silently fails to send order confirmations is not actually ready.

Deciding the site is ready to go live

The site is ready to go live when your testing has confirmed everything works — visually, navigationally, functionally, and behind the scenes — with no outstanding problems, or only ones you have consciously decided are acceptable and will address (like DNS-dependent email that can only be fully confirmed post-cutover). The decision to cut over should be a confident ‘I have verified this works,’ not a hopeful ‘it looked okay.’

Concretely, you are ready when: your representative range of pages loads with correct content, images, and styling; internal and key links resolve to the new site; forms, logins, and any checkout work; the classic problems are absent or fixed; and behind-the-scenes functions are verified as far as they can be pre-cutover, with a clear plan to re-check the DNS-dependent ones (email especially) immediately after. That is a genuinely tested site.

So make the go-live decision on the basis of completed testing, not optimism. If testing surfaced problems, fix them and re-test before cutting over — never cut over with known breakage, since that just sends visitors to the very problems you found. The whole value of pre-cutover testing is that it lets you cut over from a position of verified confidence, so the switch holds no surprises. When your checklist is clean and you have a plan for the DNS-dependent re-checks, the site is ready — and the cutover becomes the calm, safe flip it should be.

FAQs

How do I test a migrated site before going live?

View the new site privately while your domain still points to the old host — the best way is a hosts-file preview that maps your domain to the new server’s IP so you see it under your real domain. Then work through a full checklist: pages, images, styling, internal/external links, forms, logins, checkout, and behind-the-scenes things like email and integrations. Fix any problems privately, then cut over only once everything’s verified.

Why test before cutover instead of after?

Because whatever state the new site is in when you cut over is what visitors immediately get. Before cutover, your domain still points to the old host, so the new site is invisible to the public and every problem you fix has zero impact. Migrations fail publicly when people cut over first and test afterward, discovering breakage only once real visitors hit it. Test first, switch second.

How do I preview my new site before changing DNS?

The gold-standard method is a hosts-file preview: edit your computer’s hosts file to map your domain to the new server’s IP, so only your machine sees the new site under your real domain while everyone else still sees the old. Alternatives are the host’s temporary URL or a staging environment. The hosts-file method shows the site under its actual domain, catching URL/link issues others might mask.

What should I test on a migrated site?

Visual: a range of pages and posts (not just the homepage), images, and styling. Navigational: internal links and key external links resolve to the new site. Functional: forms (submit and confirm arrival), logins, and checkout if you have e-commerce. Behind-the-scenes: email flow, integrations, payment gateways (test transaction), analytics, and scheduled tasks. A genuine click-through of everything that matters, not a homepage glance.

What are the classic problems to look for after migrating?

Missing images or broken styling (usually an incomplete URL search-and-replace — stale URLs), ‘Error establishing a database connection’ (wrong credentials in wp-config.php), links pointing back to the old site (stored URLs, again search-and-replace), and a white screen or internal server error (often a file-permissions or configuration problem). Knowing these signatures lets you diagnose and fix quickly during testing.

How do I know the site is ready to go live?

When testing has confirmed everything works — pages, images, styling, links, forms, logins, checkout, and behind-the-scenes functions — with no outstanding problems except consciously accepted DNS-dependent ones (like email you’ll re-check post-cutover). The go-live decision should be a confident ‘I’ve verified this works,’ not ‘it looked okay.’ If testing found problems, fix and re-test before cutting over; never cut over with known breakage.

The bottom line

Testing a migrated site before going live is the single most important habit in migration, because of a simple truth about sequencing: whatever state your new site is in at the moment you cut over is exactly what visitors immediately get. Test first and it is a confirmed-working site; cut over untested and it is whatever breakage you never checked for. The reason this works is that before cutover your domain still resolves to the old host, so the new site is invisible to the public — giving you a private window, built into every migration, in which to catch and fix every problem with zero impact. The best way to use that window is a hosts-file preview, which makes your computer resolve your real domain to the new server so you see the site exactly as it will behave live, catching URL and link issues a temporary URL or raw IP would mask.

With that private view, test thoroughly rather than glancing at the homepage: a representative range of pages, images, and styling; internal and key links resolving to the new site; forms, logins, and checkout; and the behind-the-scenes plumbing — email flow, integrations, payment gateways, analytics — that a visual click-through misses (re-checking the DNS-dependent parts, email especially, right after cutover). Learn the signatures of the classic problems so you can diagnose fast: missing images or broken styling point to an incomplete URL search-and-replace, a database-connection error to wrong config credentials, links back to the old site to stored URLs, a white screen to a permissions or configuration issue. Fix everything you find, re-test, and make the go-live decision from a position of verified confidence — never cut over with known breakage. Do that, and the cutover holds no surprises: it becomes the calm flip to a site you already know works.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Test a migrated site before cutover by viewing it privately (a hosts-file preview mapping your domain to the new server’s IP is best) while your domain still points to the old host. Run a full checklist — pages, images, styling, links, forms, logins, checkout, and behind-the-scenes email/integrations. Diagnose classic problems (stale URLs, wrong wp-config credentials, permissions). Fix everything, then cut over from verified confidence, never with known breakage.