Postman migration
Migrate from Postman to spec-driven API testing
Import your Postman collections with their pm.test checks, captures and auth, then generate the rest of the suite from your OpenAPI spec with no AI key. Rebuild what pre-request scripts and environment files did, run Newman and Shift-Left API side by side in CI, and keep Postman for exploration.
What a Postman collection import carries over
Generating from the spec does not mean throwing the collection away. The import brings its hard-won checks across as tests.
Folders become features
Postman v2.0 and v2.1 collections are both handled. The top-level folder becomes the feature, and each test keeps its folder path (for example "Smoke / Orders") so you can trace it back to the collection.
Checks become assertions
pm.test, pm.expect, pm.response.to and chai expect checks, including collection- and folder-level scripts, are translated into point-and-click assertions. Computed checks are recompiled from a whitelisted grammar; anything left over is kept as a flagged check that fails until someone converts it.
Captures and auth carry over
pm.environment.set and similar captures of a response value become data extractions, so request-to-request hand-offs keep working. Nine Postman auth types, OAuth 2.0 with PKCE included, map into reusable auth profiles with collection, folder and request inheritance.
Bodies, base URL and GraphQL
Raw JSON, form-data, urlencoded and file bodies map to real fields (you attach each file once). The base URL comes from the collection's baseUrl variable or leading {{var}} host, and GraphQL-mode bodies become GraphQL endpoints.
An import summary, not a surprise
The summary lists tests created, assertions imported versus needing review, requests skipped, files to choose and auth profiles created, with one click to convert the flagged checks or to import bare requests as tests too.
Re-import without duplicates
Re-import a changed collection and unchanged items are skipped, changed ones updated and new ones created. Nothing is duplicated, so you can keep importing while Postman is still the team's working copy.
Details in the Postman collection import documentation.
Governance and AI policy, answered before the review
The reason most enterprise teams move automated testing off Postman is not the client; it is where data and AI run, and who can change what.
No AI key required
Test generation, gap filling and failure triage all work without an AI key. When you want AI, bring your own key from 19 provider families, or on Trial and Enterprise run a model you host (Ollama, LM Studio or vLLM).
Your infrastructure, if you need it
Self-host the platform on every plan, including the free edition, against your own MongoDB. Telemetry is opt-in and off by default; licence checks and updates contact Total Shift Left unless arranged otherwise.
Imported scripts never run as written
Collection scripts are not executed. Checks are rebuilt from a whitelisted grammar (no free globals, no unbounded loops) before they are stored.
Roles and an audit trail
Five built-in roles (Administrator, Contributor, Reviewer, Reader, Environment Manager) assigned per project, API keys capped by their creator's permissions, and an audit log with before/after values, IP and device.
Migrating from Postman
A seven-step plan, from collection audit to cut-over, that keeps Newman running until the new suite has proved itself.
- 1
Audit the collections
Export each collection as v2.0 or v2.1 JSON. Note which requests actually assert something, which rely on pre-request scripts, which environments and variables they use, and which endpoints of your API have no request at all. That gap is the baseline the migration has to beat.
- 2
Validate the OpenAPI spec
Generated tests are only as good as the spec. Lint it (Spectral or the Swagger Editor), check every endpoint and schema is defined, and compare it with live responses. No spec yet? The collection import still creates endpoints from your requests, so you can start there and grow the spec over time.
- 3
Import the collection and the spec
Open Import, choose Upload File (or Paste cURL or Text), keep test import on, and read the import summary. Then import the OpenAPI or Swagger spec into the same project so every endpoint is covered, not only the ones someone saved in Postman.
- 4
Convert, then rebuild what Postman scripts did
Convert the flagged checks from the summary. Rebuild logins that lived in pre-request scripts as an auth profile (multi-step sign-in included) or a workflow, recreate the variables your environment files held as environments, and attach the files for any file-upload requests.
- 5
Generate and compare coverage
Let the coverage engine plan the rest of the suite, then compare it with your audit. Business rules, calculated fields and multi-step journeys that only the collection knew about become custom assertions and workflows.
- 6
Run Newman and Shift-Left API side by side
Add the GitHub Actions, Jenkins or Azure DevOps integration (or call the REST API from any other CI) next to the Newman step. Start the pass-rate threshold below your target and raise it, and remove Newman only when both have run green for at least two sprints.
- 7
Keep Postman for exploration
The migration takes collections out of the pipeline, not out of the team. Postman stays useful for ad-hoc debugging and design conversations; the automated, governed suite lives in Shift-Left API.
What comes across
- +Postman v2.0 and v2.1 collections: folders, requests with checks, captures and auth
- +pm.test, pm.expect and chai checks as point-and-click assertions
- +Nine auth types mapped into reusable profiles, OAuth 2.0 with PKCE included
- +Form, urlencoded and file bodies (attach each file once) and GraphQL-mode bodies
- +OpenAPI 3.x and Swagger 2.0 specs, WSDL and GraphQL schemas
- +Single requests pasted as cURL commands
What you rebuild
- -Postman pre-request scripts: rebuild logins and computed headers as auth profiles, workflows or the test's own script
- -Postman environment and globals files: recreate the variables as environments
- -Akamai EdgeGrid, ASAP and AWS SigV4 auth settings from Postman: set those profiles up by hand
- -Checks the importer flags for review: convert them in one click or rewrite them
- -Postman monitors and Flows: use schedules, test packs and workflows instead
Postman + Newman vs Shift-Left API, after the migration
| Feature | Shift-Left API | Postman + Newman |
|---|---|---|
| Where tests come from | Imported from your collection, then generated from your OpenAPI spec (79 scenario classes across 12 dimensions, no AI key) | Requests and JavaScript scripts written by hand; Agent Mode writes and updates tests on request |
| Coverage | Status codes, parameters and request-body fields per endpoint, plus auth, routing, schema and error-body checks | None built-in |
| Running in CI | GitHub Actions, Jenkins and Azure DevOps integrations + REST API; pass-rate threshold plus fail-on-error, fail or warn | Newman CLI (requires Node.js); pass/fail on test results |
| When a run fails | Failures grouped by cause with a verdict; AI proposes grounded fixes you review and never loosens a test | Agent Mode debugs individual failures on request |
| Deployment and AI | Hosted or self-hosted on every plan; AI optional, your key or (Trial and Enterprise) your own model | Cloud workspace; AI features run on Postman-hosted models. No self-hosted deployment. |
| Protocols in one suite | REST, SOAP (WSDL), GraphQL on every plan; JSON-RPC / MCP and WebSocket-RPC on Trial and Enterprise; SSE events | REST / GraphQL / gRPC / WebSocket / MQTT / SOAP requests |
Still choosing a tool? Read our roundup of the best Postman alternatives for API testing.
Postman migration FAQ
Can I import my Postman collections?
Yes. Postman v2.0 and v2.1 collections import into the project you choose: top-level folders become features, each request with checks becomes a test (bare requests too, with one switch), pm.test checks become assertions, response captures become extractions, and collection and folder auth maps into reusable profiles. On the free edition the import counts toward its 50-endpoint limit.What does not import from Postman?
Pre-request scripts and Postman environment or globals files. Logins and computed headers built in pre-request scripts are rebuilt with an auth profile, a workflow or the test's own pre-request script; environment variables are recreated as environments. Akamai EdgeGrid, ASAP and AWS SigV4 auth are not mapped from Postman (SigV4 itself is a supported auth method), and file parts arrive named but empty, ready for you to attach the file.Do I need to rewrite my Postman test scripts?
Mostly not. Common checks are translated into assertions, computed checks are recompiled, and whatever the importer cannot convert is kept as a flagged check that fails until it is converted, with a one-click conversion attempt. What you add by hand is usually business-rule checks and the flows that pre-request scripts handled.How does this help us pass AI policy and security review?
Suites are generated with no AI key, so nothing has to go to a model provider. If you want AI, you choose the provider with your own key, or on Trial and Enterprise you run a model you host. The platform can be self-hosted on every plan, imported script code is never executed as written, and changes are covered by role-based access and an audit log.Can we run Postman and Shift-Left API in parallel during migration?
Yes, and we recommend it. Keep the Newman step in the pipeline next to the Shift-Left API step, compare results for at least two sprints, and remove Newman only when the new suite catches everything the collection caught. Re-importing a changed collection never creates duplicates.What if our OpenAPI spec is incomplete or missing?
Start with the collection: the import creates endpoints from your requests. Then lint and complete the spec service by service, starting with the busiest endpoints. Each endpoint you add to the spec gives the coverage engine more to plan from.Should we delete our Postman collections afterwards?
No. Keep them for exploration and debugging. The migration moves automated testing into a governed, generated suite; it does not take Postman away from the developers who like it.
Bring one collection and its spec
Start a 15-day Enterprise trial and import them yourself, or book a migration call and we will walk the import summary with you.