How to test a migrated site before going live

Testing is the step in a migration that people rush, because by the time you reach it the hard work — copying files, importing the database, editing configuration — already feels done. It is also the step that makes everything before it worth doing properly, because a problem found now costs nothing: the old site is still live, nobody else can see the new one yet, and there is no pressure.

Pages and navigation

• Load the home page and confirm it looks identical to the old site — layout, images and styling all present.
• Click through the main navigation, not just the links visible on the home page.
• Open a handful of inner pages picked at random, including ones a few levels deep in the site structure.
• Check that images and stylesheets are loading rather than showing as broken icons — a page with no styling at all usually means a CSS path is wrong or a file was missed in the copy.

Anything that submits data

This is the category most often skipped, because a form can look completely normal right up until someone clicks submit. Test each one properly:

• Contact and enquiry forms — submit a real test entry and confirm the email actually arrives, not just that the page shows a success message.
• Search — run a query and check results appear.
• Newsletter sign-up — if it connects to a third-party mailing list, confirm the connection still works from the new server.
• Login and registration — create or use a test account and confirm both work.
• Checkout, for a store — add an item to basket and get as far as the payment step, using test mode if the gateway offers one.

The admin area

Log into the CMS admin panel — WordPress, Joomla, or whatever the site runs on — and confirm you can sign in without errors. Once inside, check that the dashboard loads normally, that you can open and save a page or post, and that any media library shows existing images correctly. A working front end with a broken admin area is a common outcome of a database import that only partially completed.

Mixed content and broken links

Open your browser's developer console while browsing the new server and look for warnings about content loading over the wrong protocol, or requests failing entirely. Two things to look for specifically:

• Anything still pointing at the old server by IP address or hostname rather than a relative path.
• Internal links that assumed a URL structure the new server does not replicate — see keeping your URLs working after a move if any paths changed as part of the migration.

Email, without actually switching mail over

You cannot fully test incoming mail before DNS changes, since mail routing follows the domain's MX records the same way the website follows its A record. What you can test in advance is outgoing mail from the site itself — order confirmations, form notifications, password reset emails — since these usually rely on the server's own mail function or an SMTP connection rather than on where MX records point.

Performance, at a glance

Load a few key pages and get a rough sense of speed. You are not benchmarking here, just checking nothing is obviously and unexpectedly slow — a page that used to load quickly and now visibly lags is worth investigating before it becomes public, whether the cause is a missing cache, an unoptimised database import, or a PHP version mismatch.

What to do if something fails

Fix it and test again before moving on. Nothing found at this stage is urgent, because visitors are not affected yet — that is the entire advantage of testing before the switch rather than after. If a problem turns out to be serious enough that you are not confident in the new server, it is entirely fine to delay the DNS switch by a day; the old site keeps running exactly as before in the meantime.

Once everything passes

Move on to switching DNS, following the order in our full migration guide, and keep the old hosting account active for about a week afterwards regardless of how well testing went — that safety margin is unrelated to how confident you feel and exists purely because DNS takes time to reach everyone.