A UI Migration Should Not Mean a Test Rewrite

Yes, intent-based test execution can survive a component library migration without code changes.

But only when the tests are anchored to user-visible intent, not to implementation detail dressed up as intent.

That distinction is the whole story.

Teams usually discover this problem the hard way. They swap Material UI for Radix, move from Chakra to a custom design system, or rebuild form controls around headless components. The product may still look and behave the same to users, but the DOM changes completely. Class names vanish. Element nesting shifts. IDs get regenerated. A selector-heavy test suite collapses overnight.

That is exactly the kind of change intent-based execution is supposed to absorb.

What survives a migration

A good intent-based test does not care that a button is now rendered by a different component tree. It cares that a user can still click “Sign in”, enter an email address, open the account menu, or submit the checkout form.

If those user-facing contracts stay stable, the test should stay stable too.

This is why intent-based execution is fundamentally stronger than selector-based automation during migrations. It resolves actions against what the interface means in the moment, not what the markup happened to look like when the test was written.

That last row matters. Not every failure is bad. Sometimes the test should fail because the product contract changed.

What actually makes these tests durable

Intent-based execution survives migrations when three things remain true.

The user language stays consistent

If a flow still says “Email,” “Password,” and “Sign in,” the system has stable cues to work from. If the migration also rewrites labels, placeholders, and button copy, you changed the interface contract, not just the component library.

The UI remains semantically legible

This is where many migrations go wrong. Teams replace native elements with heavily customized components and accidentally strip away clear roles, labels, or relationships. If a control no longer presents itself clearly as a button, combobox, dialog, or input, both accessibility and test resilience get worse at the same time.

The flow is still uniquely identifiable

“Click Save” is easy when one Save button exists. It becomes messy when a page suddenly has four. Intent-based systems are strongest when screens are designed with clear hierarchy and distinct actions. Ambiguity in the product creates ambiguity in the test.

When “no code changes” is the wrong expectation

There is a lazy version of this promise that should be rejected.

If your migration changes behavior, wording, layout meaning, or business flow, some tests should be updated. A checkout flow that adds a confirmation step is a new flow. A settings page that splits one form into three panels is a different interaction model. Pretending those changes should require zero maintenance is how teams end up with dishonest tests.

The better standard is this:

A component library migration should not force test rewrites when the user journey is materially the same.

That is realistic, and it is the benchmark worth holding vendors to.

How to evaluate whether your suite will survive

Before a migration, inspect a few critical flows and ask:

• Are tests written around user actions or DOM paths?
• Do controls expose clear labels and roles?
• Are repeated actions distinguishable in context?
• Does the migration preserve the same user-facing copy?
• Are assertions checking outcomes users care about, not implementation trivia?

If the answers are mostly yes, intent-based execution has a real chance to carry you through with minimal or no code changes.

If the answers are no, the migration will expose a deeper problem: your tests were never modeling user intent in the first place.

That is why this question matters so much for teams evaluating modern QA platforms, including Shiplight AI. The real value is not “AI” as branding. It is whether your test suite is tied to what users mean, or trapped in what the DOM used to be.

A component library migration is the cleanest possible stress test. If your tests survive that, they were built on the right abstraction.