How to migrate JMeter tests to Postman

Postman released a coding-agent plugin that imports existing Apache JMeter .jmx load-test plans into Postman Collections and generates a ready-to-run `postman performance run` command, installed via `npx @postman/postman-plugin` on Node.js 22 or later. The plugin supports Claude Code, Cursor, Codex and GitHub Copilot CLI, and reports which elements imported exactly, which were approximated and which need manual work; Postman notes the import approximates load shapes and leaves a handful of items requiring manual fixes. The migration lets teams run load tests alongside functional tests in one workspace and from CI, replacing separate JMeter infrastructure and report formats.

How to migrate JMeter tests to Postman 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 https://learning.postman.com/docs/postman-plugin/install/overview/ 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 https://learning.postman.com/docs/postman-plugin/install/overview/ . 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 on BlazeMeter https://www.blazemeter.com/ or Taurus https://gettaurus.org/ | No rewrite, hosted execution | Still JMeter’s model, still separate from your functional tests and reporting | | Rewrite in k6 https://k6.io/docs/ or Gatling https://docs.gatling.io/ 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 https://learning.postman.com/docs/postman-plugin/install/detected-agents/ 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: 1. A Postman Collection https://learning.postman.com/docs/collections/collections-overview/ in v2.1 format. 2. A ready-to-run postman performance run command. 3. 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-if result 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 the docs https://learning.postman.com/docs/tests-and-scripts/performance-testing/performance-test-configuration/ run-a-cloud-performance-test-from-static-ips . - 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 https://learning.postman.com/docs/tests-and-scripts/performance-testing/test-data/performance-test-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-file can’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 https://learning.postman.com/docs/tests-and-scripts/write-scripts/pre-request-scripts/ 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 https://learning.postman.com/docs/postman-cli/postman-cli-overview/ 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 https://learning.postman.com/docs/tests-and-scripts/performance-testing/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 https://learning.postman.com/docs/postman-cli/postman-cli-run-performance-test/ run-a-performance-test-on-postman-cloud . Resources - Install the Postman plugin https://learning.postman.com/docs/postman-plugin/install/overview/ : 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 https://learning.postman.com/docs/tests-and-scripts/performance-testing/performance-test-configuration/ : The full reference for postman performance run , load profiles, and pass criteria. - Postman CLI overview https://learning.postman.com/docs/postman-cli/postman-cli-overview/ : Install steps and command reference for running collections and performance tests from CI. - Writing test scripts in Postman https://learning.postman.com/docs/tests-and-scripts/write-scripts/test-scripts/ : Reference for the pm. API you’ll use to replace Groovy post-processors. - Writing pre-request scripts in Postman https://learning.postman.com/docs/tests-and-scripts/write-scripts/pre-request-scripts/ : Reference for the pre-request hook where you’ll port signing logic out of JSR223. - Apache JMeter user manual https://jmeter.apache.org/usermanual/index.html : The canonical source for sampler, controller, and assertion semantics when you need to verify an approximated item.