Migrate a Katalon Project Into Test Manager

How the Katalon Importer Works

The importer reads a Katalon Studio project zip, translates the operations it recognizes into KaneAI instructions, and writes the result into a new project as authored test cases rather than static records. Imported cases carry the New Experience label, so they are editable in the agent from the moment the import finishes.

• Authored, not archived - cases land as KaneAI New Experience tests you can open, edit, and run, not as a read-only copy of the original suite.
• Compatibility shown before import - the wizard lists which steps translate, which are excluded, and which the agent handles itself.
• Partial imports are a choice - cases with unsupported steps stay excluded unless you deliberately include the rest of the case.
• Masked values are restored on the way in - you supply each missing value and decide whether it is stored as a secret or a global variable.

This is the second source tool with a built-in importer in Test Manager, which is the planning and traceability layer of the platform rather than a standalone case repository. The first covered a different source tool and is documented in the walkthrough for the qTest to Test Manager migration.

Before You Start

Gather these before you open the importer, then check the one constraint that decides whether migration is the right route at all.

• An active account with Test Manager access - the importer lives inside Test Manager, under Projects.
• A Katalon Studio project packaged as one .zip file, up to 500 MB - containing desktop web test cases.
• Values for any masked variables - the export masks them, and the wizard will ask you to supply each one.

The constraint is scope: migration supports desktop web tests only. Mobile app tests are not imported, so a mixed project brings across its web suites and leaves the rest behind. Each import also creates a new Test Manager project, which means migration is a clean landing rather than a merge into an existing workspace.

Running the Migration

The flow is an upload followed by a four-screen review. Nothing is created until the final confirmation, so you can walk the whole wizard and back out.

• Go to Test Manager, open Projects, then open the dropdown beside Create Project and select Import Data. Choose Katalon from the Import from dropdown.
• Enter a project name, drag in the Katalon zip or browse for it, optionally add a description and tags, then click Analyze File. Test Manager reads the archive and reports the test suites and test cases it finds.
• Review the supported test cases. Browse the folder tree or search, click into a case to inspect its steps, translated instructions, and source file references, and check the Imports X of Y steps count on each one.
• Review the unsupported test cases, which are excluded by default. Filter by Step Error Type to see why, and use Import Anyway on any case whose remaining steps are still worth having.
• Supply the masked variable values, choosing Secret for sensitive entries and Global Variable for the rest.
• Check the preview counts, then click Create Project & Import. The number on the button is the number of cases selected.
• Track progress on the Projects page while the import runs in the background. An email arrives when it completes.

The Step Error Type filter is the fastest way to triage a large project. It groups incompatibilities into data files backed by a database, raw driver or code execution, schema validation steps, and unsupported Katalon keywords, so you can judge a whole category at once instead of opening cases one at a time.

Reviewing Steps Before You Commit

A supported case can still import fewer steps than it started with, and the reason is visible on each step. Reading these labels during review is what separates a migration you can trust from one you discover problems in later.

Conversion notes matter even on cases that appear in the supported list, because a translation can be close without being identical. The review flags these directly: sendKeys is approximated as typing, so append behaviour may differ, and checking a checkbox is approximated as clicking, so the original only-if-unchecked behaviour is lost.

Import Anyway deserves its own warning. It excludes the unsupported steps and imports the remainder, which means the resulting test may no longer cover what the original case was written to prove. Treat those cases as drafts to repair, not as coverage you already have.

Migration Scope

The boundary is worth reading before you plan the cutover, because the gaps are the work that remains after the import finishes.

The run-history line is the one teams most often plan around. The import brings over test cases, not executions, so historical pass and fail data stays in the source tool. If that record matters for an audit, keep the old project readable for as long as your retention policy requires.

After the Import

An imported suite is a starting position, not a finished migration. Four passes turn it into coverage you can rely on.

• Check the instructions against the originals - open a case in Test Summary and compare its authored instructions and variable references with the Katalon source.
• Repair the partial cases first - anything imported through Import Anyway is missing steps by design, so add or rewrite the missing behaviour before it counts as coverage.
• Run them in the agent playground - editing or running a test in KaneAI validates its behaviour and is also what produces the step screenshots the import does not include.
• Organize before you scale - group the imported cases into folders and cycles so the new project starts with the structure described in this guide to test management.

Imported cases behave like any other case in the workspace from that point on. They can be edited, versioned, grouped into plans and cycles, and linked to defects, the same way a case written from scratch is handled. If your repository arrived with duplicates from years of parallel authoring, the walkthrough on test deduplication in Test Manager covers the clean-up pass.

Conclusion

Start with one Katalon suite rather than the whole project. Zip it, run it through the wizard, and read the Imports X of Y counts and conversion notes on the supported list before you click through, because that review is where you learn how your particular style of Katalon authoring translates.

The full step reference, including every unsupported step category, is in the documentation on one-click migration from Katalon. For how cases are structured once they land, the test case guide covers the fundamentals.