Migrating from Cypress to Playwright

Migrating test automation frameworks means moving an entire end-to-end test suite from one tool to another while daily testing work continues. Teams typically run a structured hackathon to evaluate candidate tools against real test scenarios before committing. The switch from Cypress to Playwright commonly surfaces hidden gaps: session management, request interception, and full-page screenshot behavior all work differently between the two frameworks.

Key Takeaways

• Choosing the most popular framework for the wrong context creates compounding workarounds: Cypress was a poor fit for iFrame-heavy payment flows, full-page screenshot needs, and specific React scroll behavior.
• Vendor lock-in on parallelization killed the Cypress relationship: Cypress blocked third-party orchestration tools above version 13, leaving teams either paying multiples of their QA budget for Cypress Cloud or freezing on an outdated version.
• A one-day hands-on hackathon with real test scenarios on the actual product reveals tool fit faster and more reliably than any static feature comparison or vendor demo.
• AI-assisted migration from Cypress to Playwright shows early promise but requires careful prompting, feeding both repos and documentation to the agent, and the results still need human review for long-term maintainability.

Why a popular tool can still be the wrong fit

The most popular test automation tool is not automatically the right one for your context. Cypress is fast to learn and widely used, but it pushes a specific way of writing tests that does not match every project.

Cypress comes with an opinionated domain-specific language. It largely dictates how assertions look, what a test checks, and how the test is structured. When your needs diverge from that intended style, you write against the framework instead of with it.

Plugins fill many of the gaps, and Cypress has thousands of them. The cost shows up later: keeping plugins current and compatible across Cypress versions becomes its own maintenance burden. A tool that needs a stack of plugins to do what you want is a signal worth reading.

Maciej Wyrodek points to a concrete pattern from his work at Displate. The team’s way of writing tests, and what they wanted those tests to do, kept pulling away from what Cypress offered out of the box. That mismatch, repeated across many tests, is the real reason to reconsider a framework, not a single annoying bug.

The technical frictions that pile up

Individual technical limits rarely justify a migration on their own. Stacked together over time, they do.

Third-party iframes are a known sore spot. Payment flows often live inside iframes, and Cypress handles them awkwardly. A plugin makes it possible, but iframe handling stays fragile.

Full-page screenshots on failure caused real pain for a long web page. When an assertion checked an element below the fold, the captured error view did not always show the correct scroll position. A documented issue with certain React configurations repeated the page header several times in a full-page capture instead of rendering the page once.

Each of these had a workaround. The problem is the shape of the result: workarounds layered on workarounds. When your test suite is held together that way, the framework has stopped serving the team.

How Cypress parallelization turned into a business problem

The decisive break was commercial, not technical. Cypress sells parallelization as a paid service, which changes the calculation for a larger organization.

In the Selenium era, you could self-host a Selenium grid and run your own parallelization, or buy grid capacity from providers. Cypress took a different path and built a business around parallel runs. The framework itself is free, but scaling test execution leads toward paid hosting.

Displate used Currents, a third-party alternative to Cypress Cloud. For an organization of their size, Cypress Cloud came out roughly 10 to 20 times more expensive than Currents, driven by how Cypress packaged users and runs together. The team needed more users, not more runs, and Cypress was not flexible about that combination. The Cypress Cloud package they were pushed toward would have consumed more than the entire QA budget for the year.

The relationship then deteriorated. Cypress blocked the ability to use Currents from version 13 onward. Displate stayed on Cypress version 12, the last version Currents supports, and decided to leave the Cypress ecosystem.

The lesson generalizes beyond one vendor: when a tool provider treats you as a captive rather than a partner in negotiation, that is itself a reason to plan an exit.

Why a tool migration takes far longer than the decision

The decision to leave a framework is fast. The migration is not.

Displate decided to leave Cypress in September 2023. The actual move stretched across the following year and beyond, because the team carries day-to-day testing work the whole time. Maintaining existing tests and supporting development does not pause while you swap frameworks.

A migration that competes with regular delivery cannot run from day to day. It needs reserved capacity and a realistic timeline, or it slips. Treat the move as a long-running project with frozen capacity, not a sprint goal you bolt onto a busy quarter.

How to evaluate automation tools without guessing

Selecting a framework starts with understanding your current one, not with chasing the market leader. Look first at what you actually use, what you like, and what fails you.

From that concrete list, move to the general question: what do you want from an end-to-end framework, and what is your approach to testing? Turn that into criteria you can score against. Displate built a scoring table where some criteria carried more weight than others, and narrowed the field to about seven tools.

Static research only goes so far. Demos and documentation tell you what a vendor wants you to see, not how the tool behaves on your own site.

The market itself surprised the team. Comparing the 2024 landscape against research done back in 2019, little had genuinely changed. The last big arrival was Playwright at the start of the pandemic. The wave of record-and-play tools that once looked set to dominate stayed niche, usable only when your needs fit their narrow shape.

Why a hands-on hackathon beats a feature checklist

A practical proof of concept reveals what a feature matrix cannot. Displate ran a hackathon with quality engineers plus interested backend and frontend developers, testing the shortlisted tools against ten prepared test cases.

The ten fixed scenarios served two purposes. They created a common baseline, so people were not each writing different tests, and they let the team count how many cases each tool could actually handle.

The hackathon exposed problems that no spreadsheet caught. One coded tool could not produce a single working test in a full day, even following the documentation and quick-start guide. A recent framework update had left the docs so out of date that the only path forward ran through GitHub issues. Having to dig through support tickets instead of reading documentation was, by itself, a disqualifier.

Here is the uncomfortable payoff. After all that research, the team chose Playwright, the most popular option and the obvious candidate from the start. The difference is that now the choice rested on proof, not assumption, and that proof is what you show your management.

What AI test generation actually did during the evaluation

AI-driven test generation looks impressive and does not yet replace a maintainable test suite. One evaluated tool offered an AI component that took a BDD-style description and generated a test.

A developer pasted in the prepared instructions: go to the homepage, select the first product, add it to cart, buy it. The tool scanned the page and improvised. It wandered through menus and collection pages, jumped to a brand page, dismissed a newsletter pop-up on its own, and after roughly six minutes of clicking finally reached a product page and added it to cart.

The path the tool took matched nothing in the prepared scenario. Under the hood, an AI agent first generated a path, and once approved, wrote it out as a script. Run again later, the same prompt would likely produce a completely different path, because the language model regenerates the route each time.

That non-determinism is the catch. A test that takes a different route every run is hard to trust and harder to maintain.

How Playwright performed in the same hackathon

Playwright produced the strongest results in the head-to-head. A developer using Cursor together with Playwright’s recording inspector wrote all ten cases and stabilized them during the hackathon itself.

Only one other approach also completed all ten: strict record-and-play. Playwright with AND code assistance reached the same completion while staying code-based.

The result carries a caveat worth keeping. The generated tests were not built for maintainability. If something changed, you would likely re-record the whole test, much as you would with a record-and-play tool. The hackathon proved the tests were possible, not that they were durable.

The wider team reached the same conclusion through a closing demo where everyone showed their tool and their opinion. A few options performed well. None competed with Playwright.

Why critical paths go first in a migration

Migrate the most critical tests first, because they need to be the fastest and they cut a vertical slice through the system. Displate organizes end-to-end tests into three tiers, and the order of migration follows that structure.

The top 10 are the critical money paths, run against production. They are not the easiest tests to write, but moving them first delivers a working safety net on the new framework and forces the hard integration questions early.

From there the plan is incremental. New functionality is written only in Playwright. Existing Cypress tests get moved when a real logic change is needed; a trivial locator fix can still be patched in Cypress until the test’s turn comes.

What surprises a migration even after thorough research

Even careful evaluation misses things, because frameworks handle the same job differently. Session management caught the team off guard.

Displate runs many A/B tests and keeps data in local storage, session storage, cache, and cookies. Tests run against production as well as test environments, on the principle that no test environment sits as close to production as production itself. So tests have to strip analytical cookies first, or they pollute real data.

That risk is not hypothetical. A poster page used heavily in automation racked up so many daily visits that someone in the company suggested approaching the artist about a promotion, reading the test traffic as genuine interest that was not converting.

API request interception, assumed to be equivalent across frameworks, was not. In Cypress, intercepting an authorization request took roughly two lines. In Playwright, the team had to research the right setup across scattered documentation. Blocking hosts was simple in Cypress through a config option; in Playwright, they had to write the host-blocking logic themselves. None of that appeared in the evaluation spreadsheet, because they assumed request handling implied it.

A subtler trap is rewriting instead of re-thinking. The team had agreed not to port Cypress code line for line, but to rebuild tests from the logic. Under deadline pressure, with the new tool not yet fully mastered, people drifted back into translating Cypress patterns into Playwright. That is square-peg-into-round-hole work, and it is a normal failure mode, not anyone’s fault.

How to find capacity for migration inside normal delivery

Capacity for migration comes from prioritization and timing, not from extra hours. Displate used most of December because the holiday season brings little feature development. The weeks from before Black Friday through Christmas are when the company makes most of its money, so large features stay out and the calendar opens up for cleanup and migration.

The team operates like a platform team rather than one tester per delivery team. Most developers test their own work, and the quality engineers provide support: researching how to test payments in a new market, or figuring out how to cover something a team has no idea how to test. That model frees time for maintenance work, but only when the roadmap allows it.

The honest version of capacity planning admits the limits. Looking ahead, the team expected little automation time in some months and froze a portion of capacity in the backlog rather than pretending the work would simply fit. Right now a rotation lets two people support teams while one writes automation, so everyone keeps a hand in the new tool.

Where AI fits into the migration itself

AI can accelerate the transition, with maintainability still the open question. A developer experimented with Cursor to translate tests from Cypress to Playwright by giving the AI agent the Cypress repo, the Playwright documentation, and the target Playwright code, then asking it to produce a specific test.

After a few attempts, it generated tests that worked. The catch is the same one that runs through this whole topic: whether those translated tests are maintainable is not yet proven. The demo for the wider team failed on the day, even though earlier private runs had succeeded.

The realistic read is that better prompts and more team fluency with the tool will raise the speed of writing and translating tests over time. Treat AI translation as a tool that needs learning, not a switch that finishes the migration for you.

Pulling front-end developers into automation is the parallel gain. With Playwright, developers participate in pull requests, and the plan is to let them write and maintain their own tests once the top 10 are stable. That shift, long wanted and easier on Playwright than it was on Cypress, may matter more than the framework choice itself.