Your test suite is millions in pre-AI IP. Locked up — too costly to run, too brittle to maintain. Reactivated in a sprint.

The problem

Every QA org has test debt — the folder of test cases nobody can run anymore but nobody is willing to delete. The manual "login then verify the cart" steps from 2019. The Selenium suite from when Python 2 was still a thing. The Playwright tests that depend on a CI image that was retired. The Cucumber features the BA wrote with the developer who left.

The cost of porting them by hand is what keeps the debt on the books. A senior automation engineer at fully-loaded $125/hour rewrites about 25 cases a day. The high-priority subset of a typical team's backlog is months of work at that rate. Most teams won't pay that bill; they'll keep the stuck tests, run a subset of new ones, and hope.

The Upgrade App is the alternative — a fixed-price sprint that targets the quickest wins in your backlog, converts them using the migration tools we've built (doing the mechanical work ~10× faster than rewriting by hand), runs each one against your real site, and hands back a runnable subset plus a prioritized triage list for the rest. Not every case ships in 30 days — but the ones that matter most do.

How it works

Four stages in a line. Each one has a clear job; each can be inspected and re-run independently.

The middle stage — convert — is what makes this work. Every input format flattens to one common shape. Every output target reads from that same shape. Adding a new input language or a new output target is a small change, not a rewrite. That's the architectural bet: keep the complexity at the edges, keep the middle simple.

The run stage is where the surprises live. A converted test will sometimes reference a selector that doesn't quite match your real page — fields move, labels change, banners appear that weren't there when the test was written. The auto-repair loop catches the failure, takes a screenshot, figures out what was actually meant, and retries. About a quarter of otherwise-failing steps recover this way without any human intervention.

What we support

The polyglot promise: anything reasonable as input, any common framework as output. If your tests are already in one of these, you don't have to translate before the sprint starts.

Most teams pick the framework they already have in CI so the converted suite drops straight in. Teams that want to migrate frameworks at the same time pick the new one and use the sprint as the cutover.

Where AI ends and your team starts

AI converts the test logic easily — the navigation, the assertions, the data flow, the order of operations. The shape of the test is preserved across languages because the shape was never language-specific to begin with.

Where it stops being easy is when the conversion spans languages or hits your internal utilities. A Selenium-Python test that pulls in a custom helper from your team's shared library, a Playwright spec that wires into a TypeScript page-object pattern your team built, calls into helpers/auth.ts / fixtures/db_seed.py / cypress/support/commands.js that live in your repo — those framework-specific calls, library imports, and internal utility wrappers often need a manual pass after the sprint. Sometimes a one-line tweak. Sometimes a small refactor of an internal helper. Either way, it's work your team does faster than anyone external — they have the source, the build, and the environment.

This is by design, not a limitation. The sprint hands you converted runnable code and a triage list of the cross-language adjustments worth looking at — short, targeted, easy to walk through in a morning. Nothing is hidden; nothing is silently rewritten in a way you'd struggle to review.

What the AI flags as missing

Test code and manual cases describe the happy path. They rarely describe what the page actually looks like, what the data flow assumes, or what state the user is in. The AI runs into those gaps constantly and is built to ask, not to guess.

Before the sprint runs the tests — during conversion — the AI flags ambiguities it can't resolve from the source alone. A Selenium test that calls helpers.login(user) without showing the helper's signature, a manual case that says "verify the dashboard shows today's orders" without saying what "today's" means in this timezone, a Cypress spec that references cy.fixture('customer.json') with a fixture that wasn't in the upload — all flagged as questions for your team, not silently guessed.

During the burn-in — when the converted test runs against your real site — the AI catches a different class of gap. A selector misses because a button moved, but the test description doesn't tell the AI what to look for instead. A login flow needs an MFA code that's not in the test data. An assertion looks for "the success banner" but two banners are visible. Each one becomes a clarifying question with a screenshot of the page state and a one-line ask.

These questions are the most valuable artifact of the sprint after the runnable suite itself. They surface gaps in your test code, your manual cases, and your documentation that nobody noticed because a human tester would just figure it out and move on. Now they're written down. Your team answers each one in a sentence, the suite re-burns, and the documentation gets better as a side effect.

Connect to what you have

Tests live in lots of places. We connect to the ones you already use, and we run against environments your public internet can't reach.

If you have something that looks like a test case definition and it isn't on this list, send a sample — odds are it already imports cleanly, and if it doesn't we'll add it. The polyglot importer was designed to accept almost anything that describes a test in a structured way.

Beyond the test conversion

Test migration is the headline of the sprint, but it's not the only thing the sprint delivers. The AI-driven assessment runs alongside the conversion — broader coverage, more recommendations, and an overall AI-strategy read for your QA practice.

What runs alongside the conversion

• AI bug detection — fully automated bug-hunting on your real site across personas, UX, accessibility, perf, and content. Surfaces issues your converted tests aren't looking for yet.
• Risk assessment — four-dimensional read on code blast-radius, GenAI smell, user frustration, and business risk, scored across your site.
• Quality scoring — multi-attribute jank score (12 dimensions: correctness, security, reliability, performance, data integrity, privacy, accessibility, architecture, maintainability, observability, testing, AI-agent risks).
• Competitive quality metrics — how your site benchmarks against peers in your industry. Issue counts, severity distribution, persona-rated UX, performance, and accessibility compared to a curated peer set. You see where you stand, not just where you are.
• AI-strategy recommendations — based on what the assessment surfaced: which tests to write next, where the AI is high-confidence vs needs a human, which dimensions to invest in over the next two quarters.

The ROI math

Three buckets, not one. The sprint pays for itself on the conversion alone — but the maintenance and execution-time savings over the suite's life are typically larger.

Bucket 1 — Conversion savings (one-time)

A senior automation engineer at $125/hour fully-loaded rewrites about 25 cases a day. The high-priority subset of a typical backlog is roughly $10,000 of hand-work for one engineer over a month if that's all they do (in practice it stretches to 6–8 weeks). The sprint matches the cost, beats the wall-clock, and leaves you with the toolchain warm for the long tail.

Bucket 2 — Maintenance savings (annual, compounding)

Classic Selenium and Playwright suites cost ~$9,000/year per ~100-case suite just to keep green — selectors rot as the page changes, new browser versions break old waits, deprecated APIs need swapping. Modernized output from the sprint cuts that materially (cleaner locators, autowait, role-based selectors). AI-first execution cuts it further still — the runner adapts to drift rather than failing on it. Conservatively a 40–70% drop in test-maintenance cost over three years, depending on which output target you land on.

Bucket 3 — Manual execution savings (per release, compounding)

The biggest hidden cost is the time spent running tests by hand before each release. A typical 100-case smoke pass is 30–60 minutes per case for a manual tester if you include setup, teardown, and writing up the result — call it 40 minutes average. At $75/hour for a manual tester, that's $3,000–$5,000 per full pass. Monthly releases = ~$45,000/year on manual execution alone. Automated execution is essentially free per run.

Three-year picture for a typical team

$10,000 sprint · ~$15,000 saved in conversion vs hand-rolling · ~$20,000 saved in maintenance vs classic suites · ~$120,000 saved in manual execution vs running by hand monthly. The conversion is the visible payoff. The execution + maintenance savings are where the real money is.

If your stack is one of these

The general sprint covers any mix. Three sibling articles go deeper on the specific flows our customers ask about most.