Migrating from Cypress to Playwright means switching test automation frameworks while testing carries on as usual. Typical triggers are technical limits: missing iFrame support, scrolling problems in screenshots and dependence on third-party parallelization services. The switch works best with a hackathon to evaluate candidate frameworks, a clear priority on the critical test paths and a gradual migration alongside day-to-day work.
Key Takeaways
- A hackathon in which seven tools are tried out on real test scenarios from your own website gives you more confidence in the decision than any desk research or vendor demo.
- From version 13 on, Cypress blocks the third-party parallelization service “Currents”, which effectively forces teams that don’t want to pay for the expensive Cypress Cloud to change frameworks.
- At Displate, the move from Cypress to Playwright takes more than a year despite clear priorities, because the QA team has to keep its regular testing going at the same time.
- Translating Cypress code one to one into Playwright means fighting the framework instead of working with it, because the two tools handle sessions and data in fundamentally different ways.
- Tests that run permanently against production distort analytics data unless cookies and tracking parameters are deliberately switched off.
Why Cypress Hits Its Limits After Years in Use
Before a team moves from Cypress to Playwright, it usually has a long history with Cypress. The tool is quick to learn, but it pushes teams into a very specific way of writing tests. It comes with its own domain-specific language, its own logic for assertions and firm ideas about what a test should check. Step outside those ideas and you end up working against the tool instead of with it.
That became a problem at Displate, an e-commerce company that runs its own factory. Behind the visible shop there are plenty of in-house admin functions: managing artworks, handling copyrights, coordinating with artists. This mix of standard shop and custom code didn’t fit the assumptions Cypress makes about a typical test case.
iFrames were a recurring point of friction. Third parties such as payment providers are often embedded as iFrames, and Cypress can only handle them with additional plugins. Those plugins fix the problem for now, but every version upgrade means checking their compatibility again.
Screenshots on failure caused extra work too. On a very long page, the full-page screenshot didn’t reliably capture the spot where the test failed. It showed the header several times instead. One workaround followed another, and none of them turned into a clean solution.
Cypress Parallelization Is a Business Model, Not a Feature
Cypress charges for convenient parallelization in the cloud, and that is what triggered the switch. The framework itself is free, and you can build local parallelization with your own plugins. It only gets convenient through the paid Cypress Cloud or through third-party services.
The team used one of those third-party services because it needed more user seats, not more test runs. Cypress would have required a much bigger plan with lots of unused runs and showed no flexibility about the situation. That plan would have cost more than the entire QA budget for the year.
On top of that came a conflict between Cypress and the third-party service, which went so far that newer Cypress versions could no longer be used with it. The repository is still stuck on an older version today, the last one that was supported. For the team, that was the signal to leave the Cypress ecosystem altogether. The decision was made in September 2023.
How to Actually Choose a Test Automation Tool
A reliable selection doesn’t start with the market. It starts with how you use your current tool. Maciej Wyrodek and his team first looked at what they were using Cypress for, what worked well and what didn’t. That led to a broader question: how do we want to test, and what does a framework need to support that?
The answers became a list of criteria. In a large evaluation table, each tool got points, and some criteria carried more weight than others. About seven tools made it to the next round.
The market research itself was sobering. Between 2019 and 2024, little had changed in the tools on offer. The last major newcomer was Playwright, which was still young at the time. An earlier expectation that record-and-play tools would take over the market hadn’t come true. Such tools exist, but they are very limited and only fit the workflow when the requirements are quite specific.
The Hackathon: Proof of Concept Instead of a Feature List
A static evaluation isn’t enough. A tool has to prove that it holds up on your own system. So the evaluation table was followed by a hands-on day. QA engineers and a few developers built real proofs of concept with the candidates on the company’s own website.
To keep the results comparable, there was a fixed list of ten test scenarios. Everyone tried to implement the same cases in their tool. That showed how many tests each tool actually produced and how much effort it took to get there.
Weaknesses showed up right away. With one code-based tool, two experienced people couldn’t get a single test running in a whole day. The documentation was outdated after a major update, and answers could only be found in the issues of the GitHub repository. A tool you can only figure out through support tickets was ruled out.
“Then go and explain to your boss why, after all that research, you’re still choosing the tool that was the obvious pick from the start. But then you have the proof.”
(Maciej Wyrodek)
When AI Test Generation Needs Six Minutes to Reach the Cart
One AI-based tool generated tests from natural language, but the paths it produced were useless. The task was roughly this: go to the home page, pick the first visible product, add it to the cart, buy it. With thousands of products on the home page, the automation got lost.
Instead of going straight to a product, the tool clicked through menus, from one collection to the next, then to a brand page. Along the way it closed a newsletter pop-up on its own. Only after six minutes of clicking did the test land on a product page and add something to the cart. A scenario like that can’t be maintained.
The reason lies in how it works. A language model generates the path again every time you trigger the test. Only once a generated path is confirmed and locked in as a script do you get something stable. Without that step, the same tool finds a different route on every run.
Cypress or Playwright: Why Playwright Clearly Won
Playwright delivered the best results in the hands-on test and left the alternatives well behind. The only two participants who completed all ten scenarios both used Playwright. One of them used its recording feature. The other combined Playwright with an AI-assisted IDE and got all ten cases running reliably within the hackathon.
An honest caveat belongs here. The tests created this way weren’t production-ready yet. Without clean code, any change would have meant recording the whole test again, much like pure record-and-play. The hackathon showed the potential, not the finished result.
Even though the outcome was predictable, the effort was worth it. Only the hands-on test turned a hunch into a documented decision that the team could defend in front of management.
Cypress to Playwright Migration in Layers: From the Critical Path Outward
A sensible migration order follows the business value of the tests, not their order in the repository. The team had organized its end-to-end tests in several layers:
| Test suite | Purpose | Run interval |
|---|---|---|
| Top 10 | The ten most business-critical paths (“money makers”) in production | Every 10 minutes in peak season, otherwise every 30 minutes |
| Smoke suite | Runs after every deployment; a failure means fix or rollback | Per deployment |
| Full regression | Broad coverage; failures aren’t critical but get fixed quickly | Several times a day |
The team started with the top 10. These tests have to run fastest, they are rarely the simplest, and they cut vertically through the whole system. That is exactly what makes them a good first test for the new framework.
For the Cypress tests still running, a pragmatic rule applies. Small defects such as a changed locator get fixed in Cypress. If the logic of a test changes, the test moves to Playwright. Tests for new features are written in Playwright only.
Session Handling and Request Interception Differ More Than Expected
Frameworks don’t treat sessions, cookies and network requests the same way, and that gets expensive during a migration. What surprised the team most was the different approach to session management. The website runs many A/B tests and keeps data in local storage, session storage, cache and cookies. For tests to run reliably, all of that state has to be set up cleanly.
One concrete reason: many tests run directly in production. Analytics cookies have to be switched off, otherwise test runs show up in the reports. In the past, someone at the company had already noticed that a product page used a lot in testing got high visitor numbers but no purchases, simply because the automation opened it hundreds of thousands of times.
Intercepting API requests was more compact in Cypress. In Playwright, the same thing took more research. What had been a two-liner in Cypress, such as reading an authorization request, meant working through several guides in Playwright.
Blocking hosts was the most underestimated part. In Cypress, a single option in the configuration block was enough. Playwright has no direct equivalent, so the team had to build the request interception itself. The requirement wasn’t even on the criteria list, because everyone had quietly assumed that a tool with request handling would cover it.
Translating Tests Isn’t the Same as Rethinking Them
Can you convert Cypress tests to Playwright line by line? You can, but you get bad tests. The original agreement was to carry over the logic, not the code. Under deadline pressure, that rule got lost, and Cypress code was rewritten straight into Playwright. Maciej compares it to trying to turn a square back into a circle.
No single person failed here. This is what pressure typically does. The deadline gets closer, the new tool isn’t second nature yet, and the familiar old code becomes a crutch. People who are still learning fall back on patterns they know, even when those patterns don’t fit the new framework.
Some of these tests are old. One is older than the current QA lead’s time at the company. Tests that have grown like that need to be redesigned on purpose when they move, not translated.
AI as a Migration Helper: Promising, but Maintainability Is Still Open
AI can speed up the translation from Cypress to Playwright, but it isn’t yet clear whether the results are maintainable. One developer experimented with an AI-assisted IDE and gave it the Cypress repository, the Playwright documentation and the task of recreating a specific test in Playwright.
After a few attempts, the tests worked. In a live demo, though, the same process failed, which shows the usual gap between a one-off success and something you can reproduce. The approach is promising, but not yet reliable.
The bigger lever lies elsewhere. If the whole team learns to use the AI IDE better and write more precise prompts, tests get written faster. The key question remains open: will the generated tests be maintainable in the long run?
Bringing Frontend Developers into Test Automation
The move to Playwright is also a chance to anchor testing more firmly in the development team. Frontend developers already take part in the pull requests during the migration. Once the top 10 suite is stable, they are supposed to write and maintain their own tests.
That fits the way the QA team works. It doesn’t place one tester in each team. It works like a platform team that supports the others, similar to how a DevOps team is set up. Developers test most of their features themselves, and the QA team provides the methods and takes on the hard cases, such as how to test a new payment method in a particular market.
The result is a realistic view of the pace. There isn’t capacity for the migration all year round, and in some months there’s hardly any. A rotating responsibility spreads the automation work, and the order follows the backlog, where some capacity is deliberately set aside.
Frequently Asked Questions
Why do teams hit technical limits after several years of using Cypress?
Cypress comes with its own domain-specific language, its own assertion logic, and fixed assumptions about what a test case looks like. This often doesn’t work for highly customized software: iFrames from payment service providers can only be accessed via additional plugins, which must be re-tested with every version update. On very long pages, the failure screenshot repeatedly showed only the header instead of at the actual error location.
Why does parallelizing Cypress tests become a cost issue?
The framework itself is free, but convenient parallelization is only available through the paid Cypress Cloud or third-party providers. A team that simply needed more user seats, not more test runs, would have had to sign up for a significantly higher-tier plan, the cost of which exceeded the entire annual QA budget. Starting with Cypress version 13, it was also no longer possible to combine the third-party service being used.
Is a comparison table enough to select a test automation framework?
No. The table with weighted criteria narrowed the field down to about seven candidates; the actual decision was only made during practical testing. During a hackathon, QA engineers and developers implemented the same ten scenarios on their own website. In the process, a code-based tool failed to make the cut: two experienced people were unable to produce a runnable test in an entire day.
How much has the market for test automation tools changed recently?
Little has happened between 2019 and 2024. The last major tool to emerge was Playwright. The earlier expectation that record-and-play tools would dominate the market did not materialize: Such tools exist, but they are highly limited and fit into the workflow only for very specific requirements.
Are AI tools that generate tests from natural language already practical?
Not in real-world testing. The task of adding the first visible product on the homepage to the shopping cart resulted, with thousands of products, in a confusing journey through menus, collections, and a brand page. It took six minutes of clicking before the test reached a product page. The reason lies in the underlying mechanism: the language model regenerates the path with every run unless it is hard-coded as a script.
Which tests should a framework migration start with?
With the most business-critical paths, not the simplest ones. At Displate, they started with the “Top 10”: the ten tests that cover the revenue paths in production and run every 10 minutes during peak season. These must be the fastest and cut vertically through the entire system, which is why they put the new framework through a tougher test than a broad regression suite.
How should you handle existing tests in the old framework while the migration is underway?
A simple rule distinguishes between fixes and migration: Minor defects, such as a changed locator, continue to be fixed in the old framework. If a test’s logic changes, it moves to Playwright. Tests for new features are created exclusively in the new framework. Since regular test operations continue, the transition takes longer than a year despite clear prioritization.
Can Cypress tests simply be translated line by line to Playwright?
This results in poor-quality tests. Both frameworks take different approaches to sessions, cookies, and request interception, so only the logic should be carried over, not the code. Under time pressure, this rule is easily overlooked because the familiar old code becomes a crutch. Tests that have grown over the years (some are older than the QA lead’s tenure) require a deliberate redesign.
