Most evaluations of an AI testing platform don't fail on the demo. They fail about a week later, when someone works out what adoption actually costs.
The demo is genuinely impressive: a user story goes in, a full set of test cases comes out, and they run. Then a senior engineer asks the question that ends the meeting — "so what happens to our 2,000 Cypress tests?" And the honest answer, for most tools on the market, is: nothing. They stay where they are. You run two systems in parallel, or you spend two quarters rewriting.
That's not a pricing objection or a feature gap. It's a migration tax, and it's the reason a lot of teams who *want* AI-assisted testing are still not using it.
The two options nobody likes
Faced with that tax, teams get offered a choice between two bad plans.
Start fresh. Point the AI at your user stories, generate a new suite, and treat the old one as legacy. Clean in a slide deck. In practice you now have two suites covering overlapping ground, two sets of failures to triage every morning, and an old suite that nobody maintains but nobody dares delete — because nobody is quite sure what's in it that isn't anywhere else.
Run both indefinitely. Keep the existing suite as the source of truth and use the AI tool for new work only. This is the safer plan and it's what most teams actually do. It also means the AI tool never touches the 80% of your coverage that already exists, so the maintenance burden it was bought to reduce is barely reduced at all.
Both plans share an assumption worth challenging: that the tests you already have can't come with you.
What's actually in your test suite
Here's the part that gets undersold, usually because it doesn't fit on a slide.
Your automation suite is not just executable code. It's the most accurate documentation of your product's behaviour that your organisation owns — and a large fraction of it exists nowhere else.
Somewhere in that repository is a test asserting that the discount recalculates *after* the shipping method changes, not before. Nobody wrote that in a requirements document. It's there because it broke in production in 2023, someone spent a bad Thursday on it, and the fix came with a test. Multiply that by every incident your team has had, and the suite becomes an archive of hard-won knowledge about how your system actually fails.
A requirements document tells you what someone intended. A test suite tells you what the system actually does, including everything that had to be learned the hard way.
That archive is exactly what "start fresh" throws away. An AI generating test cases from your current user stories will produce good coverage of what those stories describe. It will not produce that discount-recalculation test, because nothing in the story mentions it. The knowledge only lives in the old suite.
So the question isn't whether to migrate. It's what to migrate — the code, or the knowledge in it.
Why a script-to-script converter isn't the answer
The obvious-sounding solution is a translator: point a tool at your Selenium suite, get a Playwright suite out.
This is a lateral move that solves nothing. You already have a working script. A translated copy of it is another working script — and now you maintain two. The maintenance problem, which was the actual complaint, is untouched. Worse, the translation is only as good as its handling of your helpers and fixtures, which is where these tools reliably fall over.
The useful move is to extract the intent and let the platform own the execution.
| What goes in | What you get back | |
|---|---|---|
| Script-to-script converter | Selenium code | Playwright code, and two suites to maintain |
| Importing intent | Selenium code | Test cases the platform maintains, heals and traces — that can also emit Playwright code |
That second row is the difference. Once a test lives as steps and expectations rather than as locators and waits, the platform can re-resolve those locators when the UI changes, link it to a requirement, include it in a risk-ranked selection for a pull request, and — if you want the code back — generate it in whatever framework you like. None of that is available to a translated script.
The hard part is page objects, and it should be said plainly
Any honest account of automated migration has to deal with this.
Real test suites don't put their actions inline. They put them behind page objects, fixtures, custom commands and helper modules. A test that reads `await checkoutPage.completePurchase()` contains almost no information on its own. Everything that matters is one file away.
So an importer that only parses the test file produces confident nonsense: a step that says "complete purchase" and no idea what that involves. That's worse than producing nothing, because it looks finished.
The workable approach is to resolve those imports and read the helper alongside the test — flattening `completePurchase()` back into the concrete actions it performs, so the imported test case reads as plain steps a manual tester could follow. That covers most real code. It does not cover all of it. Helpers that are generated at runtime, deep inheritance chains, conditionals that depend on environment state — these can't be resolved by reading source, and pretending otherwise is how you get a suite full of plausible-looking tests that don't match the system.
Which leads to the design decision that matters more than the extraction itself.
That's why an import shouldn't go straight into your suite. It should land in a review, where the extraction sits side by side with the source it came from, and nothing becomes a runnable test until someone accepts it.
What this looks like in practice
In QAEverest this is Generate Test Cases → By Repository. The shape of it:
- Connect a repository — GitHub, GitLab or Bitbucket, read-only. Pick a branch, and optionally narrow to a folder like `tests/e2e`.
- Preflight, before you commit anything. It reads the tree and reports what it found: which frameworks, how many test files, in which folders, and an estimate of how many test cases that will produce. This step is free — you see the scope before you spend anything.
- Extraction. Each test file is read together with the page objects and helpers it imports. Out comes a QAEverest test case: title, steps, expected results, test data, priority, tags — plus a confidence score, the source excerpt, and any unresolved calls.
- Review. A folder tree mirroring your repository on one side, the extracted test cases on the other. Edit, accept, reject; filter to just the low-confidence ones; bulk-accept a directory you trust. Nothing runs yet.
- Proceed to Automation. Accepted cases become modules that mirror your repository's directories, one suite per test file, filed into UI, API or Mobile Automation.
Playwright, Cypress, Selenium, WebdriverIO, pytest, JUnit/TestNG, NUnit, RSpec, Go, PHPUnit, Cucumber and Robot Framework are all recognised.
The folder mirroring is a small thing that turns out to matter a lot. If your repository has `tests/e2e/checkout/cart.spec.ts`, that's where it lands — under a `checkout` module, in a suite called `cart.spec.ts`. Nobody has to learn a new map of their own test suite on day one.
What it doesn't do
Worth stating, because tools that skip this section are the ones that disappoint later.
- It doesn't run your original code. Imported tests are executed by QAEverest's engine, as QAEverest test cases. If you need your existing scripts to keep running exactly as they are, keep running them — this is a migration path, not a wrapper.
- It doesn't import your framework config. Custom reporters, CI wiring and environment bootstrapping are yours; the import is about test intent.
- It won't be perfect on the first pass. Suites with heavy runtime indirection will produce more low-confidence cases. The review is where that gets resolved — and it's why bulk-rejecting a directory is a first-class action, not an afterthought.
- It isn't free. Connecting, preflight and review cost nothing; extraction is billed per test case extracted, so you pay for what you keep and can scope a run to one folder to try it.
The point
The strongest argument for keeping your existing suite isn't sentimental and it isn't about sunk cost. It's that the suite contains information about your product that nothing else in your organisation records — and any migration plan that starts by discarding it is starting by discarding your best documentation.
Bring it with you. Review what survives the trip honestly. Then let the platform do the part your team never wanted to do by hand: keeping it alive as the UI changes.
*Ready to try it? Connect a repository under Generate Test Cases → By Repository — preflight will tell you what's in there before you spend a credit.*
