How would you migrate a large Selenium suite to Playwright?

A migration is an investment that competes with feature testing, so a good answer covers why, what, how and when to stop, not just API differences.

1. Establish why, and whether

Typical reasons: flakiness from synchronisation issues, slow execution, effort maintaining waits and driver infrastructure, wanting built-in tracing, network interception and parallelism. Capture a baseline: suite duration, flake rate, hours spent on maintenance per sprint, escaped defects.

Also consider the alternative. If the main pain is bad test design (shared data, UI-based setup, fixed sleeps), migrating will move those problems to a new tool. Sometimes fixing the existing framework is the cheaper answer. And if you rely on something Playwright does not cover well for your context, for example a particular browser or device setup your customers use, check that first.

2. Decide the language and shape

Playwright has official bindings for TypeScript/JavaScript, Java, Python and .NET. The TypeScript test runner (@playwright/test) has the richest feature set: fixtures, sharding, projects, retries, HTML reporter, trace viewer integration. A Java shop can stay in Java with Playwright for Java plus JUnit or TestNG, which reduces retraining but means building some runner features yourself. Make this choice explicitly with the team.

3. Pilot

Pick one feature area with a mix of easy and painful tests. Rebuild the framework foundations (config, auth, data builders, page objects or fixtures, reporting, CI job) and migrate that area. Compare against the baseline. This proves value and surfaces problems such as authentication flows, iframes, file downloads or SSO before you commit.

4. Migrate incrementally

• Run both suites side by side in CI. New tests are written only in Playwright from an agreed date.
• Prioritise: critical user journeys and the flakiest, most expensive Selenium tests first; low-value tests last, or never.
• Audit while migrating. Map each old test to the coverage it provides. Many will be redundant or better as API tests; delete them instead of porting.
• Track progress with a simple coverage map: feature, old count, new count, retired count.

5. Rewrite, don’t transliterate

Line-by-line translation keeps Selenium habits that fight Playwright’s model.

// Transliterated (keeps old habits)
await page.waitForTimeout(2000);
const total = await page.locator('#cart > div:nth-child(3) span').textContent();
expect(total).toBe('54.00');

// Idiomatic
await expect(page.getByTestId('order-total')).toHaveText('54.00');

• Replace explicit waits and sleeps with auto-waiting actions and web-first assertions.
• Prefer user-facing locators (getByRole, getByLabel, getByTestId).
• Log in once and reuse storageState; set up data via the request fixture.
• Use fixtures for setup and teardown instead of deep base-class hierarchies.
• Use page.route for third-party stubbing where appropriate.

AI coding assistants can speed up the mechanical first draft of a conversion, but every converted test still needs human review for correct waits, locators and assertions; generated code tends to preserve the old structure and can drop assertions.

6. Decommission

Define exit criteria up front: all critical journeys covered in Playwright, new suite flake rate below an agreed threshold for several weeks, and no unique coverage left in the old suite. Then remove the Selenium job, the grid infrastructure and the dead code. A migration that never finishes leaves you maintaining two frameworks.

Risks to call out

• Running two suites doubles CI cost temporarily.
• Team skill gaps if switching language; plan pairing and code review guidelines.
• Losing coverage silently; the coverage map protects against that.

What interviewers look for

• A business case and a willingness to say “not yet” when the problem is test design.
• An incremental, measurable plan with a pilot and exit criteria.
• Treating migration as an opportunity to prune and push tests down the pyramid.
• Understanding of idiomatic Playwright rather than a one-to-one port.