A Cypress to Playwright migration has four steps: convert every spec in bulk, review what the conversion got wrong, run both suites side by side, then cut over. The conversion is the fast part. Trust is what takes the weeks.
Key takeaways
- Convert the whole suite at once into a separate folder. Delete nothing yet.
- Custom commands, network mocks and login are where conversions go wrong. Review those by hand.
- Run Cypress and Playwright on the same commits until Playwright matches or beats Cypress.
- Remove Cypress only after Playwright has gated several green production deployments.
Why teams move, and why a straight rewrite stalls
The reasons we hear are practical. Playwright drives Chromium, Firefox and WebKit from one API, handles several tabs and origins natively, and its trace viewer makes a failed run much easier to read. Teams with a few hundred Cypress tests want those things without stopping work for a quarter.
The usual first attempt is a rewrite by hand, a few files a week alongside feature work. It rarely finishes. The old suite keeps changing while the new one is written, two suites drift apart, and after a month nobody can say which one is telling the truth. A migration needs a plan where the new suite proves itself against the old one on the same code, before anyone switches the old one off.
The four steps
This is the plan we use, condensed. For 100 to 300 tests it typically runs six to eight weeks, and about half of it is the parallel run and the cutover, not the conversion.
- Convert in bulkA script reads every
.cy.jsand.cy.tsfile, converts it under fixed rules and writes Playwright TypeScript to a newtests/folder, with a report of which files converted cleanly. - Review by handRun the converted tests in Playwright's UI mode, sort the failures by cause, and fix custom commands, fixtures and authentication.
- Run both in CIBoth suites run on the same commits. Compare pass rates, run times and flake rates, and investigate every disagreement.
- Cut overMake Playwright the CI gate. Keep Cypress as a fallback for two weeks, and remove it after five green production deployments.
The conversion rules that matter
Whether you convert with a script, an AI model or by hand, write the rules down first so every file comes out the same way. These are the ones we enforce:
| Cypress | Playwright |
|---|---|
cy.get('.btn-primary') | Role, label or test id first: page.getByRole('button', { name: 'Save' }), CSS only as a last resort |
cy.wait(2000) | An assertion that waits for the real condition, such as await expect(row).toBeVisible() |
cy.intercept() | page.route() with route.fulfill(), or a recorded HAR file |
Login in before() | A global setup that logs in once and saves storageState |
cy.fixture('user') | Import the JSON directly, or a Playwright fixture |
cy.login() and other custom commands | Helper functions or Playwright fixtures |
Playwright's own docs on locators, mocking and authentication cover each pattern in detail.
Where conversions go wrong
Custom commands. cy.login() or cy.seedDatabase() have no direct equivalent. Turn each one into a helper or a fixture, and write down the new pattern so the team stops reaching for the old one.
Heavy network mocking. Intercepts with dynamic responses convert badly line by line. Recording a HAR file for the API is usually cleaner than rebuilding each handler.
Plugins. List the Cypress plugins the suite depends on and decide for each one: a Playwright alternative, a small rewrite, or no longer needed.
Multi-origin workarounds. Tests that jumped through hoops to cross domains can usually lose the hoops, because Playwright handles several origins and tabs on its own.
How to know the migration worked
Agree the gates before you start, or the cutover becomes a matter of opinion. Ours are a pass rate of 95% or more on the converted suite, no test that passes in Cypress and fails in Playwright, and each test run ten times with a flake rate and run time at or below Cypress. The last gate is human: your developers should be able to write a new Playwright test without help.
If the two suites disagree on a commit, one of them is wrong. Find out which before you cut over.
Common questions
Can I use AI to convert Cypress tests to Playwright?
Yes, and it is the fastest way to get a first draft of every file. Give the model fixed conversion rules, then review each result. Custom commands and mocks still need an engineer.
Should the new suite be TypeScript?
We recommend it. Types catch a whole class of mistakes in fixtures and helpers before a test ever runs.
Can Playwright MCP do the migration?
Not on its own. It drives a live browser, which helps after conversion to check flows and fix selectors, but it does not batch-convert Cypress files.
When can we delete Cypress?
After Playwright has been the CI gate for a while. We keep Cypress as a fallback for two weeks and remove it after five green production deployments.
Want this done for you?
Our Cypress to Playwright migration service follows exactly this plan, at a fixed price set in the proposal.
Written by the BetterQA team. BetterQA is a software testing company in Cluj-Napoca, founded in 2018, with 50+ engineers. Related: organising existing Playwright tests.
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
