Selenium → Playwright migration
We migrate Selenium suites to Playwright — and find the defects the green build was hiding. Free read-only assessment. Findings with file and line, in 48 hours.
22-test public suite migrated · 5 defects it was passing with · you keep the code
A real Selenium suite
Public repo, Java, TestNG, data-driven. Better structured than most suites we audit.
Run it
Every test passes. This is what the team sees every day.
Same run, one query later
One test clicked the wrong row, saw "Successfully Updated", and passed. Intermittent. Nobody would ever find it.
Migrated to Playwright
Runs anywhere, in parallel, from a clean checkout. Admin still works.
Read the five findings ↓A test that cannot fail is not a test. Most Selenium suites we read have several — and they have been passing for years.
The findings
Found by migrating it, not by running it. None of these ever goes red.
"The second button in the results container", clicked before the search filters. On a slow instance that is row one — Admin. The assertion sees "Successfully Updated" and passes, because a user was updated. The wrong one.
Two static fields carry state between classes. Nothing declares it; only the order in the suite file holds it together. Four identical parallel runs: 7, 3, 2 and 0 failures.
It works only because the next assertion happens to block long enough. Move the code — any maintainer eventually will — and three tests downstream fail on a record that was never created.
They assert on the first "Required" hint on the page, not the one for the field under test.
One specific database with two specific employees, two security policies switched off, and a real display session. None of it written down.
These are not sloppiness. They are what happens to any UI suite that waits on pages instead of records. The same ones turn up in production suites at companies with test teams.
What you get
How it works
Read access to the test repo — a collaborator invite or a zip. Within 48 hours: what is done well, what is costing you, what migration would and would not change. Every finding with file and line.
Pick the ten that break most. We convert them, running in your CI. Fixed price agreed up front. You keep the code whatever you decide next.
The rest of the suite the same way, then a recorded two-hour handover — add a test, read a trace, debug a failure — so your team runs it from day one.
A migrated suite decays as features ship. We keep it alive: new coverage, flakes fixed inside a day, nothing merges on red.
About MigrateQA
We do Selenium-to-Playwright migrations and nothing else. Playwright is what we work in every day; Selenium is what we spent years maintaining before that.
The engineer who audits your suite is the engineer who migrates it — no handoffs, no juniors, no account managers. Findings in the report are the findings in the pull request. Everything up to the handover call happens asynchronously in your repo and your CI, on hours that overlap UK afternoons and US mornings.
Every number on this page traces to a log. The migration repo — original suite, migrated suite, the Docker environment, the mutation-sweep results including the one we had to throw out — is shared privately with anyone considering an assessment.
Before trusting a green check, confirm the check can go red. Every migrated test is deliberately broken once and proven to fail before it counts.
Findings say what the evidence supports and no more. When a number cannot be measured cleanly, the report says so instead of rounding up.
Nothing is installed, deleted or run against a client system without being written down first.
Questions
Yes. They have had years and haven't, because migration never wins against a feature deadline. You are not buying a skill your team lacks — you are buying the only two weeks anyone will ever spend on it.
Partly. Reusing the browser and running in parallel gets time back — if the tests are independent. On the suite above they were not, and parallelism broke them. Playwright gives you the independence, the built-in waiting, traces on failure and half the code to maintain. The speed is a side effect.
No. The assessment is read-only on the test repository. The pilot runs in your CI with credentials you control. Nothing runs against your environments from our side.
That is what the pilot is for. Fixed price, one week, and you keep every line of converted code whatever happens next. Nobody has to trust us for a full migration — only for ten tests, once.
If nothing turns up, you have lost an hour of our time and none of yours.
hello@migrateqa.com