Migrating from Selenium to Playwright: what does it involve?
You spent years building your Selenium suite. It works, but it requires constant intervention. Fixed waits accumulate, selectors break with every redesign, and nobody dares to touch the core because everything might fail at once. You have decided to move to Playwright. The question is what that actually involves.
A common assumption is that the suite will be “rewritten”: each test is taken in turn and translated into the new language. A mechanical rewrite tends to be expensive and can carry the original suite’s weaknesses into the new tool.
Common problem: a literal rewrite also migrates old weaknesses
The suite’s value lies primarily in its valid scenarios and assertions: knowledge about how the product should behave, what should happen after a form is submitted, what message should appear for an invalid payment, and which input combinations have failed in the past. The code, integrations, and diagnostic mechanisms need to be assessed separately, because they too may contain reusable parts or technical constraints.
The code is only the way this knowledge is recorded. And that record is exactly what causes pain today: fixed waits, unstable selectors, and missing structure. If we translated it mechanically, you would get the same problems in a newer tool. You would pay for the migration and be back where you are today a year later.
We therefore select the valid scenarios and assertions from the old suite and assess the code, integrations, and diagnostics separately. We neither migrate them automatically nor discard them all without review.
How to migrate valuable scenarios
First, we review the current suite and determine what it actually covers. Some tests are dead: they verify a feature that no longer exists in the product or have been skipped for years. We do not migrate those. Others test the same thing three times in different ways. It is useful to identify this before work begins as well.
We migrate the rest onto a foundation designed for easier maintenance:
- An appropriate layer of page or component objects. Shared elements are described centrally, so a change often does not need to be repaired separately in every test.
- Stable identifiers. We base selectors on what has meaning on the page: visible text, the element’s role, or test identifiers agreed with developers. We do not base them on a position in the page structure or a class generated by the framework.
- Separate test data. A test creates what it needs and cleans up afterwards. Tests then do not interfere with one another’s data and can run concurrently.
The migration proceeds gradually by priority, with critical journeys first. The old and new suites can run side by side for a period, and a coverage map identifies which one checks each regression scenario. This avoids a planned period without checks of all agreed critical journeys.
What the new foundation gives you
Before actions, Playwright performs element-readiness checks and supports retrying assertions. This can remove many fixed waits. Stability still depends on the data, environment, selectors, and scenario design.
Playwright supports projects for several browser engines. Depending on the configuration, it can save a screenshot, video, or trace when a test fails to help with diagnostics; not every output is created automatically under every configuration.
We write the new suite in a language that fits your team—most often Python, or TypeScript if the tests should live alongside the frontend. We integrate it with CI/CD from the first migrated scenario, not only at the end of the project.
When migration does not make sense
If you have a large Grid infrastructure and a team that knows Selenium well, leaving it may not be the right decision. In that case, it may be better to change only the architecture or language and keep the tool. If the suite is sound but merely unstable, it is often less expensive to repair it than to migrate it.
We will tell you when migration is not worthwhile too.
Next step
Show us the current suite and tell us what causes the most pain. Contact us and we will assess what is worth migrating, what to discard, and in which order.