What Twenty Years of Selenium Cost Us to Leave

QASource · Automation practice

Selenium was the right answer for twenty years. It was the reason a great deal of what we built was possible, and it is embedded in a large part of what our clients run today. When we tell people we are retiring it, the reaction is usually some version of: why would you disturb something that works?

The honest answer is that it stopped being the best thing we could give a client, and the gap got too wide to justify on grounds of our own convenience.

What the Numbers Looked Like

Playwright executes comparable suites roughly 80% faster. Maintenance—which, over a suite's life, is the cost that actually matters—falls by about 90%. False positives, the thing that quietly destroys a team's trust in its own test results, drop sharply.

Any one of those is an argument. Together they are not a preference; they are a different economic model for what a regression suite costs to own.

The Part Nobody Writes About

A framework migration across a two-decade estate is not a technical exercise. It is an accounting one. Every script that gets rewritten is work that produces no new coverage. The client's product does not get safer on the day of the migration; it gets safer afterwards, and someone has to fund the interval.

This is where most firms quietly decide not to migrate. The existing suite works. The cost is real and immediate, the benefit is real and deferred, and the vendor is not the party who suffers most from a slow, brittle suite. It is a very easy decision to defer forever.

Nothing keeps a framework in production longer than what it cost to build on it.

How We Made It Affordable

We ran the migration through the QASource Intelligent Platform (QASIP), our internal platform, and it took roughly a tenth of the effort a hand migration would have taken. That is the only reason the decision was possible at the scale we needed it. A tenfold reduction turns a multi-year program that nobody would approve into something that can actually be scheduled.

We pointed it at our own estate before we pointed it at anyone else's—partly because that is the right order, and partly because a twenty-year codebase with real clients depending on it is a much harder test than a demonstration repository.

The Thing This Era Is Teaching Us

Here is what actually changed, and it is larger than one framework. For most of our history, an investment in tooling paid back over years. You chose well, you built on it, and the choice compounded.

That is no longer reliably true. Tooling now goes obsolete before it has finished paying for itself. The models improve faster than the practices built on them can amortize, and a two-year payback assumption is starting to look like a three-year mistake.

We have lived through three transitions before this one—waterfall to agile, manual to automated, and phased delivery to continuous. Each of them forced us to give something up. This one is different in a specific way: the interval between having to give something up is now shorter than the interval over which the last thing paid off.

We do not think the answer is to stop investing. We think the answer is to assume shorter lives, to build so that migration is cheap, and to be honest with clients about what the current transition costs rather than describing only what it gains.

Selenium served us and our clients well for twenty years. That is a long time in this industry, and it is over.

← All insights