Your Selenium suite works. It drives a browser correctly, it has years of institutional knowledge baked into its page objects, and the team that built it knows exactly where the sharp edges are. The strain is rarely in Selenium itself. It shows up everywhere around it: keeping the framework alive as the application changes, running the suite fast enough to fit inside a release window, and proving to anyone who asks what the suite actually covers.
That is a different problem from "we picked the wrong tool," and it needs a different answer than a rewrite. Bringing a Selenium project into Katalon Studio does not mean throwing away the code. You copy the project in, resolve a small number of dependencies, and run it. What you add on top is execution capacity, AI-assisted authoring for the people who cannot write Java, and a governed record of what ran and what was approved.
THE SHORT ANSWER
What a Selenium migration to Katalon actually involves:
• Copy Java source and project resources into Katalon's Include folder while preserving their structure.
• Validate and build the project's dependencies. Katalon Studio bundles Selenium, TestNG, and JUnit dependencies; other project dependencies must be added and tested.
• Use the documented Selenium/TestNG/JUnit migration flow, or Katalon's separate BDD/ Cucumber integration where applicable. Git can remain the source of truth.
• Keep existing driver setup initially, then evaluate optional Katalon-managed driver configuration after parity is established.
• Evaluate execution, reporting, and AI-assisted authoring capabilities against your team's requirements and plan.
There is no conversion tool that rewrites Selenium into Katalon syntax, and that is deliberate. The recommendation is to keep the framework as it is and author new work with AI assistance from there.
As suites and teams grow, maintenance, execution, and visibility can become material constraints.
Locators drift as applications change, and teams must diagnose and update affected tests before a smoke or regression run can be trusted. The hidden costs of test maintenance can compound quietly, which is why the problem often becomes visible only when a framework refresh is being planned.
Selenium requires code, which can limit automation contributions to team members who can work comfortably in the framework. Domain specialists may know what should be tested but need a supported way to contribute without authoring Java directly.
Selenium results are not linked to a requirement or a traceability matrix, so there is no straightforward way to answer which parts of the application are covered and which are not. Gaps get discovered in production rather than closed deliberately. Katalon's own State of Software Quality 2025 survey of more than 1,500 quality professionals found automated UI testing in use by just 31% of respondents, rising only to 47% among the highest-maturity organizations, while 82% still rely on manual testing.
Regression measured in hours does not fit a release cycle measured in hours. Under deadline pressure, teams can be forced to reduce or skip suite execution precisely when automation should provide confidence. The same report found 55% of teams naming insufficient time for testing as their biggest challenge, and 43% pointing at short release cycles.
Selenium has no smart locator strategy and no healing, so a slow environment is indistinguishable from a real defect: the test fails, and it gets marked flaky. Engineers then spend their time triaging failures that are not real defects, which is the least valuable work available to them. Worse, without consolidated reporting there is no way to ask the useful question, which is how many of the last ten runs passed and which tests are unreliable across all of them.
There is a newer pressure sitting on top of all five. Google Cloud's 2025 DORA report, based on responses from nearly 5,000 technology professionals, found that 90% now use AI at work and more than 80% believe it has increased their productivity. It also found a negative relationship between AI adoption and software delivery stability, and 30% reporting little or no trust in AI-generated code. Its central conclusion is worth sitting with: "AI doesn't fix a team; it amplifies what's already there."
Read against the five pains above, that is a warning. If AI is now writing more of the application, the constraint moves downstream to verification capacity, and a Selenium suite that already takes nine hours to run and weeks to repair is exactly the kind of control system that amplification will expose.
Most migration content quietly implies a rewrite, which is why most migration conversations stall. It is worth being precise about what changes and what does not.
Your code stays yours. Java and Groovy sources, page objects, step definitions, helpers, and custom libraries are carried over as they are, and they stay on your machine or your on-premises environment rather than moving to a cloud service.
Your suites still run. A Cucumber BDD project, a TestNG project, and a JUnit project all follow the same migration path. Git remains the source of truth, so your branching model, review process, and pipeline triggers do not need to be redesigned around a new tool.
Katalon takes the rest. Execution capacity, parallel scheduling, centralized reporting, and low-code and AI-assisted authoring for the part of the team that has been locked out.
Katalon Studio has a dedicated Include for imported code and resources. For the Selenium/TestNG/JUnit migration flow, copy Java source into Include/scripts/groovy and copy other resources into Include, then refresh the folder. Cucumber feature files and step definitions should instead follow the documented BDD project structure. If you are coming from Eclipse, VS Code, or IntelliJ, preserve the internal package structure as you copy the project assets.
Validate dependencies before the first run. Katalon Studio bundles Selenium, TestNG, and JUnit dependencies, but any other project dependency must be added to the project's Gradle configuration and built according to the migration guide. Resolve version conflicts through a controlled parity test rather than assuming a bundled version is interchangeable with a pinned dependency.
For TestNG and JUnit projects, create a Katalon test case that uses the documented TestNG/JUnit keywords to run the imported tests. For Cucumber projects, use Katalon's BDD integration to add feature files, define and link steps, and run the feature file. Validate the first imported suite without changing step definitions unless parity testing identifies a necessary change.
Execute the imported suite unchanged and compare results against your existing baseline. Then check the reports, because reporting is one of the things you are migrating for, and it is worth confirming it says what you need before you depend on it.
There is one optional code change worth making. In the hook or setup class where you create the driver instance, adding a couple of lines hands driver management to Katalon. You stop maintaining WebDriver versions and browser compatibility yourself, and you gain the ability to select a target browser at run time rather than having it hard-coded. Your existing driver setup will keep working if you leave it alone, so this is a recommendation rather than a requirement.
Migration duration depends on framework complexity, custom dependencies, environment configuration, and the depth of first-run validation. Start with one representative suite and use the parity result to estimate the remaining work.
The step-by-step mechanics, including project structure and a sample repository, live in the Selenium, TestNG, and JUnit migration guide in Katalon Docs, and there is a Katalon Academy course that walks through a full migration. If your suite leans heavily on external test data, our walkthrough of a data-driven testing framework with Selenium and Katalon covers how that part carries across.
Execution is where the nine-hours-to-two-hours gap gets closed, and the honest answer is that it depends on constraints you already have. Data residency rules, security review, and existing hardware investment all push in different directions, so there are three ways to run an imported suite.
| Execution path | Three ways to run an imported Selenium suite Pick by constraint, not by preference. Most teams end up using all three. |
|---|---|
| Locally in Katalon Studio | The day-to-day path while authoring and debugging. Pick a browser from the toolbar, including headless, and run the test case or suite on your own machine. This is what replaces hitting Run on a runner class in Eclipse. |
| Katalon Runtime Engine (KRE) | The set of binaries that lets Katalon scripts run anywhere outside Studio. Your pipeline does not need to know anything about Katalon: you generate the command from the test suite and run it from a terminal, a remote machine, or a CI job in Jenkins, GitLab CI, GitHub Actions, or Azure DevOps. Executes against your own physical or virtual machines, which matters when data residency or security review rules out the cloud. |
| Katalon TestCloud | Cloud-native scaling with no infrastructure to install, patch, or maintain. Windows, macOS, and Linux, with a browser matrix that includes beta and dev channel versions as well as older releases, plus real mobile devices. Switching a run from local to cloud is a matter of enabling cloud device integration in project settings and choosing an operating system and browser version. |
Two suite-level settings do most of the work of closing the execution gap. Parallel execution is configured on the test suite itself, is off by default, and takes an instance count: set it to the number of tests you want running at once and total wall-clock time drops accordingly.
Retry behavior is configured in the same place, defaulting to three attempts, and can be set to zero, raised, or scoped so that a rerun covers only the failed tests rather than the whole suite. The mechanics of parallel testing are the same on any of the three paths: the constraint is capacity, not the tool.
Reporting has three tiers, and it is worth knowing where the line sits. Every run writes an HTML report into the project's Reports folder, and PDF output can be switched on in project settings. Both are included with Studio and stay on your machine.
Centralized reporting, where every run from every machine uploads to one place that anyone on the project can open, requires a platform license. That tier is where the useful views live: pass and fail summaries across runs, flakiness and always-failing tests called out, attachments, AI analysis sessions, step-level detail, and the ability to raise a defect straight into Jira or Azure DevOps from the failed test rather than copying details by hand.
Two things help with a Selenium codebase, and they help with different problems.
Katalon AI Assistant works inside Studio with access to your project. In the session demo, one prompt analyzed a Jira requirement, generated a test case and its object repository, ran it, hit a failure, found the root cause, applied a fix, and re-ran until it passed.
The useful detail is the review loop: teams should validate generated artifacts, execution results, and any proposed changes before accepting them into a shared suite. Confirm licensing, availability, data handling, and retention terms for the version and deployment model you use with current Katalon documentation and your agreement.
Supported model providers and version prerequisites can change. Confirm the currently supported configuration in the Katalon AI Assistant documentation before planning an implementation.
GitHub Copilot carries different context: your repositories rather than Katalon itself, so it fills gaps from surrounding code when a requirement is thin. That difference shows up in the output.
Asked to automate the same scenario, the assistant produced roughly 40 to 45 lines that create objects in the Object Repository and reference them, while Copilot inlined the locators alongside the test steps and produced noticeably more code.
One can be easier to maintain across many tests, while the other can be faster to read in isolation. Integrations with work-management systems and MCP-enabled tools depend on the configured and authorized tools in your environment; verify those capabilities before making them part of a delivery workflow.
Self-healing works differently: it can use alternative locators to help a test continue when a locator changes, and the resulting healing information should be reviewed as part of test maintenance. Our guide to self-healing test automation covers the trade-offs.
What none of this does is record what was generated, who approved it, or what changed between two runs. Authoring assistance and governance are separate jobs, and once AI is writing tests the volume of change goes up while the evidence trail does not follow on its own. That is what the next section is about.
A migrated estate is a hybrid estate. Some of it is imported Selenium code that has been running for years. Some is newly authored in Studio by people who could not contribute before. Some is AI-generated. Once that is true, the useful question stops being "does it run" and becomes "can we show what was tested and what was approved."
Some of that governance is already visible in the authoring loop, and it is worth noticing because it is easy to miss as friction. The assistant asks permission before each action, and you choose whether to allow it once or always. Self-healing proposes a locator change rather than applying it silently. A generated test lands in your project as a reviewable artifact, not as a background mutation. In other words, AI proposes and a person approves, at every point where something would otherwise change without anyone knowing.
Katalon True Platform is what turns those individual checkpoints into a record. It is the governed system of record connecting requirements, test cases, execution, evidence, defects, approvals, and releases across manual, automated, and AI-generated testing. For the test management specifics, the module doing that work is TestOps.
The value of governance grows with the size, change rate, and regulatory obligations of a testing program. A small team may prioritize execution and authoring first, while regulated teams often need evidence of what was verified and who approved it.
Migrations go badly when everything moves at once: a parity problem in week one is unattributable by week four. Move in steps that are each independently reversible.
Start with one representative suite, small enough to diagnose but complex enough to be real. Run it unchanged and compare against your baseline until you can explain every difference. People rush this, and it is the only step that proves the rest of the plan is sound.
Move execution next: running that suite in parallel through KRE or TestCloud asks nobody to change how they write tests, and getting regression inside the release window buys room for everything after. Then open AI-assisted and low-code authoring to the testers who have been locked out.
This lifts the ceiling on coverage: people who know the application but could not write a line now describe a requirement and get a working script back. Governance comes last, because approval workflows matter only once there is real hybrid activity to govern.
Meanwhile, do not write new work in Selenium. There is no conversion tool, and building one is not worth it: effort scales with framework complexity and buys nothing that running your code as-is does not. Keep the existing suite running, author new tests with AI or the recorder, and combine both into the same suites. The balance shifts on its own, with no migration project that has to finish.
Use the migration path above as a starting point, then validate it against your own suite and operating constraints. Two boundaries worth stating plainly while you scope your own: Katalon covers functional testing across web, API, mobile, and desktop, and it is not a performance testing tool, so load and stress work stays wherever it lives today. And if your environment also includes Playwright, our guide to Playwright test management in Katalon covers how those suites can sit in the same managed space.
We ran this material as a live, demo-led session in two regions (AMER/EU and APMEA), and both recordings are available on demand. They are worth an hour if you are scoping a migration, because the migration, the three execution paths, and the AI authoring loop are all demonstrated end to end on a real Cucumber project rather than described:
Then do the thing the recording cannot do for you. Download Katalon Studio, copy in one suite you are genuinely worried about, and see what the first run tells you. For a straightforward BDD project that is an afternoon at most, the dependencies are mostly already there, and you will know more from one imported suite than from any amount of evaluation.
The case for modernizing a Selenium suite is not that Selenium is bad at what it does. It is that the work around Selenium, maintaining the framework, finding execution capacity, and proving coverage, has grown into a bigger job than writing the tests ever was. Migration in this sense is additive: the code stays, the suites keep running, and what changes is how much of the team can contribute and how quickly results come back.
If you have a suite you are genuinely worried about, that is the one worth starting with. Bring it and find out what importing it actually involves, rather than estimating from the outside.