Selenium to Playwright migration: when the rewrite doesn't pay

Selenium shipped 4.52.0 on 29 October 2026, its fourth release in about seven weeks, so a selenium to playwright migration is not an escape from a dying tool. It is a spending decision. By the end of this post you will know what the two most-cited migration guides actually estimate, why they disagree by a factor of several, and which three facts about your suite decide whether the rewrite pays back.

The short answer for a QA lead with a slow, flaky 600-test Java suite: the published effort tables say suite architecture moves the cost more than test count does, and the parallel-running period, not the code translation, is where budgets slip. If your flakiness comes from how the tests are written, Playwright fixes some of it and a disciplined Selenium refactor may get you much of the rest for less.

Is Selenium still maintained? Yes, and it is changing protocol

Selenium is actively maintained. The project's GitHub releases page lists 4.49.0 on 9 September, 4.50.0 on 30 September, 4.51.0 on 9 October and 4.52.0 on 29 October 2026. We found no announcement of a Selenium 5. The 4.52.0 notes are full of WebDriver BiDi work across the Java, Python and Ruby bindings.

That BiDi work is the part most "Selenium vs Playwright 2026" comparisons skip. The Selenium documentation describes WebDriver BiDi as the W3C standard bidirectional protocol for browser automation, created by the Selenium project together with the browser vendors, and as the cross-browser replacement for the Chrome DevTools Protocol. The same page says Selenium "is updating its entire implementation from WebDriver Classic to WebDriver BiDi", while maintaining backwards compatibility as much as possible, and that CDP support "is temporary until WebDriver BiDi has been implemented" (page last modified 15 August 2026).

The practical meaning: network interception, console capture and JavaScript error events, the things teams cite when they say Selenium cannot see what the browser is doing, are being built into Selenium's standard protocol rather than bolted on through Chrome-only CDP. If your migration case rests on those capabilities, check what your Selenium binding exposes today before you budget a rewrite to get them.

Selenium to playwright migration effort: what the two guides estimate

Two guides dominate the search results for this question, and both come from companies with something to sell. DeviQA, a QA services firm, publishes a table of migration time in weeks. Currents, which sells test reporting for Playwright, publishes a phased plan. Neither interest makes the numbers wrong, but you should read both with the seller in mind.

DeviQA: weeks, by suite size and architecture

DeviQA's guide, updated 13 August 2026, estimates the following, assuming a dedicated migration owner:

Suite size	Clean page object model	Mixed or legacy	Spaghetti code
Under 100 tests	1-2 weeks	2-3 weeks	3-5 weeks
100-500 tests	2-4 weeks	4-7 weeks	6-10 weeks
500+ tests	4-8 weeks	8-14 weeks	12-20 weeks

Read across a row rather than down a column. A 500-test suite with clean page objects (4-8 weeks) is estimated to cost less than a 150-test suite of spaghetti (6-10 weeks). The guide adds 30-50% if the team also carries full sprint commitments, and tells you to budget 4-8 weeks of dual maintenance while both frameworks run.

Apply that to the 600-test Java suite with mixed architecture, which is the honest description of most suites that have grown for five years. The table gives 8-14 weeks. With the 30-50% uplift for a team that still has a sprint to deliver, our arithmetic on DeviQA's figures puts it at roughly 10-21 weeks, before the dual-maintenance period.

Currents: a spike, then quarters of parallel running

Currents' guide, written by Walter Galvão and published 18 March 2026, frames the work in phases. It starts with a 2-4 week spike covering installation, a CI proof of concept, auth and data fixtures, and 5-10 critical-path tests. It says engineers typically match their previous test-writing speed within 2-3 weeks, recommends pulling 2-3 engineers off regular work for a quarter if you can, and plans for parallel running of "1-2 quarters minimum".

It also says many teams move 60-70% of their tests and leave the rest in Selenium, starting with high-frequency flows such as login, checkout and core business paths. That is a useful reframe: the goal is not a 100% port, it is moving the tests that run on every pull request.

Why the selenium to playwright migration cost estimates disagree

DeviQA's 4-8 weeks of dual maintenance and Currents' one to two quarters of parallel running look like a direct contradiction. They are mostly measuring different things. DeviQA's table counts translation effort by a dedicated owner. Currents counts the calendar time until a team trusts the new suite enough to switch the old one off, which includes the weeks where both suites run, disagree, and someone has to work out which one is right.

The second number is the one that hurts budgets, because it is paid in CI minutes and in attention, not in a line on a project plan. For a 200-person SaaS company, two suites gating the same release for six months means two sets of failures to triage on every red build. If your plan only costs the translation, it is the DeviQA number with the Currents problem attached.

Be careful with the performance figures that travel with these guides. DeviQA's page cites a 42% execution-speed improvement attributed to a TestDino benchmark of 300+ suites, and 67% fewer flaky tests, but links no source for either, so we have not used them. Currents expects an individual migrated test to be "typically 20-40%" faster, which is the author's estimate rather than a published benchmark. Treat speed as a possible benefit to measure in your own spike, not as the business case.

When not to migrate to Playwright

The strongest argument for migrating is real: Playwright's auto-waiting and isolated browser contexts target the timing bugs that make Selenium suites flaky, which is how DeviQA explains its flakiness claims, and Currents expects engineers to match their previous writing speed within 2-3 weeks. The case for Playwright on a new suite is strong. Both also list cases where the rewrite does not pay, and they line up well.

• Small, stable suites. Currents advises skipping migration for small suites that are not causing pain. A suite that passes reliably has no flakiness to buy back.
• Mostly API-level suites. Currents advises against migrating suites that are mostly API-level tests. Playwright replaces the browser layer, which is a small part of such a suite.
• Deep Java tooling or a customised grid. Currents flags heavy Java-ecosystem tooling, and DeviQA flags a deeply customised Java Selenium Grid that would need complete replacement.
• Certified toolchains and old browsers. DeviQA lists regulated industries with frozen, certified toolchains, and Internet Explorer coverage, which Playwright does not support.
• No bandwidth. Currents says to wait if the team is mid-release with no capacity. A migration started without capacity tends to stall halfway, leaving two frameworks to maintain.

Two more constraints come from Playwright's own documentation. Playwright does not work with branded Safari or branded Firefox, because it relies on patched builds; it tests its own WebKit and Firefox builds instead, while branded Chrome and Edge are supported through channels. If a customer contract requires evidence on real Safari, that matters.

Java selenium to playwright migration: the runner question

For a Java team, the bigger constraint is the test runner. Playwright is available in JavaScript and TypeScript, Python, Java and .NET, but only the Node.js version comes with Playwright's own test runner, with parallelisation, screenshot assertions and an HTML reporter built in. The Java version has no runner of its own; the documentation says to use JUnit or TestNG.

So the Java team has two migrations to choose from. Stay in Java and you get Playwright's browser automation inside the runner you already have, while rebuilding parallelism and reporting yourself. Move to TypeScript and you get the full runner, fixtures and sharding, but you are now changing language, build tooling and probably who owns the suite. Price the path you will actually take.

Migrate, run both, or fix the Selenium suite

The decision has three real options, not two. The third is the one vendor guides rarely cost, because nobody sells it.

Option	What it costs	Pays back when	Wrong choice if
Migrate the suite to Playwright	DeviQA's table plus the parallel-running period Currents describes	Flakiness is structural, the suite is large, and you will move to the TypeScript runner	You need branded Safari, IE, a frozen toolchain, or a deeply customised Java grid
Run both: new tests in Playwright	Two frameworks in CI for as long as the old suite lives	Currents' 60-70% pattern: migrate the critical paths, freeze the rest	Nobody owns retiring the old suite, so "both" becomes permanent
Fix the Selenium suite	Refactoring waits, locators and page objects in place	The suite is small or stable, mostly API-level, or tied to Java tooling	The flakiness survives a refactor and the team is already writing workarounds

Fixing in place has a quiet advantage: it is also the first step of a good migration. DeviQA's table says a clean page object model roughly halves the estimate against mixed architecture at every size. Refactor the Selenium suite towards clean page objects and you either stop needing to migrate, or you migrate at the cheaper column of the table.

Whatever you choose, run the spike Currents describes before you commit: 5-10 critical-path tests in Playwright, in your real CI, against your real auth. Measure the speed and flake rate yourself. If the result is not obviously better, that is your answer. We made a similar argument about measuring before trusting headline numbers in our look at test automation ROI, and the same discipline applies here.

Running Selenium and Playwright in parallel without paying twice

Selenium and Playwright can run in the same CI pipeline; Currents' whole plan depends on it. The cost control is to give each suite a different job. Keep Selenium as the full regression run on a schedule, and gate pull requests on the smaller Playwright suite once it covers the critical paths. That keeps the per-commit pipeline short, which is where most of the pain of a slow suite lands. If the pipeline itself is the bottleneck, our post on how to speed up CI pipeline runs covers the build side of the same problem.

Set an end date for the old suite when you start, not when you finish. The same pattern shows up in any incremental rewrite: the risk is not the cutover, it is the second system that never gets switched off, as we found when comparing incremental and big-bang code migration.

Before you commit a quarter: the call to make this week

Playwright is moving quickly too: v1.64.1 shipped on 14 October 2026, a week after 1.64.0 brought Chromium 156, Firefox 157 and WebKit 27.2. Neither tool is standing still, which is exactly why "the other one is better" is not a business case. Your suite's architecture, your language, and your browser obligations are.

Start with an audit, not a migration: classify each flaky test by cause, check whether your page objects are clean enough to sit in the cheap column of DeviQA's table, and decide whether you would stay in Java or move to TypeScript. If that audit is the part your team has no time for, our QA and automation team can review the suite with you and give you a recommendation on whether to migrate, run both with a retirement date, or fix the Selenium suite you already have, before anyone spends a quarter on it.