How to Migrate from ReadyAPI to Apidog

TL;DR

Migrating from ReadyAPI to Apidog is straightforward for REST-heavy test suites. Export your ReadyAPI project, convert what you can via OpenAPI import, and manually recreate Groovy scripts in JavaScript. SOAP test cases require the most manual work. Plan for a phased migration to keep testing coverage continuous.

Introduction

Migrating API testing infrastructure is one of those tasks that sounds straightforward until you start. ReadyAPI projects can contain years of accumulated test cases, custom Groovy scripts, data files, environments, and complex test suite structures. Getting all of that into Apidog requires understanding what transfers automatically, what needs manual conversion, and what you may decide to leave behind.

This guide walks through the migration process step by step. It covers exporting your ReadyAPI project, analyzing what you have, importing into Apidog, handling the Groovy-to-JavaScript conversion, setting up CI/CD, and managing the transition period when both tools run in parallel.

Step 1: Audit your ReadyAPI project before you start

Before exporting anything, spend time understanding what is in your current ReadyAPI project. This audit shapes how long the migration takes and where you focus effort.

Open your ReadyAPI project and answer these questions:

How many test suites, test cases, and test steps do you have? Open the Navigator panel and count. A project with 50 test cases migrates in hours. A project with 500 takes days.

What percentage are REST vs SOAP test cases? REST test cases migrate much more cleanly. SOAP test cases require more manual work, especially if they use WS-Security policies or complex assertions.

How much Groovy scripting is in your test cases? Click through your test cases and look for Script steps. Count how many test cases have custom Groovy logic. Each Groovy script requires manual conversion to JavaScript.

Are you using data-driven tests with DataSource steps? Apidog supports data-driven testing with CSV and JSON data files, but the setup is different from ReadyAPI’s DataSource/DataSink pattern.

Do you use Properties or Property Transfer steps heavily? These patterns work differently in Apidog. You will use variables and environment variables instead.

Are you running load tests through LoadUI Pro? LoadUI Pro integration does not carry over to Apidog. You will need to set up k6 or another load testing tool separately for those scenarios.

Document your findings. A spreadsheet with test case name, type (REST/SOAP), has-Groovy (yes/no), and complexity (simple/medium/complex) gives you a migration estimate before you start.

Step 2: Export your ReadyAPI project

ReadyAPI stores projects as XML files. To export a project for analysis:

1. Open ReadyAPI and open your project.
2. Go to File > Save As to save the project as a standalone XML file.
3. Save any external data files (CSV, Excel, XML test data) that your tests reference.
4. Note any environment configurations you have set up under the Environments section.

The project XML contains all test suites, test cases, test steps, scripts, and configuration. It is a complete representation of your test project.

Step 3: Extract your API definitions

The cleanest migration path for REST APIs goes through an OpenAPI specification, not directly from the ReadyAPI project XML.

Option A: Export from ReadyAPI. If you have a REST service in ReadyAPI, right-click on it in the Navigator and look for an export or generate API definition option. ReadyAPI can export Swagger/OpenAPI specs from service definitions.

Option B: Use your backend’s OpenAPI spec. If your backend service already exposes an OpenAPI spec (at /openapi.json or similar), download it directly. This gives you the most accurate and current definition.

Option C: Extract manually. For APIs without an existing spec, use your ReadyAPI REST requests as the source. Note the endpoints, request bodies, headers, and response structures. You will recreate these in Apidog.

Step 4: Import into Apidog

With your OpenAPI spec ready, import it into Apidog.

1. Open Apidog and create a new project.
2. Go to APIs > Import and select your format (OpenAPI 3.0, Swagger 2.0, etc.).
3. Upload the spec file or paste the URL.
4. Apidog parses the spec and creates API definitions for all endpoints.

After import, you have a structured API definition with all endpoints, parameters, request bodies, and response schemas populated. This is the foundation for your test cases.

If you have existing Postman collections (perhaps migrated from a previous tool), Apidog imports those as well via File > Import > Postman.

Step 5: Recreate test cases for REST endpoints

For REST test cases, the migration process is:

1. Open a ReadyAPI REST test case.
2. Identify the requests, assertions, and any data sources it uses.
3. Create a corresponding test case in Apidog by selecting the API endpoint and adding test steps.

Assertions translate as follows:

• Contains assertion (body contains string) becomes a JavaScript assertion: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
• Status code assertion: pm.test('status 200', () => { pm.response.to.have.status(200); });
• JSONPath assertions: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

For straightforward GET and POST tests without Groovy, this migration is fast. A simple test case with 5 to 10 assertions can be recreated in 15 to 30 minutes.

Step 6: Convert Groovy scripts to JavaScript

This is the most labor-intensive part of the migration for projects with significant custom scripting.

Common Groovy patterns and their JavaScript equivalents:

Reading a response value:

// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

Setting a variable:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

Conditional assertions:

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

Date manipulation:

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

For complex Groovy scripts with Java library imports or intricate logic, the conversion requires careful analysis. Read each script, understand what it is doing, and write equivalent JavaScript. Do not attempt automated translation — the semantics are close enough to fool you but different enough to cause silent bugs.

Step 7: Handle SOAP test cases

SOAP test cases are the most challenging part of any ReadyAPI migration. Apidog does not have dedicated SOAP tooling, so these require a different approach.

For SOAP services that also expose a REST interface (which is increasingly common), migrate the tests to use the REST endpoints and drop the SOAP layer.

For SOAP services with no REST alternative, you have two options:

Keep ReadyAPI for SOAP only. Run ReadyAPI in parallel for SOAP test cases and use Apidog for REST. This is a practical middle ground that keeps SOAP coverage without blocking the REST migration.

Use SoapUI Open Source. SoapUI Open Source is free and handles SOAP testing. It cannot replace all of ReadyAPI’s features, but it covers basic SOAP functional testing without a license cost.

Do not rush the SOAP migration. WS-Security test cases in particular carry significant risk if their assertions are not carefully reproduced.

Step 8: Set up environments and variables

ReadyAPI’s Environment feature maps to Apidog’s Environment system. For each ReadyAPI environment you have configured:

1. Create a matching environment in Apidog (Settings > Environments).
2. Add the same variables: base URLs, authentication tokens, shared headers, etc.
3. Verify that test cases reference variables with the correct Apidog syntax: {{variableName}} in URL fields and request bodies.

Step 9: Configure CI/CD

ReadyAPI’s CI setup typically involves the testrunner command on build agents. Apidog uses a different approach.

Install the Apidog CLI on your CI agent:

npm install -g apidog-cli

Run a test collection:

apidog run "path/to/collection.json" -e "environment-id"

For GitHub Actions, a workflow step might look like:

- name: Run API tests
  run: apidog run collection.json --environment staging

For Jenkins, add a shell step to your pipeline that calls the Apidog CLI. No ReadyAPI installation required on the build agent.

Update your CI configuration files to use the new command. Remove ReadyAPI testrunner references once the Apidog runs validate correctly.

Step 10: Run both tools in parallel during transition

Do not cut over from ReadyAPI to Apidog in a single day. Run both tools in parallel through at least one release cycle.

During the parallel period:

• Run ReadyAPI tests in CI as the authoritative test gate.
• Run Apidog tests alongside and compare results.
• Investigate any failures in Apidog that do not appear in ReadyAPI.
• Gradually add new test cases only in Apidog.

Once you have confidence that Apidog catches the same failures ReadyAPI does, remove ReadyAPI from the CI pipeline. Keep the ReadyAPI installation available for a few months as a fallback.

FAQ

How long does a ReadyAPI to Apidog migration typically take?A REST-only project with minimal Groovy scripting can migrate in one to three days. A large project with extensive Groovy scripts, SOAP test cases, and complex test structures can take two to six weeks. The audit in Step 1 gives you the clearest estimate before you commit.

Will my ReadyAPI test data files work in Apidog?CSV data files work with Apidog’s data-driven testing feature. The import format is similar. Excel files require conversion to CSV first. XML data files need to be restructured depending on how they were used in ReadyAPI.

Can I run ReadyAPI and Apidog in the same CI pipeline during migration?Yes, and this is the recommended approach. Add the Apidog CLI step to your existing pipeline alongside the ReadyAPI testrunner step. Compare results run-by-run during the transition period.

Do I need to recreate environments manually or is there an automated way?Environment configuration must be recreated manually in Apidog. There is no automated import of ReadyAPI environment settings. Keep your ReadyAPI environments open in one window while recreating them in Apidog.

What happens to ReadyAPI tests that have no REST equivalent?For SOAP-only test cases with no REST alternative, the practical options are maintaining ReadyAPI (possibly on fewer licenses) for those specific tests, migrating to SoapUI Open Source, or accepting a testing gap if the services are legacy and low-risk.

Does Apidog support the same assertion types as ReadyAPI?Apidog supports JavaScript assertions that can express the same logical conditions as ReadyAPI’s built-in assertion types. The syntax is different but the capabilities are comparable for REST testing. Some ReadyAPI-specific assertion types (SOAP Fault, WS-Security) have no Apidog equivalent.

Migration from ReadyAPI to Apidog is a meaningful project, not a one-afternoon task. Teams that plan it carefully, start with a clear audit, migrate REST test cases first, and run both tools in parallel during the transition complete it without coverage gaps or testing regressions.