ReadyAPI & SoapUI migration
Migrate from ReadyAPI or SoapUI without losing your SOAP coverage
There is no converter for ReadyAPI or SoapUI project files. Migration is spec-first: import the WSDL and OpenAPI definitions your projects were built from, generate the suite with no Groovy and no AI key, rebuild the scripted scenarios as workflows, and run both tools in CI until the results agree, ideally before your renewal date.
Why teams migrate at ReadyAPI or SoapUI renewal
ReadyAPI is a mature suite and SoapUI Open Source is free. Teams move when the cost of keeping them is the scripts, the desktop installs and the licence quotes, not the tool itself.
Groovy holds the logic
Anything beyond a basic request in ReadyAPI or SoapUI means Groovy scripts, and the people who wrote them are often not the people who maintain them now.
A desktop app per person
ReadyAPI is a Windows, macOS and Linux desktop application with TestEngine for headless runs; SoapUI Open Source projects are files that are shared by export and import.
Licences per module
ReadyAPI is sold as annual licences per module (API Test, Performance, Virtualization), and SmartBear publishes no list prices, so every renewal is a quote.
Load testing is another licence
ReadyAPI Performance is licensed separately; without it, ReadyAPI load tests are capped at 10 virtual users.
AI that your policy can review
ReadyAPI added AI test generation in May 2026, but SmartBear does not say where the model runs and documents no bring-your-own-model option. SoapUI Open Source has no AI features.
Renewal is the natural deadline
A migration that starts one release cycle before the renewal date can run in parallel, prove itself, and avoid paying for both tools for another year.
ReadyAPI vs Postman vs Shift-Left API
Most teams leaving ReadyAPI shortlist Postman because everyone already has it. The question is what you need the replacement to do: explore APIs, or run governed, generated suites in CI, SOAP included.
| Feature | Shift-Left API | ReadyAPI | Postman |
|---|---|---|---|
| Built for | Automated, governed API test suites generated from your spec | SOAP-heavy enterprise functional testing in a desktop suite | API exploration, design and collaboration in a cloud workspace |
| Test creation | A full suite planned from OpenAPI, WSDL or GraphQL with no AI key (79 scenario classes across 12 dimensions); AI adds to it | Manual test building with Groovy for advanced logic; AI test generation added in May 2026 | Manual request building + JavaScript scripts; Agent Mode writes and updates tests on request |
| Protocols | REST, SOAP/WSDL, GraphQL on all plans; JSON-RPC 2.0/MCP and WebSocket-RPC on Trial and Enterprise; SSE streams | REST, SOAP, GraphQL, JMS and more — strong enterprise coverage | REST / GraphQL / gRPC / WebSocket / MQTT / SOAP requests |
| Deployment | Web platform: hosted, or self-hosted on every plan including the free edition | Desktop application (Windows, macOS, Linux); TestEngine for headless runs | Cloud workspace; no self-hosted deployment |
| Where the AI runs | No AI key needed; bring your own key, or on Trial and Enterprise a model you host (Ollama, LM Studio, vLLM) | SmartBear does not say where its model runs; no bring-your-own-model option is documented | AI features run on Postman-hosted models |
| Coverage tracking | Endpoint, method, status code, parameter | Coverage against OpenAPI and WSDL definitions, switched on per test case, suite or project; not for GraphQL | None built-in |
| CI/CD | GitHub Actions, Jenkins and Azure DevOps integrations, plus a REST API | Functional TestRunner CLI, an Azure DevOps extension (Windows agents), TestEngine and a Maven plugin | Newman CLI (requires Node.js) |
| Load testing | Built from your functional tests, no scripts (paid add-on; in the trial) | ReadyAPI Performance, separately licensed; without it, capped at 10 virtual users | Performance testing in the Collection Runner |
| Run triage | Failures grouped by cause with a verdict; passing tests checked for missed regressions | Not documented — failures are investigated from the test log | Agent Mode debugs individual failures on request |
| Pricing | Free Citizen Developer Edition (single user) + 15-day Enterprise trial; transparent team plans | Annual licences per module; SmartBear publishes no list prices | Free 25 monitor runs/month |
Competitor details as reviewed on the ReadyAPI alternative and Postman alternative pages.
Migrating from ReadyAPI or SoapUI
A seven-step plan that keeps ReadyAPI running until the new suite has proved itself. Nothing here needs a project-file converter.
- 1
Inventory the projects against the renewal date
List every ReadyAPI or SoapUI project, the WSDL or OpenAPI definition behind each service, the Groovy scripts and script assertions, the DataSource loops and the auth each service needs. Start at least one release cycle before renewal.
- 2
Pick a pilot: one SOAP service and one REST service
Choose services whose definitions are current. A pilot on both protocols shows the team how WSDL operations and OpenAPI endpoints look side by side before you commit the whole estate.
- 3
Import the definitions, not the project files
Import each WSDL by URL (?wsdl) or file: every operation becomes an endpoint, SOAP 1.1 and 1.2 bindings are detected separately, and the WSDL is stored so runs never refetch it. Import OpenAPI 3.x, Swagger 2.0 or GraphQL schemas the same way.
- 4
Generate the suite and compare coverage
The coverage engine plans happy paths, negative and boundary cases and opt-in security probes from the definition, with no AI key. Compare service by service with what the ReadyAPI project covered and list the scenarios that exist only in Groovy.
- 5
Rebuild what Groovy did
Multi-step flows become workflows with data passed between steps; DataSource loops become data sets from CSV, Excel, JSON, YAML, XML or a read-only database (PostgreSQL, MySQL, SQL Server, Oracle, SQLite, MongoDB); scripted sign-ins become auth profiles such as NTLM, OAuth 1.0a, OAuth 2.0 or a client certificate. Most script assertions turn out to be a status check plus a field check.
- 6
Run both in CI for one release cycle
Add the GitHub Actions, Jenkins or Azure DevOps integration (or the REST API for any other CI) next to the existing TestRunner job. Gate on a pass-rate threshold plus fail-on-error, and compare results green-on-green.
- 7
Cut over at renewal, service by service
Switch the services that have run clean, keep the ones that rely on anything under "What you rebuild" in ReadyAPI until they are covered, and let the remaining licences lapse when nothing depends on them.
What comes across
- +WSDL 1.1 definitions by URL or file, with SOAP 1.1 and 1.2 bindings detected separately
- +OpenAPI 3.x and Swagger 2.0 (JSON or YAML), GraphQL SDL or introspection
- +Postman collections elsewhere in your estate, with their pm.test checks converted into assertions
- +Single requests pasted as cURL commands
- +Test data files in CSV, Excel, JSON, YAML or XML, and read-only database connections
- +HTTP-level auth: Basic, NTLM, OAuth 1.0a, OAuth 2.0 (five grant types), bearer tokens and client certificates
What you rebuild
- -ReadyAPI and SoapUI project files: there is no project importer
- -Groovy scripts and script assertions: rebuilt as assertions, workflows, data sets or custom JavaScript checks
- -Message-level SOAP security (UsernameToken, signatures, encryption), SOAP header elements and binary attachments: not supported today
- -Full XPath and XSD validation: assertions are XPath-style element checks and XML well-formedness only
- -JMS and other non-HTTP protocols: not supported
- -Virtual services: mocks are generated from your spec with conditions and latency, but they are not stateful
On SoapUI Open Source? The same plan applies
SoapUI Open Source is free, so the reason to move is rarely the licence. It is manual test creation, Groovy for anything advanced, and file-based projects shared by export and import. Import the same WSDL and OpenAPI definitions, generate the suite, and run it from GitHub Actions, Jenkins or Azure DevOps instead of a command-line runner. The SoapUI alternative page compares the two feature by feature.
ReadyAPI and SoapUI migration FAQ
Can Shift-Left API import ReadyAPI or SoapUI projects?
No. There is no importer for ReadyAPI or SoapUI project files, and we do not pretend otherwise. You import the WSDL and OpenAPI definitions the projects were built from, generate the suite from them, and rebuild the Groovy-scripted scenarios as workflows, data sets and assertions.ReadyAPI vs Postman: which should replace ReadyAPI?
It depends on what ReadyAPI does for you today. Postman is strongest at API exploration and collaboration in a cloud workspace, with JavaScript test scripts and no self-hosted deployment. If you are leaving ReadyAPI but still need SOAP/WSDL suites, generated coverage, CI gates and the option to self-host with your own AI model, Shift-Left API is the closer fit. Many teams keep Postman for exploration either way.Is there a SoapUI alternative that keeps WSDL support?
Yes. Shift-Left API imports WSDL 1.1 by URL or file, detects SOAP 1.1 and 1.2 bindings separately, builds envelopes with the right namespaces, and offers fault, envelope and XPath-style element assertions. SOAP services can sign in with Basic, NTLM, OAuth 1.0a, bearer tokens or a client certificate.What happens to our Groovy scripts?
They are not executed or converted. Catalogue them first, because they hold your institutional knowledge, then rebuild each one as what it really does: an assertion, a workflow step that passes data on, a data set, an auth profile or, when nothing else fits, a custom JavaScript check.Which SOAP features are not supported?
Message-level SOAP security (UsernameToken, signatures, encryption), SOAP header elements, binary attachments, full XPath (matching is by element name) and XSD validation (the XML schema assertion checks well-formedness only). Keep suites that depend on those in ReadyAPI until they are covered.How long does a ReadyAPI migration take?
Importing a definition and generating its suite is quick; most of the time goes into rebuilding scenarios that live in Groovy. Plan for a pilot on one SOAP and one REST service, then run both tools in CI for at least one release cycle before you switch.Can we keep specs, test data and AI inside our network?
Yes. Shift-Left API can be self-hosted on every plan, including the free edition, against your own MongoDB, and suites are generated without any AI key. On Trial and Enterprise, AI features can use a model you host (Ollama, LM Studio or vLLM). Licence checks and updates contact Total Shift Left unless arranged otherwise.
Bring one WSDL and one OpenAPI spec
Book a migration call and we will run your pilot services with you, or start a 15-day Enterprise trial and import them yourself.