--- title: "Migrating from Selenium to Playwright: A Step-by-Step Guide" description: "How to migrate from Selenium to Playwright, with a step-by-step overview and how to overcome common challenges." canonical: "https://momentic.ai/blog/migrate-selenium-playwright" last-updated: "2026-09-22T16:05:23Z" --- # Migrating from Selenium to Playwright: A Step-by-Step Guide URL: https://momentic.ai/blog/migrate-selenium-playwright [blog](/blog) [/ resources](/blog/category/resources) / migrate-selenium-playwright Resources How to migrate from Selenium to Playwright, with a step-by-step overview and how to overcome common challenges. Wei-Wei Wu CEO, Momentic Migrating from Selenium to Playwright takes 11 steps: audit the framework, pick a language, install Playwright, convert tests, replace wait strategies, rebuild page objects, simplify parallel runs, update CI/CD, migrate gradually, train the team, then adopt advanced features. To skip the rebuild, teams move straight to Momentic, where tests are plain-English YAML that coding agents write and maintain. Tired of the constant workarounds needed to make [Selenium](https://momentic.ai/blog/selenium-future-relevance) work with modern web apps? Thinking about all the hours the team could save_if only Selenium did X, Y, or Z better_? Congratulations – you’ve reached the point where many engineering teams start to consider migrating from Selenium to Playwright. Here’s what you need to do, the challenges you should anticipate, and some alternative software suggestions. One more path exists. Teams that move to Momentic skip the rebuild: tests are version-controlled YAML in your own repository, they self-heal when the UI changes, and Mo, an autonomous AI coworker, explores the app and reports bugs beyond your migrated coverage. The last section covers that option. ## Why Migrate from Selenium to Playwright? Teams migrate because Playwright executes tests faster, waits for elements automatically, handles modern web apps, runs tests in parallel natively, and needs fewer third-party integrations than Selenium. In the case of [Playwright and Selenium](https://momentic.ai/blog/playwright-vs-selenium), it’s pretty clear that the efficiency gains you’ll get from Playwright far outweigh that risk. Here’s why: ### Playwright Executes Tests Faster Playwright runs tests faster thanks to its direct browser communication over WebSockets (no WebDriver layer). ### Playwright Offers Built-In Auto-Waiting Playwright automatically waits for elements to be actionable before testing. This means fewer flaky tests and less time spent coding complex workarounds – especially if you’re testing SPAs. ### Playwright Handles Modern Apps Better Selenium was released in 2004, Playwright in 2020. This means that Playwright is, naturally, better designed for [modern testing needs](https://momentic.ai/blog/browser-testing-tools) – as well as SPAs, Playwright deals with shadow DOMs, network interception, and multiple browser contexts better than Selenium. ### Playwright Offers Native Parallel Support Playwright supports parallel testing out of the box. This offers a significantly easier and more efficient way of running parallel tests than Selenium, which relies on external tools. ### Playwright Requires Fewer Third-Party Integrations Playwright has a built-in test runner and reporting features, so you don’t need to rely on third-party tools for test retries, tracing, screenshots, or HTML reports. ## How to Migrate from Selenium to Playwright In 11 Steps The migration takes 11 steps, from auditing your Selenium framework to adopting Playwright's advanced features, and most teams run both frameworks in parallel during the switch. The exact process varies between teams based on Selenium setup, and it requires technical know-how. If you don’t have this expertise in-house, find a consultant who can advise you on your specific circumstances. A good one is worth the investment. Still, it can be pretty useful to get an overview of what you need to do in a Selenium to Playwright migration, and when you need to do it. Here’s an at-a-glance guide for reference: **1. Audit your Selenium framework** - Boring but necessary - Review test coverage and other key metrics – where could Playwright improve things? - Note key requirements for migration – what resources will you need, and when will you need them? - Discuss process retention – which workflows will you keep? Which will no longer work? **2. Choose your Playwright language** - Playwright supports JavaScript/Typescript, Python, .NET, and Java - If you’ve chosen it for language continuity, carry on - However, you could use this opportunity to migrate from Java to TypeScript for better test maintainability – lots of teams do this **3. Install Playwright in your project** - This one’s self explanatory **4. Convert basic tests** - Start simple, then work your way through your test suite - What to be aware of: no WebDriver setup, built-in assertions, no explicit waits - If you’ve done it right, tests will become shorter and more readable **5. Replace wait strategies** - Playwright automatically waits for element visibility, stability, enabled state, and network idle - This significantly reduces flakiness - Make sure you update migrated tests to benefit from this **6. Rebuild Page Objects** - When you migrate Selenium to Playwright, your POM becomes cleaner, more asynchronous, and less dependent on driver injection - Ensure test scripts are set up to enable this **7. Simplify parallel execution** - Bid farewell to Selenium Grid and complex Docker setups - Playwright offers native parallelization - To maximize the benefits, simplify your execution strategy and remove unnecessary infrastructure **8. Update CI/CD** - Remove WebDriver setup, driver binaries, and Grid services - Ensure that your CI is updated to store the test artifacts Playwright generates (HTML reports, trace viewer, screenshots on failure) **9. Migrate gradually** - Do not try to do everything at once - Create a priority list for rewriting and migration - High-priority, high-value tests go first **10. Train your team** - Make time for proper training – this reduces the likelihood of bad habits forming, and ensures you maximize efficiency gains - Focus training on key Selenium/Playwright differences, including: - Asynch waits - Locators - Fixtures - Debugging with Trace Viewer **11. Start using Playwright’s advanced features** - After migration and training, the efficiency gains really start - Take a look at: - Network interception - Multiple browser contexts - Built-in tracing - API testing ## What Are The Challenges of Migrating from Selenium to Playwright? The two challenges that stall most migrations are user buy-in and the temporary dual maintenance of both frameworks. Migrating from Selenium can also feel intimidating: for many teams, it is the only test automation tool they have ever used. The key is anticipating these challenges and planning how to address them in advance. Consider the following: ### 1. User Buy-In Migrating from Selenium to Playwright will only work if your users buy into the change, and embrace it. However, people are naturally change-resistant. This creates a dilemma. (This doesn’t mean that your team are luddites – just that they’re following a natural ‘if it’s safe, why move’ evolutionary instinct). To alleviate: - Communicating the benefits early. Chances are, there’s plenty that your team doesn’t love about Selenium – show them how Playwright fixes that - Staggering training – a huge info-dump will make things seem insurmountable. Delivering training in bite-sized pieces is more manageable - Encouragement – there may be setbacks, and things may operate less efficiently as your team gets the hang of a new tool. Reward your team’s commitment and perseverance, show recognition for their efforts, whatever works in your organization ### 2. Temporary Dual Maintenance You won’t be able to migrate all your tests at once – which means you’ll need to maintain both Selenium and Playwright as you complete the switch. If you don’t organize this properly, things could get pretty chaotic. Make sure to: - Be super clear about which tests are migrated, and when they will be migrated - Check in regularly with stakeholders to avoid misunderstandings - Run a tight ship, administratively speaking – update key documentation as you go, and maintain a single source of truth throughout the project ## Which tools convert Selenium tests to Playwright? No tool converts a Selenium suite to Playwright and gives you tests you can trust without a review. The options are a manual rewrite, a coding agent that ports one file at a time, or a move to a test format that an agent writes from the spec instead of from the old code. Here is what each option does and where it stops: - Playwright codegen records a new test from a browser session. It does not read Selenium code, so it replaces a Selenium test instead of converting it. Use it when the old test is short and the flow is easy to click through. - A coding agent (Claude Code, Cursor, Codex, Devin) converts Selenium Java, Python or C# to Playwright TypeScript. It handles the mechanical part well: driver setup, locators, waits and assertions. It still needs a run and a review for every file, because the agent cannot see the app when it writes the code. - Community scripts on GitHub rewrite the driver API calls with regular expressions. They cover a small part of the WebDriver API, and they do not touch page objects, waits or test data. Treat their output as a starting point, not as a converted test. - Momentic ships no automatic converter from Selenium. Instead, a coding agent with the Momentic MCP server or the coding agent skills writes the YAML test from the existing spec, then runs it and reads the result. The Momentic path is documented in [Test portability](https://momentic.ai/docs/get-started/test-portability). Keep the Selenium suite running, port the highest-value flows first, and delete an old spec only after its replacement passes a few consecutive runs. ## What breaks when you move Selenium tests to Playwright? Explicit waits, driver management, Selenium Grid and driver-injected page objects break first, because Playwright removes the layer they depend on. Locators, iframes and multi-window flows need a rewrite, not a search and replace. Plan for these six breakages before you convert the first file: - WebDriverWait and implicit waits. Playwright waits for an element to be attached, visible, stable and enabled before it acts. A ported wait either does nothing or hides a real bug. Delete the wait and let the locator action or the web-first assertion (expect(locator).toBeVisible()) do the work. - Driver binaries and WebDriverManager. Playwright installs its own browsers with npx playwright install. Every driver download step in CI goes away. - Selenium Grid and remote WebDriver URLs. Playwright runs tests in parallel with workers on one machine, and across machines with --shard. The Grid hub, the nodes and the Docker files that ran them are no longer needed. - Page objects that receive a WebDriver in the constructor. Playwright page objects receive a Page, and every method becomes async. A Java suite with synchronous chains needs await on every line in TypeScript. - switchTo().frame() and switchTo().window(). Playwright uses page.frameLocator() for iframes and a new Page object for each tab or popup. Alerts move from switchTo().alert() to page.on('dialog'). - Cloud grid configuration for BrowserStack or Sauce Labs. Both vendors run Playwright, but with a different connection method (a CDP endpoint, not a WebDriver capability), so the config file changes even when the vendor stays. Locators do not break, but they cost you the most time. A Selenium suite full of absolute XPath keeps working in Playwright and stays as brittle as before. Convert to getByRole, getByLabel and getByTestId while you port, or the migration moves the maintenance problem without fixing it. ## Can a coding agent convert a Selenium suite? Yes. A coding agent converts Selenium code to Playwright faster than an engineer, and the same agent can write the flow as a Momentic YAML test instead. The difference is what the agent does after it writes the file. For a Selenium to Playwright port, give the agent one test file, the page objects it imports, and a prompt like this: `Convert this Selenium Java test to Playwright TypeScript. Use getByRole, getByLabel or getByTestId locators. Remove every explicit wait and use web-first assertions. Keep the test name and the assertions. Run `npx playwright test ` and fix failures until it passes.` The agent produces a file that compiles. It does not know whether the locator matches the real page until the test runs, so the loop that matters is run, read the failure, correct the code. In practice an engineer still reviews every converted file, because the agent will invent a test ID or drop an assertion it could not map. With Momentic the agent skips the Playwright code and writes the test as steps in plain English: `@Test public void checkoutShowsConfirmation() { driver.get("https://shop.example.com"); new WebDriverWait(driver, Duration.ofSeconds(10)) .until(ExpectedConditions.elementToBeClickable(By.id("checkout"))) .click(); driver.findElement(By.name("email")).sendKeys("jeff@example.com"); driver.findElement(By.cssSelector("button[type=submit]")).click(); assertTrue(driver.findElement(By.className("confirmation")).isDisplayed()); }` `fileType: momentic/test/v2 id: checkout-shows-confirmation url: https://shop.example.com steps: - click: Checkout - type: text: jeff@example.com into: Email input - click: Place order - assert: An order confirmation is visible` The YAML file lives in your repository next to the code. The agent writes it with the [Momentic MCP server](https://momentic.ai/docs/coding-agents/mcp-server) or the [coding agent skills](https://momentic.ai/docs/coding-agents/skills), runs it with npx momentic run, and reads the step that failed, the screenshot and the trace. When the checkout button is renamed later, Momentic re-resolves the element from the step description instead of failing on a selector. ## How long does a Selenium to Playwright migration take for 500 tests? Plan 3 to 6 months of one engineer for a manual rewrite of 500 tests, 6 to 10 weeks with a coding agent doing the conversion and an engineer reviewing, and 4 to 8 weeks for an agent-assisted move to Momentic. These are planning figures. Convert your first 20 tests, measure the hours per test, and rescale before you commit a date. The figures come from a per-test estimate, and the per-test cost is what changes between the three paths: | Path | Hours per test | 500 tests | What the engineer does | | --- | --- | --- | --- | | Manual rewrite in Playwright | 1 to 3 | 500 to 1,500 hours | Reads the Selenium test, writes the Playwright test, rebuilds the page object, debugs the run | | Coding agent writes Playwright, engineer reviews | 0.5 to 1 | 250 to 500 hours | Reviews the diff, runs the test, corrects locators the agent guessed | | Coding agent writes Momentic YAML, engineer reviews | 0.3 to 0.6 | 150 to 300 hours | Reviews the steps against the spec, runs the test, accepts the result | Two costs are not in the table and apply to both Playwright paths: the page objects, which you rebuild once per page and not once per test, and the dual maintenance period, in which every UI change costs a fix in Selenium and a fix in Playwright. With Momentic the second cost falls away for the ported tests, because the test updates when the UI changes and the change is a diff in your repository. Cost follows the same shape. At a loaded engineer cost of $100 per hour, the manual rewrite of 500 tests costs $50,000 to $150,000 in engineering time before the suite runs in CI. The agent-assisted paths cost $15,000 to $50,000 in review time plus the tooling. Put your own rate and your measured hours per test in the same formula. ## How do Selenium Grid parallel runs map to Playwright workers in CI? A Grid node becomes a Playwright worker, and a Grid with several machines becomes a sharded run. Set workers in playwright.config.ts for one machine, and pass --shard=1/4 on four CI jobs to split the suite across machines. `# .github/workflows/e2e.yml jobs: e2e: strategy: matrix: shard: [1, 2, 3, 4] steps: - run: npx playwright install --with-deps - run: npx playwright test --shard=${{ matrix.shard }}/4` Three rules keep the mapping honest. Tests that shared state on the Grid, such as one login account, fail under workers because each worker runs in its own browser context. Playwright reports arrive per shard, so merge them with npx playwright merge-reports or upload each blob as an artifact. And the retry count in playwright.config.ts replaces the rerun-failed-tests plugin you had in Selenium. ## Is a Selenium to Playwright migration worth it in 2026? A Selenium to Playwright migration is worth it in 2026 when the suite is under about 300 tests, the team already writes TypeScript, and Selenium Grid costs more than an engineer-week per quarter to run. Above that size, or when maintenance hours are the real cost, the port only moves the problem, and a move to an agent-maintained format pays back sooner. Use this table to make the call. Each row is one input that changes the answer; the last column gives the path that wins on that input alone. | Input | Migrate to Playwright | Stay on Selenium | Move to Momentic | | --- | --- | --- | --- | | Suite size | Under 300 tests: a port fits in one quarter | Over 1,000 tests and stable: the rewrite cost is not paid back | Any size: the agent writes tests from the spec, not from the old code | | Java or TypeScript | TypeScript team: Playwright is the native fit | Java team with no plan to change: Selenium keeps the language | Either: the test is YAML, and the agent works in both repos | | Grid cost | You run your own Grid: Playwright workers and --shard remove the hub and nodes | You already pay a cloud grid that runs Selenium well | Momentic runs the browsers, so the Grid line item goes away | | Maintenance hours | Under 10 hours a week: auto-waiting cuts the flaky share | Under 5 hours a week: no reason to move | Over 10 hours a week: tests re-resolve elements when the UI changes, so the hours drop | Add up the rows. Two or more rows in the Playwright column make the port worth it. Two or more rows in the Momentic column mean the port is a detour: you pay for a rewrite and keep the maintenance bill. Yes for speed, no for maintenance. Software testing is faster, simpler, and easier to scale with Playwright, but you still own a code-based suite. If you plan your migration properly, you are likely to start realizing those efficiency gains relatively soon after implementing. On the other hand, Playwright is no longer the_creme de la creme_of software testing tools. You’re still anchored to writing tests in code, and auto-waits don’t solve your ongoing test maintenance burden. If you’re looking to shift left and up your release cadence (and in this environment, you need to), Playwright will only get you halfway there. Momentic removes the two costs that Playwright keeps: writing the test in code, and fixing it when the UI changes. It does this with functionality that Playwright does not offer: - **Natural language test creation:** create tests in plain English – it takes seconds, and makes it much easier for your engineers to test as they go and avoid huge find-and-fix bottlenecks just before code is shipped - **Version-controlled YAML:** tests live in your own repository as plain English, so engineers and coding agents can read, diff, and maintain them like source code - **Intent-based locators:** these update your test when the UI changes – [tests self-heal](https://momentic.ai/blog/self-healing-test-automation-guide), minimizing your test maintenance burden and freeing up engineering hours for other, more valuable tasks - **AI agents:** Mo, your autonomous AI coworker, explores your app, evaluates critical user flows, generates new tests, and reports the bugs it finds. Routine maintenance runs in the background If you migrate from Selenium to Playwright now, chances are you’ll need to migrate again in a couple of years when you realize that AI offers steeper efficiency gains. Why waste effort migrating to a [system that’s on its way out](https://momentic.ai/blog/playwright-alternatives)? Migrate straight from Selenium to an AI-native testing tool to really see the difference. ## Migrate to Momentic > “We went from 1-2 months for 80% user flow coverage to 1-2 days.” [Momentic](https://momentic.ai/) is an AI testing solution that’s designed to be intelligent, intuitive, and fast. Implement on Day 1, test on Day 1. [Here’s how Best Parents reached 80% user flow coverage](https://momentic.ai/customers/best-parents) in just one day after implementing Momentic – _with tests written in plain English_. Want to join them? [Talk to our engineering team today](https://momentic.ai/sales). ## Selenium to Playwright, answered. How do I migrate a Selenium suite to Playwright? Audit your Selenium framework, choose a language, install Playwright, convert basic tests, replace wait strategies, rebuild page objects, simplify parallel execution, update CI/CD, migrate gradually, train your team, then adopt advanced features like tracing and network interception. Is there a tool that converts Selenium tests to Playwright? No tool reliably converts Selenium tests to Playwright, so teams rewrite them by hand or have a coding agent port them. Another path is Momentic, where tests are plain-English YAML that self-heal when the UI changes. What breaks when you move Selenium tests to Playwright? Explicit waits break because Playwright auto-waits for actionable elements. WebDriver setup and Selenium Grid are no longer needed. Page objects must be rebuilt for async locators, and CI must store Playwright's trace and screenshot artifacts. How long does a Selenium to Playwright migration take for 500 tests? Plan 3 to 6 months of one engineer for a manual rewrite of 500 tests, 6 to 10 weeks with a coding agent converting and an engineer reviewing, and 4 to 8 weeks for an agent-assisted move to Momentic. Convert 20 tests first and rescale from the measured hours per test. Is a Selenium to Playwright migration worth it in 2026? Yes when the suite is under about 300 tests, the team writes TypeScript, and you run your own Selenium Grid. No when maintenance hours are the main cost: the port keeps a code-based suite, so move to tests that an agent writes and maintains instead. Can a coding agent convert our Selenium suite for us? Yes. Claude Code, Cursor, Codex or Devin convert Selenium Java or Python to Playwright TypeScript one file at a time, and an engineer reviews and runs each file. The same agent can write the flow as a Momentic YAML test with the Momentic MCP server, then run it and read the failure. Still have additional questions? ## Keep reading. [Resources Best Puppeteer Alternatives for Browser Automation Compare the best Puppeteer alternatives for browser automation, E2E testing, and web scraping. Explore Playwright, Selenium, Cypress, Momentic, and more. Wei-Wei Wu 8 min read](/blog/puppeteer-alternatives)[Resources Best Qodex Alternatives for UI Testing Compare the best Qodex alternatives for UI testing, including Momentic, QA Wolf, mabl, Testim, and more. Explore AI-powered testing, self-healing locators, and web and mobile support. Wei-Wei Wu 8 min read](/blog/qodex-alternatives)[Resources Best Shiplight Alternatives for AI-Native Testing Compare the best Shiplight alternatives for AI-native testing, including Momentic, Playwright, mabl, TestRigor, and QA Wolf. Explore self-healing, autonomous testing, mobile support, and more. Wei-Wei Wu 7 min read](/blog/shiplight-alternatives) ## Close the feedback loop. Point Momentic at your app. Free to start, no credit card. [Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)