Website Migration Testing Checklist (with Visual QA)

Most website migration checklists are written by SEO agencies, and they are good at what they cover: redirect maps, canonical tags, crawl budgets, keeping rankings. What they skip is the question the client actually asks on launch day: does every page still look right?

That question is hard to answer by hand. A migration touches every page at once — new CMS, new theme, new hosting, sometimes all three — and the team checks the homepage, five landing pages and the contact form, then ships. The broken pages are the ones nobody opened: the 2019 event listing with a custom embed, the pricing table built in a plugin that did not survive, the landing page whose hero image was hard-coded to the old domain.

This checklist is organised around the migration timeline, and it treats visual QA as a first-class step rather than a spot check. It applies to any migration — Drupal 7 to Drupal 10/11, WordPress to Drupal, a re-platform to Astro or Next.js, or just a move from one host to another — because the method is the same: capture the old site, capture the new one, compare URL by URL.

Phase 1: Before you migrate, inventory what you have

You cannot verify a migration against a site you never measured. Everything below happens on the old site while it is still live.

Build the full URL list

Do not trust the CMS’s page count. Crawl the site and collect every URL that returns a 200: content pages, taxonomy and tag pages, paginated listings, PDFs, media pages, and the odd landing page marketing built two years ago. Cross-reference the crawl with the XML sitemap and with Google Search Console’s Pages report, because each source misses things the others catch.

In Diffy, the project scan turns that into a page list without copy-pasting: point it at the site’s sitemap.xml (sitemap indexes work too) or at any page and it extracts the URLs into the project. Review the list, delete the 300 tag pages you do not care about, and save. That list becomes the spine of every later step.

Rank the pages

A 4,000-URL site does not get 4,000 pages of manual QA. Split the list into three tiers:

Tier 1 — must be pixel-checked. Homepage, top landing pages by traffic (Search Console or analytics, last 12 months), every page in the main navigation, conversion pages (pricing, contact, checkout, signup), legal pages.
Tier 2 — one representative per template. One article, one product, one event, one author page, one taxonomy listing. If the template renders correctly for one node, it is very likely correct for the others.
Tier 3 — everything else. Automated checks only: status codes, redirects, and a visual comparison you review by exception.

The tiering matters because it decides how much of the review is human. Tier 1 and 2 get looked at by a person. Tier 3 gets looked at only when the tooling flags something.

Take a baseline of the old site

This is the step most teams skip, and it is the one you cannot do later. Once the old site is gone, there is no reference to compare against.

Screenshot every URL in the list, at every breakpoint you support, on the live production site. In Diffy this is a single screenshot run against the production environment; the ten preset breakpoints from 320px to 1920px cover most sites, and you can add your own. Keep the run — it is the “before” half of every comparison you will make for the next two months.

If parts of the old site require a login (member areas, intranet sections), configure the login now, while you still know the old site’s login form. The screenshots behind the login are the ones nobody will remember to check otherwise.

Record the non-visual facts

While you are on the old site, capture the things a screenshot does not show: page titles and meta descriptions, canonical URLs, hreflang tags, structured data, robots directives, and the response headers that matter (caching, security headers). A crawler export is enough. You will diff this list against the new site in Phase 3.

Phase 2: Migrate, then test on staging

Run the migration into a staging environment that is as close to production as you can make it — same hosting, same CDN configuration, same PHP or Node version. Migrations that were tested on a developer laptop and then deployed to a different stack are where the surprising bugs come from.

Staging is usually locked down. Diffy handles HTTP basic auth and custom cookies in the project settings, so the staging site does not have to be public for the screenshots to work.

Content parity

Before you look at pixels, confirm the content arrived:

Row counts per content type: 1,240 articles in, 1,240 articles out. Any gap is a migration script bug, not a design issue.
Spot-check fields that migrate badly: rich text with embedded media, dates and time zones, references between entities, files and their alt text, redirects that lived in the old CMS as content.
Search the new site’s database for the old domain. Hard-coded absolute links and image paths are the single most common leftover.
Check taxonomy: terms exist, are attached to the right content, and the listing pages are not empty.

Visual parity, URL by URL

Now compare the two sites. Set the old production site as one environment and staging as the other, and run a comparison over the full URL list at every breakpoint. Diffy compares the same path on both base URLs, which is exactly what a migration needs: /about on the old site against /about on the new one, times four thousand, in a few minutes.

What you are looking for depends on what changed:

Same design, new platform. This is the easy case and the most common one for host-to-host and Drupal 7 to 10 migrations that keep the theme. Everything should match, and every diff is a bug until proven otherwise. Expect small, legitimate differences from font rendering or a newer browser engine. Diffy’s default custom highlight comparison is built for this: it ignores content that merely shifted down the page and highlights what actually changed, and you can switch any diff to pixel perfect when you need it strict.

New design. Every page will differ, so a raw pixel diff is useless. Change the question from “is it identical?” to “is everything still there?” — compare old and new side by side in the review UI and check for missing sections, images that did not load, empty components, and content that was truncated by a new field length. The tiered page list from Phase 1 is what keeps this manageable: you review Tier 1 and one page per template in Tier 2 carefully, and skim Tier 3 for pages that look empty or broken.

Mixed. Most migrations are actually this: the same design with a new header and footer, or a new design on the homepage and untouched templates elsewhere. Use mask and exclude to hide the regions you changed on purpose, so the comparison only reports the changes you did not intend. A redesigned header masked out of every page turns a wall of red diffs into a short list of real problems.

Whichever case you are in, use the same rules that keep visual testing honest anywhere else: freeze carousels, mock dates and dynamic content, hide cookie banners. Our guide to avoiding false positives covers the settings. A migration is a bad time to learn them, so set them up on the baseline run in Phase 1.

Review as a team, not as a developer

The person who wrote the migration script is the worst person to review its output — they know what should be there and their eyes fill it in. Diffy’s review UI lets a content editor or project manager go through the diffs, approve the expected ones, and mark the rest as bugs, without touching code. On a large migration, splitting the page list between three reviewers by tier is a good use of an afternoon.

The AI summary of a comparison is useful here as a first pass: it splits what changed into critical and minor items, each listing the pages and breakpoints affected, so a footer change that touched 900 pages reads as one line with 900 references instead of 900 separate diffs.

Everything a screenshot cannot see

Run these in parallel with the visual review:

Redirects. Every old URL that changed should return one 301 to the correct new URL — not a chain, not a 302, not a soft 404. Test the whole redirect map with a crawler or a script, not by hand.
Status codes. Crawl the new site: no 404s from internal links, no 500s, no pages accidentally returning noindex.
Metadata. Diff the titles, descriptions, canonicals, hreflang and structured data you exported in Phase 1 against the new site.
Forms and integrations. Submit every form. Check the CRM, the email service, the payment gateway, and analytics received the event.
Performance. Lighthouse on Tier 1 pages, old versus new. A migration that doubles Largest Contentful Paint is a regression even if it looks identical.
Search. Site search returns results and the index is rebuilt.
Files. Every PDF, download and image URL that was linked externally still resolves (or redirects).

Where URLs change

Path-based comparison assumes the URL structure is preserved, which it should be wherever possible — changing URLs is the most common way migrations lose search traffic. Where slugs genuinely have to change, Diffy cannot pair /old-slug on one site with /new-slug on the other automatically; the same path list is used on both sides. Handle those pages separately: keep the old-to-new mapping in a spreadsheet, verify every redirect with a script, and review the changed pages by hand or in a small dedicated project. The list of changed URLs is usually short enough for this.

Phase 3: Launch, then keep watching

Launch day is not the end of testing. DNS propagates unevenly, caches warm up, cron jobs run for the first time, and editors start touching content on the new platform.

Immediately after cutover, rerun the Tier 1 comparison against the new production domain. Staging and production are never quite the same — a CDN rule, an environment variable, a missing image bucket permission — and the cost of this run is a few minutes.

For the next two weeks, put the site on a schedule. Diffy’s scheduled monitoring takes a fresh set of screenshots on the days and times you pick and compares them with the previous run, so you hear about the broken page from Slack rather than from a customer. It catches the slow-burn issues: a cache that expired and exposed an unstyled page, a plugin update that ran automatically, an editor who pasted a table from Word. Our post on baselines for monitoring versus pull requests explains how the baseline moves forward as you approve changes.

Watch Search Console for the same two weeks: coverage errors, a spike in 404s, and the crawl of the new sitemap. If rankings dip, the visual and redirect records from Phases 1 and 2 are how you find out whether it is a content problem or a technical one.

Keep the old baseline. Do not delete the Phase 1 screenshots at launch. Questions like “was the sidebar always that narrow?” come up a month later, and the old screenshot set is the only place the answer lives. Check your plan’s retention period: paid plans keep screenshots for six months, the free plan for one, so download the Tier 1 screenshots if the project will run longer than that.

The checklist

Copy this into your project tracker.

Before migration

Crawl the old site; merge with sitemap and Search Console to get the full URL list
Tier the list: must-check pages, one per template, everything else
Baseline screenshots of every URL at every breakpoint on old production
Configure logins, cookies, masks and dynamic-content fixes now, not later
Export titles, descriptions, canonicals, hreflang, structured data, headers
Write the redirect map for every URL that will change

On staging

After launch

Tier 1 comparison rerun against the live domain
Scheduled visual monitoring for at least two weeks
Search Console coverage and 404 reports checked daily
Old baseline screenshots kept

Frequently asked questions

How long does visual QA add to a migration? Less than the manual alternative. Capturing 2,000 URLs at six breakpoints is an unattended job — you start it and come back to results — and reviewing the flagged pages is a few hours for a team of two or three. Clicking through 2,000 pages by hand at one breakpoint takes days and misses more.

We are redesigning at the same time. Is visual comparison still worth it? Yes, but for a different reason. You are not checking that pages match; you are checking that nothing is missing. Side-by-side review with masks on the redesigned regions finds empty components, broken embeds and truncated content faster than opening pages one at a time — and the old-site baseline is still your only record of what content each page used to have.

Our staging site is behind a firewall. Can it still be tested? Diffy supports HTTP basic auth, custom cookies and headers, and login sequences in the project settings, and you can allow Diffy’s IP addresses through a firewall. If staging is on a private network with no public route at all, screenshots can be taken from inside the network — with Diffy’s local screenshot worker or any tool — and uploaded to the project for comparison.

What about Drupal 7 to Drupal 10 or 11 specifically? The method is identical; the failure modes are just well known. Expect differences from the new theme layer (Twig instead of PHPTemplate), CKEditor 5 rewriting inline markup, missing contributed modules that rendered a field in a particular way, and Views that migrated with a different pager or sort. Our Drupal visual regression testing page covers the Drupal-specific setup.

Do we need a paid plan for a one-off migration? A free Diffy account includes 500 screenshots, which covers a small site or the Tier 1 pages of a larger one. For a full-site migration, a monthly plan for the months of the project is usually enough; there is no annual commitment required. See pricing.

If you are planning a migration and want a second opinion on the test plan, start a free project, scan the old site’s sitemap, and you will have the URL inventory from step one in about ten minutes.