The Official JMeter-to-k6 Converter Is Archived — What to Use Instead

People still find grafana/jmeter-to-k6. The repo shows up in search, in DeepWiki mirrors, and in old blog posts that treat it as the default path from a JMeter .jmx to a k6 script. The project is archived. It is no longer maintained. If you are planning a migration on the back of that tool alone, you need a different plan.

This is a practical look at what the converter was, why one-shot JMeter-to-k6 conversion is hard, and what to do instead — without pretending any converter finishes the job for you.

What the project was

Grafana’s jmeter-to-k6 was an open-source converter that took JMeter test plans and emitted k6 JavaScript. For a while it was the obvious answer when someone asked “how do I get our JMX into k6?” Teams installed it, ran it over a handful of scripts, and either celebrated or opened a GitHub issue.

The repository is now in an archived state: read-only, stated as no longer maintained. Community threads confirm the same. That does not make every past conversion worthless. It does mean you should not treat the tool as a supported dependency in a migration programme, a CI step, or a client delivery plan.

If you still have it pinned in an internal wiki, update the wiki. The risk is not only missing bug fixes. The risk is silently accepting mappings that never covered the JMeter features you actually use.

Why one-shot converters struggle

JMeter and k6 do not share a mental model. JMeter stores a tree of GUI elements as XML. k6 is JavaScript with explicit options, check(), and http calls. A converter has to invent a mapping between those worlds.

Some of that mapping is boring and reliable: method, URL, headers, body, basic status checks. Some of it is not. JMeter’s CookieManager, complex controllers, certain pre/post processors, and JSR223/BeanShell blocks do not have a one-line equivalent. Community discussion around the Grafana converter repeatedly hit the same class of problem — elements that either disappeared, became approximate, or required hand edits the tool could not describe clearly.

That pattern is not unique to one repo. Any JMeter-to-k6 converter that claims a clean one-shot pass is either scoping to simple HTTP threads or leaving the hard parts for you to discover at runtime. A conversion that “succeeds” and still drops correlation, cookie handling, or a critical extractor is worse than a failure: the script runs, the numbers look plausible, and you are not testing what you think you are testing.

The useful bar is not “fully automatic”. It is “mechanises the mechanical, and tells you what still needs a human”.

What to use instead

There is no single right answer. There are four honest options.

1. Rewrite by hand

For a small suite, or for scripts that are mostly custom logic anyway, a rewrite in k6 is often faster than debugging a bad conversion. You keep full control. You also pay the full cost: every extractor, every CSV feed, every think time, re-expressed in JavaScript.

Use this when the JMeter plans are outdated, poorly structured, or already due for a redesign. Migration is a bad moment to preserve accidental complexity.

2. Try the archived tool — knowing the risk

If you already know the converter and your plans are simple HTTP thread groups, you can still run the archived project locally and treat the output as a draft. Do not put it on the critical path. Do not assume CookieManager, controllers, or scriptable processors survived. Diff the request list against the original JMX and validate under a single VU before you talk about load.

Treat this as archaeology, not a platform choice.

3. Use a maintained converter that flags manual work

A maintained converter earns its keep when it:

• covers the HTTP shape of the plan;
• preserves or clearly approximates load profile intent;
• flags constructs it cannot map, instead of dropping them quietly.

That is the difference between a migration aid and a false start. Our free JMeter to k6 converter does exactly this kind of pass in your browser tab — nothing is uploaded — and Perf Script Studio covers the same job offline when you want a local binary rather than a tab. Either way, read the flagged list before you celebrate.

4. Pay for a finished migration

Sometimes the cheapest path is a fixed-price migration: reviewed k6 out from JMeter in, with the awkward JSR223 and correlation work done by someone who has already hit the silent failures. That is the rational choice when the suite is large, the deadline is real, or the JMeter plans encode business journeys you cannot afford to rediscover under load. I publish fixed-price migration tiers for this; use them when the converter output would cost more to finish than the review.

A legacy install note (historical only)

Older guides still show an npm-based install for the Grafana converter. If you encounter that in an internal runbook, treat it as legacy documentation for an archived project — not a recommendation:

# Legacy example only — grafana/jmeter-to-k6 is archived / unmaintained
npm install -g jmeter-to-k6
jmeter-to-k6 plan.jmx -o plan.js

Prefer a maintained path, or a deliberate rewrite, over copying that block into a new pipeline.

Practical checklist after any conversion

Run this whether the output came from an archived tool, a maintained converter, or a contractor.

1. Request inventory — Same hosts, paths, methods, and body shapes as the JMX? Spot-check POSTs with bodies; converters love to mangle multipart and raw body encodings.
2. Cookies and sessions — If the JMeter plan relied on a CookieManager, confirm the k6 script establishes and reuses cookies the way your app expects. A missing session is the classic “200s that mean nothing.”
3. Correlation — Tokens, CSRF values, IDs extracted in JMeter must still be extracted in k6. Search the JMX for extractors and post-processors; each one is a checklist item, not a nice-to-have.
4. Data feeds — CSV / user parameters need an explicit k6 equivalent (SharedArray or similar). One recorded user is not a load test.
5. Assertions — Status checks are not enough if the app returns 200 with an error payload. Port the response body checks that mattered in JMeter.
6. Load profile — Thread group ramp and duration should show up as stages (or your chosen k6 pattern). A flat spike is not “what we had in JMeter” unless that was intentional.
7. Custom code — JSR223, BeanShell, and fancy controllers: assume rewrite. If the converter did not flag them, flag them yourself.
8. Secrets — Migration is a good moment to remove hardcoded credentials and tokens from scripts. Do not paste a full JMX into a random online box; clean it first.
9. Single-VU proof — Run one virtual user against a safe environment and compare journey outcomes to the JMeter control run before you scale out.
10. Keep the JMX until CI agrees — Parallel runs for a sprint beat a big-bang cutover.

What “done” looks like

A converted script is done when it fails for the same reasons the original failed, passes for the same reasons the original passed, and exercises the same authentications and business paths under the load model you intended. File existence is not done. Green CI on a script that never correlated is not done.

k6 is a strong destination, but the destination does not remove the need to understand the source. The archived Grafana converter solved part of the syntax problem for simple plans. It did not solve correlation, custom logic, or ownership of the result.

If you are staring at a pile of JMX files and a wiki link to grafana/jmeter-to-k6, update the wiki, pick one of the four options above on purpose, and run the checklist. The migration will still take work. It will take less work than discovering a silent gap in production week.

Related reading

• Migrating performance test scripts between JMeter, k6, and Gatling
• Free JMeter to k6 converter — runs in your browser, nothing uploaded
• grafana/jmeter-to-k6 on GitHub (archived)