Migration visual testing: the systematic process of verifying a website's visual integrity before and after a migration (CMS change, framework switch, design overhaul, or infrastructure move), consisting of capturing a complete visual baseline of the old site and automatically comparing it with the new one to detect any unintended regression.
Every website migration is a gamble. You know this if you've lived through one. Whether it's a CMS switch, a move to a new front-end framework, or a complete design overhaul, the moment you flip from old to new is the moment problems appear.
And these problems aren't the ones you expect. It's not the homepage that breaks — everyone checks that. It's the Terms of Service page buried three navigation levels deep whose formatting has collapsed. It's the newsletter widget whose button became invisible because the background color changed. It's the 24-pixel margin between sections that dropped to 0 on mobile because a CSS reset from the new framework overrode the old styles.
According to a Semrush analysis, a poorly executed site migration can cause a 10 to 30% drop in organic traffic in the weeks that follow — and part of that drop comes directly from interface issues that degrade the user experience and increase bounce rates. Visual regressions are one of the most overlooked causes, as visual bugs carry a measurable business cost that compounds over time.
Visual testing is the only reliable method to systematize before/after migration verification. And yet, most teams still skip it.
Why Migrations Are the Moment of Maximum Risk
A migration is not a standard deployment. In a standard deployment, you modify one part of the system and the rest stays put. In a migration, everything moves at the same time — or almost. And it's that "almost" that's dangerous.
The Volume of Changes Is Unmanageable Manually
Take a CMS migration: from WordPress to a headless CMS like Strapi or Contentful, for example. The content is migrated, the templates are rewritten, the routing system changes, WordPress plugins disappear and are replaced by custom code or third-party integrations. Every page on the site is potentially affected.
If your site has 50 pages, manually checking each one on desktop and mobile takes days. If your site has 500 — which is common for an e-commerce site or a multilingual corporate site — a complete manual check is simply impossible within a realistic project timeline.
The result: teams check the 10 main pages and hope the rest holds. That's a strategy based on hope, not rigor. A better approach is to use a systematic before/after comparison — our article on how to compare two versions of a website covers the methodology in detail.
The Regressions Are Subtle
Post-migration visual bugs aren't 500 errors or blank pages. They're subtle degradations that nobody notices until a user — or worse, a customer — reports them.
A spacing that goes from 16 pixels to 12 pixels. A font weight that drops from 400 (regular) to 300 (light). A CSS gradient that no longer renders because the syntax slightly changed between the old and new framework. A border-radius that disappears on product cards. A box shadow that fades because the CSS property was overridden by a more aggressive reset.
Individually, each of these regressions is minor. Collectively, they give the impression that the site has "lost quality" without anyone being able to pinpoint a specific issue. It's death by a thousand cuts for perceived quality.
Functional Tests Don't Cover the Visual
Your functional test suite verifies that the "Add to Cart" button works, that the contact form submits, that the 301 redirect fires correctly. That's necessary. But no functional test verifies that the "Add to Cart" button is still green with an 8-pixel border-radius and a 16-pixel margin below the price.
Functional tests answer the question "does it work?". Visual testing answers the question "does it look like what it should?". During a migration, both questions are critical. Our article on visual testing vs functional testing explores why covering only one leaves dangerous blind spots.
Migration Types and Their Specific Visual Risks
Not all migrations create the same risks. Here are the most common scenarios and their typical associated visual regressions.
Design Overhaul: The Highest Risk
A design overhaul is by far the most visually risky migration. It's also the most common: according to a HubSpot survey, companies redesign their website on average every two to three years.
In an overhaul, everything is supposed to change — that's the point. But "everything changes" doesn't mean "nothing needs to be checked." The creative brief says "new header, new footer, new color palette." It doesn't say "the terms and conditions text can lose its formatting" or "old blog posts may have images that no longer display correctly in the new layout."
Typical design overhaul regressions include old content that doesn't adapt to the new layout (text too long, images at the wrong ratio), secondary components forgotten in the overhaul (error pages, transactional emails, popups, modals), interactive states that change inconsistently (hover, focus, active on buttons and links), and responsive breakpoints that no longer match the same viewports.
CMS Migration
Switching from WordPress to Contentful, from Drupal to Strapi, from Magento to Shopify — every CMS migration involves rewriting the templates that produce the HTML and CSS. The content theoretically stays identical, but the visual rendering can change unexpectedly.
The specific risks of a CMS migration are rich content (WYSIWYG) that loses its formatting during transfer, CMS-specific shortcodes or widgets that aren't migrated, images that change dimensions or compression quality, and resource URLs (CSS, images, fonts) that break in the new system.
Front-End Framework Migration
Moving from jQuery to React, from AngularJS to Vue, from React class components to Next.js App Router — these migrations fundamentally change how HTML is generated and CSS is applied.
The main risk is the rendering difference between the old and new framework, even with the "same" CSS. Each framework has its own CSS scoping mechanisms, animation management, and conditional rendering. The CSS-in-JS from the old framework doesn't necessarily produce the same result as CSS Modules in the new one.
Infrastructure Migration
Changing hosting providers, moving from a dedicated server to a CDN, migrating from AWS to GCP — these changes should theoretically change nothing about the visual rendering. In theory.
In practice, server configuration differences (image compression, cache headers, Node.js versions for SSR) can produce subtle visual differences. A server that compresses JPEG images at 80% instead of 85% produces slightly different images. SSR rendering on a different Node.js version can generate slightly different HTML if the code uses version-dependent features.
The Method: Before/After Migration Visual Testing
The principle is simple and powerful: capture a complete visual snapshot of the old site, then systematically compare with the new one. Every difference is detected, analyzed, and classified as intentional or regression.
Step 1: Capture the Baseline on the Old Site
Before touching anything, capture the complete visual state of your current site. This is your baseline — your source of truth.
Which pages to capture? Ideally, all of them. In practice, prioritize based on traffic and business importance. Start with pages that generate significant organic traffic (check Google Analytics 4 or Search Console), conversion pages (signup, purchase, quote request), the homepage and main navigation pages, and unique templates (each page type: article, product, category, landing page).
On which viewports? At minimum desktop (1440px or 1920px) and mobile (375px or 393px). If your tablet audience is significant, add an intermediate viewport (768px or 1024px).
When to capture? As late as possible before the migration, so the baseline reflects the most recent state of the site. But not on the day of the switch itself — you need time to verify that the captures are complete and correct.
This baseline is your safety net. Treat it with the same seriousness as a database backup before migration.
Step 2: Prepare the Comparison
Before comparing, identify the intentional changes. If you're doing a design overhaul, the new header will be different from the old one — that's the point. Document these expected changes so you can distinguish them from regressions during comparison.
Create a list of areas that will change intentionally and configure your visual testing tool to treat them separately. The goal is to focus your attention on unintentional differences — the real regressions.
Step 3: Capture the New Site and Compare
Once the new site is deployed (in a staging environment, not production), capture the same pages on the same viewports and run the comparison against the baseline.
Each detected difference falls into one of these categories.
Intentional change: the new design is different, that's expected. You validate and update the baseline.
Regression: something changed that shouldn't have. You create a ticket and fix it before going to production.
Gray area: a subtle change you're not sure is intentional or accidental. You consult the designer or project manager for clarification.
Step 4: Iterate Before Going to Production
The first comparison will reveal dozens, even hundreds of differences. That's normal. The work is to sort them, fix the regressions, and run the comparison again until the only remaining differences are intentional.
This iterative process is exactly what automated visual testing makes viable. Doing this sorting manually across 100 pages would be exhausting and error-prone. With a tool that highlights differences and lets you validate or reject them one by one, it's methodical and reliable.
Step 5: Post-Migration Monitoring
The migration doesn't stop on the day of the switch. In the days and weeks that follow, additional problems can appear — a cache that clears and reveals a hidden issue, old content that goes through an untested rendering path, an interaction between new code and a popular browser extension.
Maintain regular visual monitoring for at least two weeks after the migration. The new baseline is the validated new site, and any deviation from this baseline is an alert.
What Delta-QA Brings to a Migration Context
Delta-QA is particularly well-suited for migrations for several structural reasons.
Baseline capture without code. You don't need to configure a CI/CD pipeline to capture the old site. You open Delta-QA, navigate your site, and the tool captures each page. It's an operation any team member can perform — the project manager, the tester, the designer.
Structural comparison. Delta-QA's 5-pass algorithm doesn't compare images. It compares computed CSS properties — dimensions, colors, fonts, spacing, positions. When it tells you "the margin between the Hero section and the Features section went from 64px to 48px," you know exactly what to check and fix.
This approach eliminates the false positive noise from rendering differences that plague pixel diff tools during migrations. A framework change can slightly modify font anti-aliasing without changing CSS properties — a pixel diff tool would flag a change on every text on every page. Delta-QA will ignore these cosmetic differences and focus on real structural changes.
Zero infrastructure. In a migration context, the team is already overloaded. Adding a tool that requires a pipeline, a cloud account, SDK integration, and maintenance means adding complexity at the worst possible time. Delta-QA installs in minutes and works immediately, locally, without external dependencies.
Classic Mistakes to Avoid When Testing a Migration
Experience shows that certain mistakes come up systematically. Knowing them helps you avoid them.
Not capturing the baseline in time. If you capture the baseline after starting the migration, you no longer have a reliable reference of the old site. Capture before any modification, and keep those captures safe.
Testing only on one environment. The staging site may behave differently from the production site — different URLs, different data, different server configuration. Ideally, test both in staging and in production (after the switch) and compare both against the baseline.
Ignoring low-traffic pages. The "About" page with 50 visits per month isn't a business priority. But if it's visually broken, it's a negative quality signal for every visitor who sees it — including prospects evaluating your credibility. Low-traffic pages are often the first forgotten and the last fixed.
Forgetting authenticated states. Many sites have a different experience for logged-in and logged-out users. If you only test the logged-out state, you miss regressions in the dashboard, profile, settings — pages your existing customers use daily.
Relying solely on user feedback. "We'll see if users report problems" is not a QA strategy. Users don't report subtle visual issues — they leave silently. You'll only see the consequence in bounce rate and conversion metrics, weeks later, when it's too late to isolate the cause.
Visual Testing Checklist for a Migration
Here's a checklist you can follow to structure your visual testing approach for your next migration.
Before the migration:
- List all unique pages and templates on the site
- Capture baselines on desktop and mobile for each page
- Verify that captures are complete and correct
- Document the expected intentional changes
- Identify dynamic zones to exclude from comparison (dates, counters, personalized content)
During the migration (staging):
- Capture the same pages on the new staging site
- Compare against baselines and sort the differences
- Fix identified regressions
- Re-run the comparison after fixes
- Iterate until only intentional changes remain
After the migration (production):
- Capture the production site within hours of the switch
- Compare against validated staging baselines
- Check often-forgotten low-traffic pages
- Monitor visually for two weeks
- Update definitive baselines for ongoing surveillance
FAQ
How far before the migration should you capture the baseline?
Ideally, capture the baseline one to two weeks before the planned migration date. This gives you time to verify that captures are complete and resolve any capture issues (pages requiring authentication, dynamic content to stabilize). If your site changes frequently, recapture the baseline a few days before the switch to have the freshest possible reference.
How do you handle intentional changes during the before/after comparison?
Document expected changes before running the comparison. When analyzing results, address unexpected differences first — those are your priority regressions. Intentional changes can be validated in bulk and used to update the baseline. Some tools like Delta-QA allow you to exclude specific zones from the comparison to ignore elements that are changing on purpose.
Is visual testing enough to validate a migration?
No. Visual testing covers interface integrity — what the user sees. But a migration also involves verifying 301 redirects, technical SEO (robots.txt, sitemap, canonical tags, structured data), application functionality (forms, payment, authentication), and performance. Visual testing is a pillar of validation, not the entire validation.
What's the difference between a pixel diff tool and a structural tool for testing a migration?
A pixel diff tool overlays two screenshots and flags different pixels. It's sensitive to font rendering, anti-aliasing, and micro-variations — which generates lots of false positives during a migration where the rendering engine changes. A structural tool like Delta-QA compares computed CSS properties (dimensions, colors, positions). It detects real layout and style changes without being polluted by cosmetic rendering differences.
How do you test pages that require authentication?
Log into your application before capturing baselines, then stay logged in throughout the capture session. With a desktop tool like Delta-QA, you navigate your application normally — authentication works exactly like a real user. Capture authenticated pages as a journey: login, navigate to the dashboard, profile, settings.
How many pages should you test during a migration?
Ideally, all pages with a unique template. A site with 500 pages but 15 different templates can be effectively covered by testing a representative sample of each template — at minimum the most-visited page of each type. For e-commerce sites, add product pages with varied characteristics (long/short titles, with/without images, with/without promotions) to cover template edge cases.
Conclusion
A migration is a major investment for your business — in time, budget, and risk. Not systematically checking the visual result of this investment is a choice that nothing justifies when the tools exist to do it efficiently.
Before/after migration visual testing transforms a hope-based process ("it should be fine") into an evidence-based process ("here's exactly what changed, here's what's validated, here's what needs fixing").
Your next migration deserves better than partial manual checks and silent prayers.