How would you migrate a Selenium suite to Playwright incrementally?

Big-bang rewrites of test suites are how teams burn 6-12 months and end up with two half-working systems. The right pattern is parallel run + feature-by-feature migration.

Phase 1 — Tracer bullet (1-2 sprints)

• Port one small but representative feature (e.g. login + dashboard smoke).
• Establish the Playwright project structure: tests/, fixtures/, playwright.config.ts, CI pipeline.
• Write a base fixture: storage state, base URL, env config.
• Codify code review standards (selectors, no manual waits, fixtures over global state).
• Run both Selenium and Playwright against the same feature in CI. Treat divergent results as bugs in either suite — and learn from them.

Phase 2 — Smoke migration (1 quarter)

• Port the full smoke suite. This is the most-watched suite, so quality bar is highest.
• Decommission the Selenium smoke once Playwright smoke has been green for 4 consecutive weeks with no regressions.
• Keep Selenium regression running unchanged.

Phase 3 — Regression migration (1-2 quarters)

• Migrate by feature area (auth → checkout → reports → admin → ...).
• One feature at a time: port → run in parallel for 2 weeks → decommission Selenium for that feature.
• During parallel run, expect ~10-20% of Selenium tests to be obsolete or duplicates — don't port those, delete them.

Phase 4 — Decommission Selenium

• After 2-4 weeks of zero Selenium-only test failures, remove the Selenium suite + Maven build.
• Archive the repo or branch for reference.

Cross-cutting:

• Don't port 1:1. Use the migration as a chance to rewrite obvious anti-patterns (positional xpath, shared test data, no fixtures). Playwright fixtures are different from TestNG @BeforeMethod — model the right pattern for the new tool.

• Train the team. Playwright's auto-wait and locator API are different idioms. Pair-program the first month so the team learns Playwright conventions, not "Selenium translated."

• Communicate to stakeholders weekly. "X% of regression in Playwright; on track to decommission Selenium by Y." Migrations lose support when leadership can't see progress.

Anti-patterns:

• Hard cutover ("Selenium gone by quarter end") — guaranteed missed deadline.
• Running both suites forever — choose a sunset criterion and enforce it.
• Letting one engineer do the migration alone — ports pile up, quality drops, that engineer becomes a single point of failure.