Your Selenium suite is years of pre-AI IP. Locked up by maintenance cost. Reactivated in a sprint.

The Selenium test debt

Selenium is the granddaddy of browser automation, which means your suite has scars — test debt that's been accruing for years. Some tests were written against Selenium 2 with explicit WebDriverWait chains and a long list of By.xpath selectors that don't quite match the page anymore. Others use the Python-2 helper that one engineer wrote in 2017. The newer tests use Selenium 4, but only on a subset; the rest break on the wrong browser version, or on JUnit 4 lifecycle hooks that the current driver doesn't tolerate.

The choice is almost always the same: rewrite by hand (months, $20K+, painful), keep ignoring the broken tests, or move onto a framework with a friendlier autowait model and hope someone else writes the rewrites. The sprint gives you a fourth option — pick the highest-value tests in your suite, ship those in 30 days with our migration tools doing the mechanical work, and queue up the rest as a prioritized list for your team.

Two paths the sprint covers

Path A — modernize in place

Keep Selenium as your framework. Bring everything onto Selenium 4 in your target language (Python, Java, JavaScript, or C#). Replace explicit-wait soup with idiomatic waits. Unify the JUnit / pytest / TestNG lifecycle so the test runner stops surprising you. Re-locate flaky selectors using the live page rather than a six-year-old DOM dump.

Path B — migrate onto Playwright

Some teams take the sprint as the cutover. Selenium goes in, Playwright in TypeScript or Python comes out. Same test logic, modern locators (getByRole, getByLabel), built-in autowait, faster runs. The triage list flags any Selenium API call without a Playwright equivalent so you know what to revisit intentionally rather than discovering it in CI.

Where AI ends and your team starts

AI converts the test logic easily — the navigation, the assertions, the data flow, the order of operations. Selenium 2 to Selenium 4 in the same language is mostly mechanical and the conversion is clean.

The work that needs your team's hands is the cross-language, internal-utility, and custom-call layer. A Python helper that wraps selenium.webdriver.support.expected_conditions doesn't have a direct Java twin. A custom page-object pattern your team built lives in your repo. Project-internal calls into your shared helpers/auth.py or BasePage.java reference things only your codebase sees. AI flags those, drafts a reasonable conversion, and notes which lines a senior on your team should review before merge.

The reason we draw the line there: those library-specific tweaks live in your environment for a reason. Your team can adjust them in minutes because they have the source, the build, and a green CI run as feedback. An outside team would take hours guessing, and might guess wrong. That said, we don't disappear at the line — the sprint includes paired work with your team on translation + wrapper bits that need shared context. We don't auto-do it; we collaborate on it.

What the AI flags as missing

Selenium tests describe what to click but rarely describe what the page looks like, what the data flow assumes, or which helper functions live where. 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 test that calls PageObjects.login(user) when the page-object file wasn't in the upload, a step that depends on By.id("nav-2026") on a page whose IDs rotate every quarter, a fixture file referenced as conftest.py:db_seed() with the seed SQL not included — all flagged as questions for your team rather than 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 between Selenium 2's rendering and today's. A login flow needs an MFA code that wasn't in the test data. An assertion looks for "the order confirmation" but two confirmations 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 a senior tester would just figure out and move on from. 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.

What we accept and what we produce

Connect to what you have

Selenium tests usually live in a Git repo plus a TMS or two. We connect to all of them.

• Repo upload — point us at the test directory; we read pytest configs / pom.xml / package.json so we know your toolchain
• TestRail / Xray import — for the manual side of your suite, pull cases directly via API
• Reverse-proxy connection — staging environments behind a firewall? We stand up a one-way reverse proxy so the runner reaches your site without us touching your network
• Almost any artifact — if it looks like a test case definition in a structured way, the importer accepts it. Send a sample if you're unsure

Beyond the test conversion

Selenium migration is the headline. It's not the only thing the sprint delivers — the AI-driven assessment runs alongside the conversion, giving you broader coverage and an overall AI-strategy read.

• AI bug detection — fully automated bug-hunting on your real site across personas, UX, accessibility, perf, and content. Surfaces issues your Selenium suite isn't looking for.
• Risk assessment — four-dimensional read on code blast-radius, GenAI smell, user frustration, and business risk.
• Quality scoring — multi-attribute jank score across 12 dimensions.
• Competitive quality metrics — how your site benchmarks against peers in your industry. Issue counts, severity, persona-rated UX, perf, 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.

The Selenium math

Three buckets, not one. Conversion savings are visible. Maintenance and execution-time savings are where Selenium teams typically see the larger return.

Bucket 1 — Conversion savings (one-time)

A senior automation engineer at $125/hour, ~25 minutes per case to modernize idiomatically — Selenium cleanup runs slow because you're often fighting old WebDriver behaviors, not just rewriting steps. The high-priority subset of a typical Selenium backlog is roughly $10,000 of hand-work for one engineer over a month, if that's the only thing they do. The sprint matches the cost and beats the wall-clock.

Bucket 2 — Maintenance savings (annual, compounding)

Classic Selenium suites cost ~$9,000/year per ~100-case suite just to keep green — selectors rot as the page changes, new browser/driver versions break old waits, deprecated APIs need swapping. Modernized Selenium 4 output cuts that materially (idiomatic waits, role-based locators). Playwright output cuts it further (autowait, better locators). Conservatively a 40–60% drop in test-maintenance cost over three years.

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

The biggest hidden cost is the time spent running tests by hand before each release. If your team is still manual-running the 150 cases in TestRail before every cut, that's ~$3,000–$5,000 per release at $75/hour, ~$45,000/year on execution alone. Automated execution is essentially free per run.

Three-year picture for a typical Selenium team

$10K sprint · ~$15K saved on conversion vs hand-rolling · ~$15–20K saved on maintenance vs classic Selenium · ~$120K saved on manual execution. The conversion is the headline; the execution + maintenance savings are where the real money is.

Or you might want…

Two sibling paths cover the other common starting points.