Your functional tests run in Postman on every pull request. Your load tests live in a .jmx file that one person understands and nobody wants to open. Tool sprawl is real, and we get it – which is why we built Performance testing in Postman.
Install the Postman plugin for your coding agent, point it at your .jmx file, and ask it to import the plan. You get a Postman Collection, a ready-to-run postman performance run command, and a report of what imported exactly, what was approximated, and what needs manual work. Then smoke test one iteration, run the load test, and compare p95 and error rate with your last JMeter run.
Quick start. Install the plugin into every coding agent on your machine (needs Node.js 22 or later):
npx @postman/postman-plugin
Restart your agent, open it in the folder with your .jmx file, and paste:
Import the .jmx file in this folder into Postman and give me the performance run command.
No Node.js? In the Postman desktop app, click Help > Postman CLI and Plugins > Install Postman Coding Agent Plugin. For other options, see Install the Postman plugin.
What does a typical JMeter plan look like before migration? #
Say you own checkout-load.jmx. It signs in with HTTP Basic, pulls a token out of the login response with a Regex Extractor, and sends that token as a Bearer header on every call after. A Duration Assertion fails any sample slower than your SLO. There’s a CSV Data Set with test accounts, a Groovy JSR223 post-processor doing some custom signing, and a Constant Timer between steps. The suite runs on a dedicated box after every nightly build.
Your functional tests already live in a Postman workspace. Your QA lead wants one thing: stop maintaining two tools, two report formats and two sets of credentials. Put the load tests next to the functional tests and run both from CI. This post shows how to move that plan into Postman without rebuilding it by hand.
What are your options for moving off JMeter? #
There are four reasonable paths. Each one fits some teams better than others.
| Option | What you get | Trade-off |
|---|---|---|
| Keep JMeter | Mature, covers almost every protocol | Separate suite from your functional tests, XML diffs in reviews, own infra to maintain |
Run .jmx onBlazeMeter orTaurus |
No rewrite, hosted execution | Still JMeter’s model, still separate from your functional tests and reporting |
| Rewrite in k6 orGatling by hand | Code-first, versionable | Weeks of rewrite, community .jmx converters are dated and partial |
| Import into Postman with your coding agent | Reuse requests, auth, extractors, and assertions; load tests live next to functional tests; cloud load without load machines to maintain | Approximates load shapes; a handful of items need manual work |
None of these is wrong. The right call depends on how much of your test estate is HTTP and how badly you want one place for functional and load.
How do you migrate JMeter tests to Postman? #
Install the Postman plugin for your agent:
npx @postman/postman-plugin
This installs the plugin into every supported agent it finds on your machine, including Claude Code, Cursor, Codex and GitHub Copilot CLI. It needs Node.js 22 or later. To install into one agent only, run npx @postman/postman-plugin install --agent cursor. There’s no separate importer binary and nothing to wire up by hand after that.
Open the agent in the directory with your .jmx file and send this prompt verbatim:
Import checkout-load.jmx into Postman and give me the performance run command.
The agent reads the .jmx and follows the plugin’s JMeter mapping rules. You’ll get back three things:
- A Postman Collection in v2.1 format.
- A ready-to-run
postman performance runcommand. - An import report with four sections: Imported exactly, Approximated, Needs manual work, and Not supported.
What imports exactly?
For a checkout plan like yours, these come across as-is: HTTP Request samplers, Header Manager, HTTP Request Defaults, Basic and Digest auth, Transaction and Simple controllers (they become folders), Regex and Boundary extractors, simple JSON extractors, Response Assertions, your Duration Assertion (as a pm.test plus a --pass-if p95 hint), User Defined Variables (${var} becomes {{var}}), __UUID, __time, and JMeter’s implicit 200 to 399 success check.
So your login call keeps its Basic auth. The Regex Extractor that grabs the token becomes a script that saves it to a variable, and later requests send it as the Bearer token. The Duration Assertion survives as both a per-request check and a run-wide pass criterion.
What gets approximated?
Thread groups turn into virtual users. The run duration and one of four load profiles (fixed, ramp-up, spike, peak) replace JMeter’s ramp-up and scheduler settings. Loop counts become duration. If and While controllers get translated with the closest matching logic. Size and JSON assertions, CSV Data Set (one file), and __Random all come across but may need a second look.
Smoke test, then run the load test
Before you kick off a load test, do a one-iteration pass:
postman collection run <collection-id>
Fix anything that fails there. Push the collection to a workspace. Then run the load test:
postman performance run <collection-id> --peak-vu 50 --duration 10 --load-profile ramp-up --pass-if "less_than(p95, 500)"
Where should the load come from? #
The JMeter plan ran on a dedicated box. You don’t need to rebuild that box. Add --runner postman-cloud to the same command, and the load comes from Postman’s managed cloud infrastructure. The collection, the test configuration and how results are reported all stay the same.
postman performance run <collection-id> --runner postman-cloud --peak-vu 50 --duration 10 --load-profile ramp-up --pass-if "less_than(p95, 500)"
That gets you three things the JMeter box couldn’t:
- More load than one machine. A cloud run generates load beyond what your laptop or CI runner can produce, without moving the test out of your pipeline. The command waits for the run to finish and returns the
--pass-ifresult as its exit code, so set your CI job’s timeout to at least the test duration. - Load your firewall can trust. If staging only admits known addresses, use
--runner postman-cloud-static-ip. The load comes from a fixed set of IPs in your account’s region (US by default, or EU for EU Data Residency plans), so your security team allowlists them once. The current addresses are in thedocs . - Results the whole team sees. Each run is recorded in Postman, so anyone in the workspace can open the results and compare runs.
Two things change for a cloud run. Your CSV moves to a dataset, because --data-file can’t be used with cloud runs. Secrets move to a Shared Vault secret, because Local Vault secrets aren’t available in the cloud.
How do you tell the import worked? #
Don’t trust the import because it was quiet. Measure it.
Read the import report end to end. Anything under Approximated is a thing to verify, not a thing to ignore. Run the collection once with postman collection run and confirm every request is green with real credentials against your test environment.
Then compare apples to apples. Run the Postman performance test with the same virtual user count your JMeter plan used last. Pull your last clean JMeter result and compare p95 and error rate. Expect throughput to run higher than in JMeter, because timers don’t carry over. If p95 and error rate land in the same neighborhood, the correlations and auth are working. If p95 is way off, check whether your old plan had think time doing more work than you remembered.
What doesn’t carry over from JMeter? #
Be honest with your team about what doesn’t cross:
- Timers and think time aren’t supported.
- Concurrent thread groups aren’t supported; one collection per run.
- Non-HTTP samplers (JDBC, FTP, LDAP, TCP, Java) aren’t supported.
- Kerberos and NTLM auth aren’t supported.
- Groovy and BeanShell scripts, XPath and CSS extractors, and complex JSONPath need manual work.
--data-filecan’t be used with cloud runs. Use a dataset instead.
For the checkout plan, the Groovy JSR223 post-processor and the Constant Timer are the two items you’ll have to decide about. You can rewrite the signing logic as a Postman pre-request script in JavaScript. For the Constant Timer, drop it and let the load profile do the shaping.
Frequently asked questions #
Do I have to delete my JMeter test plans?
No. The import reads the .jmx and produces a collection. Your original file stays where it is. Teams usually keep both for a release or two, run them side by side, and retire the JMeter suite once p95 and error rates line up. If you later need a protocol Postman doesn’t cover, your JMeter plan is still there.
What happens to JMeter timers and think time?
Timers aren’t supported, so a Constant Timer or Gaussian Random Timer won’t carry over. In practice, the load profile (ramp-up, spike, peak, fixed) does the shaping work most teams used timers for. Expect higher throughput than your JMeter runs, and compare p95 and error rate at the same virtual user count rather than requests per second.
Can I run the migrated load test in CI?
Yes. The Postman CLI runs both postman collection run for functional checks and postman performance run for load. Drop both commands into a GitHub Actions step, a Jenkins stage, or a GitLab job. Fail the build on --pass-if thresholds. Add --runner postman-cloud to generate the load from Postman’s cloud instead of the CI runner.
Which Postman plan do I need for performance tests?
Local runs are available on all plans. Cloud runs and static IPs are available on paid plans. Cloud runs require a minimum of 10 virtual users. Check the test locally first, then add --runner postman-cloud when you need more load than one machine can produce, a fixed set of source IPs, or results the whole team can see.
Can I set the test duration in seconds or add several pass criteria?
--duration is in whole minutes, so --duration 10 is a 10-minute run. Fractional minutes aren’t accepted, so round up for short smoke runs. For pass criteria, --pass-if takes a metric and threshold such as "less_than(p95, 500)"; the valid metrics are avg, p90, p95, p99, error_rate, and rps.
Next step #
Walk through the full configuration reference at Performance test configuration and add the command to your CI job with --runner postman-cloud. For cloud-specific options, see run a performance test on Postman Cloud.
Resources #
- Install the Postman plugin : Install into Claude Code, Cursor, Codex and other coding agents with one command, from the desktop app, or through each agent’s own marketplace.
- Postman performance test configuration : The full reference for
postman performance run, load profiles, and pass criteria. - Postman CLI overview : Install steps and command reference for running collections and performance tests from CI.
- Writing test scripts in Postman : Reference for the
pm.*API you’ll use to replace Groovy post-processors. - Writing pre-request scripts in Postman : Reference for the pre-request hook where you’ll port signing logic out of JSR223.
- Apache JMeter user manual : The canonical source for sampler, controller, and assertion semantics when you need to verify an approximated item.