"Should we move to Playwright?" You will be asked this, and the quality of your answer is a senior signal in itself. Most teams decide it on enthusiasm in one direction or inertia in the other.
Start by naming the actual problem. "Selenium is old" is not a problem. These are:
- The suite takes four hours and blocks releases.
- Tests are flaky and the team has stopped trusting them.
- Writing a test takes a day because the framework is unusable.
- We cannot test the flows that matter (multi-tab, network state).
- We cannot hire; every candidate wants to work with modern tooling.
Each has a different answer, and three of those five are not fixed by migrating.
A slow suite is usually slow because of UI setup and insufficient parallelism. Those follow you to a new tool. Flakiness is usually bad waits and shared state; the new tool's auto-waiting helps with one of those and not the other. A bad framework can be rebuilt in Selenium for a fraction of the cost of migrating.
Migration does help with capability gaps and with hiring. Be clear about which one you are actually solving, because a migration justified by the wrong reason arrives, costs a year, and does not fix the complaint.
What migration really costs. Teams underestimate this consistently:
Rewriting tests. Not translating. The models are different enough that mechanical conversion produces bad tests. Budget 30 minutes to 2 hours per test. Five thousand tests is several engineer-years.
Rebuilding the framework. Page objects, data, config, reporting, CI integration.
Retraining everyone, including people who were productive and will be slow for a while.
Running two suites in parallel during the transition, with two sets of infrastructure and two sets of failures to triage.
Losing coverage in the gap. The riskiest part, and the one nobody plans for.
When migration is the right call. The real cases: when you need capabilities the protocol cannot provide and BiDi does not yet cover; when the suite is small enough that rewriting is weeks rather than years; when you are rewriting the application anyway; or when hiring has become a real constraint on the team's existence.
When it is not. When the real problem is architecture, when the suite is large and working, when nobody has costed it, or when the driver is that a new senior engineer prefers a different tool. That last one is more common than people admit.
If you do migrate: never big-bang.
The pattern that works:
Stop writing new Selenium tests. All new work goes to the new tool. The Selenium suite is now frozen, and this alone stops the problem growing.
Migrate by value, not by file order. Move the tests that fail most often and cost most to maintain. You get the benefit early and can measure it.
Run both suites. Yes, it is more infrastructure. It is also the only way to avoid a coverage gap, and the gap is what makes migrations dangerous.
Delete Selenium tests as they are replaced, not at the end. A test covered twice is maintained twice.
Set a checkpoint, not a deadline. After three months, compare: are the new tests faster and more reliable in practice? If not, stop and reconsider. A migration that is not delivering should be abandoned, and being able to say that is more valuable than finishing something that is not working.
The strongest version of the answer. When asked, do not answer yes or no. Say: "What problem are we solving? Let me measure where our time actually goes. If it is setup and parallelism, I can fix that in Selenium in six weeks. If we really need capabilities the protocol cannot give us, migration is justified, and here is what it will cost and how I would sequence it."
That answer demonstrates every senior skill this track has covered: reasoning from architecture, measuring before acting, costing decisions properly, and separating a technical problem from a preference.
Remember this: name the problem first, cost the migration properly, and never big-bang a suite that people depend on.
Reference: Selenium documentation.