Selenium to Playwright Migration: What Enterprise Teams Get Wrong in the First 30 Days

Playwright npm downloads grew roughly 235% year on year through 2025, overtaking Cypress on weekly download volume and closing fast on Selenium for new project starts. The Currents migration guide captures the technical shift well: auto-waiting replaces explicit waits, parallel workers replace Grid, and a single API covers browser, network, and trace. That part is real, and it is solvable.

It is also only 20% of the work.

Every enterprise Selenium-to-Playwright migration we have seen stall in the first 30 days has stalled for the same reasons — and none of them are about the framework. The migrations that ship on time treat the port as a delivery programme, not a tooling swap. Here is what enterprise teams consistently get wrong, and what to do about it before week four.

Mistake 1: Treating the port as a 1:1 rewrite

The instinct is to map each Selenium test to a Playwright equivalent and call it migration. This produces a slower, flakier suite in a new framework — because the Selenium suite encoded years of workarounds for problems Playwright does not have.

Explicit waits become redundant under auto-waiting. Page Object Models built around WebDriverWait become awkward when the framework already waits on actionability. Custom retry loops fight Playwright's built-in retries. A literal port carries forward the scar tissue.

The research is consistent here. The 2024 ISSTA study on flaky test root causes found that 45% of flaky UI tests trace to async/timing issues that auto-waiting eliminates outright. If you port those tests verbatim, you keep the flakes and blame Playwright.

What to do this week: before any code moves, classify your existing Selenium suite into three buckets — tests that exercise real user journeys (port and rewrite), tests that duplicate unit coverage (delete), and tests that exist because something was once flaky (rewrite from the spec, not the code). In most enterprise suites the delete bucket is 30–40% of the total. You are not migrating those.

Mistake 2: No flake baseline before you start

The second-month complaint on every stalled migration sounds the same: "Playwright is flakier than Selenium was." It almost never is. What is happening is that nobody measured the Selenium flake rate before the migration began, so any flake in the new suite reads as regression.

The 2024 DORA report found that elite performers track test reliability as a first-class metric — pass rate on retry, time-to-quarantine, and flake-driven CI minutes. Most enterprise teams track none of these for their existing suite. They discover their Selenium suite was 12% flaky only when the Playwright suite comes in at 4% and somebody calls it a problem.

What to do this week: instrument the existing Selenium suite for two weeks before any migration work starts. Measure pass rate on first attempt, pass rate on retry, mean test duration, and the top 20 flakiest tests by name. Publish the numbers. Now the migration has a baseline to beat, not a vague memory to argue with.

Mistake 3: CI ownership stays where it was

This is the killer. The Selenium suite was owned by a QA team or a dedicated SDET function. The migration plan assumes that team will own the Playwright suite too. But Playwright is a developer-first tool — it runs in the same language as the application, lives in the same repo, and is designed to be authored by the engineers who wrote the feature.

If ownership does not move, you get the worst of both worlds: a modern framework run by a team structurally separated from the code it tests, with developers no more accountable for test outcomes than they were before. The CI pipeline still gates on a suite nobody on the feature team feels responsible for.

The 2024 State of Testing report found that teams where developers own end-to-end tests have 2.3x lower escaped defect rates than teams where a separate QA function owns them. The tool change is the moment to fix the ownership model, not preserve it.

What to do this week: write down who will own each test file after migration. If the answer is "the same QA team that owns it now," stop. Decide whether you are doing a framework migration or a quality ownership migration. Doing the first without the second wastes both.

Mistake 4: The reporting chain still talks to the wrong people

Selenium suites tend to produce reports that go to a QA lead, who summarises them for engineering management, who occasionally escalates to product. By the time a failing test reaches the product manager who cares about the feature, it has been through three filters and lost most of its context.

Playwright's trace viewer changes what is possible here. A failing test produces a recorded trace with network logs, console output, and a DOM snapshot at the moment of failure. A product manager can open it and see what broke. That changes who can be in the loop — but only if you wire the reporting to actually reach them.

What to do this week: pick one critical user journey. Wire its Playwright failures to post directly to the Slack channel of the product team that owns the feature, with a link to the trace. See what happens to time-to-triage. In our experience it drops from days to hours, and the conversation about test value changes immediately.

What 90 days actually looks like

A realistic enterprise migration timeline, assuming a suite of 800–2,000 Selenium tests and a 50–200 engineer organisation:

• Weeks 1–2: instrument existing suite, establish flake baseline, classify tests into port/delete/rewrite buckets, agree new ownership model

• Weeks 3–6: migrate the highest-value 20% of tests (typically the smoke and critical-path suites), run both frameworks in parallel CI, tune Playwright config against the baseline

• Weeks 7–10: migrate the long tail by feature team, with each team owning its own slice; retire Selenium tests as Playwright equivalents reach reliability parity

• Weeks 11–12: decommission Selenium infrastructure, fold Playwright reports into the product feedback loop, publish the new flake and duration numbers against the original baseline

The teams that hit this timeline are not the ones with the best Playwright knowledge. They are the ones who treated weeks 1–2 as a delivery problem rather than a tooling problem.

Where pods fit

This is the kind of work a 3-person AI-augmented pod is built for: a fixed-scope, 90-day programme with clear technical and organisational deliverables, run by senior engineers who have done it before. The pod handles the migration, the CI rework, the ownership transition, and the reporting wiring in parallel — and exits leaving the in-house teams owning a faster, more reliable suite they understand.

If you are mid-migration and watching the timeline slip, the fix is rarely more Playwright expertise. It is usually the four things above, addressed in week one rather than week ten. Anystack runs these as part of our QA modernisation and test automation practice — typically as a 10–12 week engagement that delivers the suite, the ownership model, and the metrics together.