How to Migrate from Selenium to Playwright Without Rebuilding Your Debt

Most Selenium-to-Playwright migrations fail before the first test runs in CI. Not because Playwright is hard to learn, but because teams treat the migration as a translation exercise. They port page objects line by line, recreate custom wait logic, and rebuild the same brittle architecture in a newer framework. Then they wonder why maintenance overhead didn’t drop.

The framework isn’t the problem. The patterns you carried over are.

Before you pick a framework, run a structured POC

Resist the pull toward the tool your most vocal engineer already knows. Before you write a single line of POC code, define your evaluation criteria and then score each candidate framework against them.

A few things worth flagging before you start:

• Language choice matters more than most teams expect. Playwright supports Python, Java, .NET, and Node.js with TypeScript or JavaScript, but the feature set is not equal across all of them. Native parallelism, fixture support, and community tooling are most mature in the TypeScript/JavaScript implementation. If your team is choosing Java Playwright expecting parity with the docs, you’ll hit gaps.
• Mix quantitative and qualitative criteria. Execution speed and setup time are measurable. Community health, GitHub activity, and whether your team actually wants to work in the framework are not, but they matter just as much.
• Run the same scenarios for each candidate. You want to compare equivalent implementations, not impressions.
• Document the decision. Write down why you chose what you chose. You’ll need it for the engineers who weren’t in the room and for the retrospective you’ll run six months later.

What actually changes when you move to Playwright

The line count difference alone tells part of the story. A login test that runs 116 lines in Selenium covers the same scenarios in roughly 40 lines in Playwright. That’s not aesthetics — that’s maintenance surface cut by two-thirds.

The more significant changes are architectural.

Playwright’s auto-waiting means you stop writing explicit waits for elements, animations, and network responses. You write the action; Playwright handles the timing. One sentence on this is enough: it eliminates an entire category of flakiness that Selenium teams spend hours chasing.

Fixtures are where the real execution gains live. Instead of instantiating page objects inside every test file, you define them once in a base fixture and inject them where needed. Test files stay focused on behavior, not setup boilerplate. Teams that implement fixtures well report up to 70% reductions in test runtime — largely because authentication and page object initialization happen once rather than per test.

Storage-state authentication compounds those gains. Playwright lets you perform login once via an API call during global setup, serialize the session to a JSON file, and reload it before each test. No UI login flow per test. No seven-second sign-in overhead multiplied across hundreds of tests.

Built-in parallelism runs at both the file and test level. You don’t need separate files to run two tests concurrently. That’s a meaningful structural difference if you’re coming from a tool where parallel execution required significant configuration work.

Architecture from scratch, not from memory

Teams that get the most out of Playwright treat migration as a greenfield architecture decision. The ones that struggle port their old structure forward and spend the next year paying for it.

Set hard constraints before you write your first test:

• Max 200 lines per file
• Max five parameters per method
• Import sorting enforced via Prettier plugin

ESLint, Prettier, and Husky enforce these at commit time so they don’t depend on code review discipline. Set them up on day one. A test suite that looks clean at 50 tests will become unreadable at 500 if you skip this step.

Keep your page manager lean. If a single fixture loads every page object at initialization, you’re adding overhead to tests that don’t need most of what gets loaded. As your suite grows, split into multiple focused fixtures rather than one that loads everything.

Where visual testing closes the gap

Here’s what “Playwright screenshot comparison breaks down at scale” actually looks like in practice: your UI ships a round of content updates, localization changes, and layout adjustments. Now you’re manually updating baselines one by one across hundreds of tests. It’s the kind of work that makes engineers question their career choices — and it’s a real scenario for any team maintaining a UI that moves fast.

Applitools Eyes integrates directly with your Playwright suite via the Playwright SDK. Instead of maintaining pixel-perfect baselines, you get visual AI checks that distinguish real visual regressions from rendering noise. A button that shifted two pixels in a non-interactive area doesn’t fail your suite. A form field that disappeared does.

Baseline management moves to a single dashboard. You review, approve, or reject visual differences across your entire suite in one place rather than hunting through individual test artifacts. For teams managing internationalized UIs or frequent design updates, that’s the difference between visual testing being a practice and visual testing being a burden.

The Applitools MCP server takes it a step further. Point it at your existing Playwright suite and it identifies where you’re relying on brittle text assertions or locator-dependent validations — the checks most likely to break when the DOM shifts — and suggests where to replace them with visual AI checks instead.

See it in code

Reading about fixtures and page managers is one thing. Watching someone walk through the actual implementation — side-by-side with the Selenium equivalent — is another.Renata Andrade, software quality engineer at Adobe, covers all of it in detail: the POC framework, the architecture decisions, the code comparisons, and how Applitools fits into a Playwright suite in production.

🎥 Watch the full tech talk from Renata here

Quick Answers