Test migration

What to do with automated tests after a website redesign

A website redesign can change components, navigation and the order of steps without changing the main business objective. A user still buys, signs in or submits a form, but dozens of automated tests suddenly fail. This does not mean that every test is bad. They may simply describe the old HTML too precisely instead of describing product behaviour.

The worst response is a mass replacement of selectors until the report turns green. First distinguish four things: a genuine product regression, an intentionally changed user journey, a technically broken test and a data or environment problem. Only then decide what to repair, rewrite or remove.

Why a redesign breaks a “working” suite

A test can depend on details the user never sees: a particular CSS class, the third button in a container, nested elements or copy that marketing has changed. A new component performs the same function but has a different DOM structure. The test cannot find it and stops before checking the business rule.

Another group of failures is legitimate. A redesign may accidentally remove validation, change the default delivery option, hide an error or break keyboard operation. If every failure is labelled “test maintenance”, the suite overlooks exactly the regressions it was meant to detect.

The third case is a product change. The old checkout had three steps and the new one has one. The test should not restore the old workflow; it needs a new scenario and expectations. The team therefore needs the approved scope of the redesign, not only the finished screen.

Preparation should begin before deployment

If the test team learns about the redesign only after it reaches the main branch, most of the work becomes reactive. A better approach starts with an inventory of the existing suite and a change map.

Before implementation, or while it is underway, prepare:

• the key user journeys and risks that must remain protected;
• pages and components that will change;
• decisions about behaviour that remains or intentionally changes;
• tests coupled to old selectors, text or screenshots;
• an agreement on stable attributes and accessible names;
• a separate environment or preview URL for updating tests continuously;
• baseline results and known flaky tests on the old version.

The baseline run matters. If a test already failed before the redesign, its result should not be attributed to the new implementation. It also reveals which parts of the suite are trustworthy and which require repair independently of visual change.

Classify failures by cause

Do not create a single “fix 146 tests” task after the first run against the new site. Put every failure into at least one category:

Classification requires somebody who understands expected behaviour. AI grouping of similar stack traces can speed up orientation, but it cannot decide whether a new step matches product intent.

Locators should describe an element’s meaning

A locator such as .checkout > div:nth-child(3) button.primary copies implementation. A redesign moves the container or changes CSS and the test loses its target. Locators based on role, accessible name, field label or an explicit test identifier are more stable.

Playwright recommends user-facing locators, including role and name, and an explicit test ID where no suitable user contract exists. Its best-practice guidance warns that long CSS and XPath chains are tied to DOM structure and break easily when it changes.

This does not mean adding a test identifier to every element. Use the following priority:

1. role and accessible name where they reflect real use;
2. a stable label, placeholder or visible text when it is part of required behaviour;
3. an agreed data-testid for a technical element without an unambiguous user-facing name;
4. CSS or XPath only where a more suitable contract does not exist.

If two elements cannot be distinguished reliably from a user’s perspective, the interface may have a problem, not only the test. An accessible name helps automation and people using assistive technologies.

Hide component change behind a test layer

When fifty tests use the same selector or operation, it should not be repaired in fifty places. A Page Object Model or component objects centralise locators and core interactions. The article explaining the Page Object Model covers the pattern in more detail.

The abstraction should not copy every page detail. A method such as selectDelivery('courier') is more stable than public methods called clickThirdDiv, openDropdown and clickSecondItem. A test should read like a user or business flow; the page object handles interaction with the current component.

For a large redesign, build the new component-layer implementation alongside the old one. A scenario can temporarily select a variant by URL or feature flag. This is not a permanent architecture, but it lets the new site be verified without immediately disconnecting regression checks from the current production version.

Do not migrate everything mechanically

A redesign is a useful moment for inventory. A historical suite often contains duplicate scenarios, checks of removed functions and tests whose maintenance cost exceeds their information value. Repairing each one simply because it exists in the repository prolongs the transition and preserves old debt.

For each scenario, ask:

• which risk or business rule it protects;
• whether the check is still necessary at UI level;
• whether an API or integration test can verify the same rule faster and more precisely;
• how often the scenario revealed a relevant defect;
• whether its state and data can be prepared reliably;
• the repair cost now and maintenance cost at the next change.

Move key journeys first. Scenarios with no explainable value can be archived or removed with the risk owner’s agreement. Their history remains in version control.

Preserving regression coverage during transition

A separate test branch merged only on launch day is risky. New tests should run continuously against a preview environment. The original suite continues against the current version. The team sees two different facts: whether today’s production behaviour remains intact and whether the future version is ready.

Practical stages are:

1. restore a trustworthy baseline for the old suite;
2. map scenarios to the new user journeys;
3. update shared locators and components;
4. run smoke tests against every preview deployment;
5. add broader regression gradually and classify differences;
6. perform focused exploration, visual review, accessibility and cross-browser coverage before launch;
7. verify key production journeys with safe tests after deployment;
8. remove the old suite implementation only after an agreed stabilisation period.

This resembles parallel operation during a test-suite migration without losing regression coverage. The objective differs: in a redesign, the tool and language often remain, while the tested product and user-facing contract change.

Screenshots need a new approved baseline

Visual-regression tests naturally report many differences after a redesign. Automatically approving all new screenshots could save a defect as the new expectation. Create the baseline component by component or page by page and compare every difference with the design and functional behaviour.

Stabilise the viewport, fonts, animations, dates and dynamic data. Otherwise, unexpected differences disappear among thousands of expected ones. Visual review also does not replace assertions about content, state or accessibility; it detects a different class of risk.

Data and diagnostics determine repair speed

A redesign can also change form validation, feature-flag names or the way an in-progress state is prepared. Assess test data separately from locators. A stable test can create its prerequisite through an API, fixture or controlled setup and clean up afterwards.

For failures, retain the step, screenshot, console, network requests and deployment version in proportion to risk. This distinguishes a missing element from an API error, modal overlay or delayed load. Without evidence, every failure requires manual reproduction and the transition slows down.

When to repair and when to rewrite

A local repair is enough when the business flow is unchanged and only its stable interaction point moved. A rewrite is better when the sequence, component responsibility or expected result changed. If the original test accumulates conditions for both versions, a new clean scenario is usually clearer than another branch.

Do not decide by the number of changed lines. Decide by future readability and value. A test nobody understands after repair becomes an obstacle again at the next redesign.

What a successful update delivers

The objective is not the same test count as before. It is trustworthy protection of today’s risks, delivered in time and maintainable by the team. Shared locators reduce maintenance, continuous execution exposes differences during development, and inventory removes scenarios without value.

A redesign also tests the site’s testability. Agreed roles, names and stable identifiers improve the current repair and future tests. The guide on how to prepare a website for test automation describes these contracts before automation begins.

Next step

Run the existing suite against the old version and establish a trustworthy baseline. Select the five most important user journeys, map them to the new product flow and classify every failure in the first new-version run. Only then repair locators. This creates the first working regression layer without blindly carrying all historical debt into the redesigned site.