JMeter to Gatling converter: stop rewriting, start converting

A lot of teams running JMeter today aren't unhappy with it. It works. It's been there for years. It's embedded in workflows, CI pipelines, and team habits.

But the context around it has changed.

Performance testing today looks different. Systems are API-first, distributed, and event-driven. Test logic needs to evolve alongside application code. Collaboration across teams matters more than ever.

And that's where many teams start looking at Gatling, not because JMeter is broken, but because Gatling aligns better with how modern engineering teams work:

• Tests as code, not UI-driven configuration
• Versionable, reviewable scenarios that live in the same repo as the application
• Tighter CI/CD integration without extra tooling
• More maintainable test suites over time

The intent to switch is often there. But it rarely happens.

Because the blocker isn't deciding whether to switch, it's what it actually takes to do it. because rewriting existing tests is a full-on project. JMeter's ThreadGroup doesn't map directly to a Gatling scenario. CSV handling, extractors, and injection profiles all behave differently. Even when concepts overlap, the implementation changes. Someone has to own it, and there's always something more urgent.

So the migration sits in the backlog. Not rejected, just never prioritized. But that’s about to change with the JMeter to Gatling converter.

Introducing the JMeter-to-Gatling converter

We've been working on a way to take that blocker off the table.

We built a Claude Code skill — gatling-convert-from-jmeter — that converts JMeter test plans to Gatling simulations. Not by guessing, not by generic LLM prompting, but through a structured workflow with explicit knowledge of how JMeter and Gatling concepts relate.

Here's what actually happens when you use it.

You open Claude Code in your project and ask it to convert your JMeter test — plain English is enough. Claude Code recognizes the intent and picks up the skill automatically.

From there:

1. It finds your JMX files: If there's only one, it proceeds. If there are several in the workspace, it asks which one to use.
2. It checks for an existing Gatling project: If one is there, it uses it. If not, it offers to bootstrap a new one — you specify the language (Java, Scala, or Kotlin) and build tool (Maven, Gradle, or sbt).
3. It reads the JMX and maps each construct: to its Gatling equivalent, writing the output to your project.
4. Resource files are carried over automatically: CSV data files referenced in your test plan get copied to the Gatling project's resources directory. You don't configure this — it just happens.
5. It runs a compile check: If the generated code has a syntax problem, it surfaces immediately. This turns out to be a feature: if something is fundamentally wrong with the conversion, it tends not to compile, rather than silently producing a test that runs but behaves incorrectly.

One small detail that says a lot about the approach: if you have a disabled thread group in your JMeter plan, the converter doesn't delete it and doesn't break it. It converts it and comments it out in the Gatling simulation — preserved, readable, easy to re-enable when you're ready.

The output isn't deterministic. Run the converter twice and you may get slightly different code — that's normal for LLM-generated output. The point isn't a byte-for-byte reproducible artifact. The point is a solid, compilable starting point you can actually work from.

What it looks like in practice

The two most common sources of migration pain are also the clearest illustration of what the converter does.

ThreadGroup → scenario

In JMeter, a ThreadGroup bundles your virtual user count, ramp time, and duration into a single XML element. In Gatling, these are separated: the scenario defines what users do, and the injection profile defines how users arrive. The converter handles this split.

The generated code includes comments explaining the conversion choices — a byproduct of how Claude Code works that turns out to be genuinely useful when you're reviewing the output.

CSVDataSet → csv feeder

JMeter's CSVDataSet and Gatling's csv feeder serve the same purpose but have different behaviors around how data is shared across virtual users. The converter handles the shareMode logic correctly: if multiple CSVDataSet elements reference the same file and are set to share data across the whole test, a single feeder is created and reused. If they're scoped per thread group, each scenario gets its own feeder.

This is exactly the kind of detail that trips people up doing the migration by hand — not because it's hard to understand, but because it's easy to miss if you're not deep in both tools at the same time.

What the skill actually knows

The converter works because it was built with explicit knowledge of where JMeter and Gatling diverge. A few examples of what that means in practice.

• Serialized thread groups: If your JMeter plan runs thread groups sequentially (serialize_threadgroups = true), the converter chains the corresponding Gatling scenarios with andThen. If they run in parallel, they're listed independently in the setUp block. This isn't something you'd think to check — until you run the test and the timing is wrong.

• Redirect behavior: follow_redirects = false in JMeter maps to disableFollowRedirect in Gatling. Easy to miss. Changes test behavior if it's wrong.
  ‍‍
• Functions with side effects: Some JMeter functions can save a result to a variable as a side effect — for example, __Random(0,10,myVar). Gatling's expression language doesn't support side effects inside expressions. The converter detects these cases and moves the logic into an exec block where saving a session variable is the right pattern.
  ‍‍
• JMESPath extraction: JMeter's JMESPath extractor with match=-1 (extract all values) maps to Gatling's jmesPath(...).ofList(). Without specific guidance, an LLM tends to miss this distinction silently — the code looks plausible but the check behavior is wrong. This is one of the cases where the skill's explicit instructions matter most.‍
  ‍
• Post-conversion suggestions: After converting, the skill looks for places where the output is technically correct but not idiomatic. If ramp_time is 0 or 1, for example, it will suggest replacing rampUsers with atOnceUsers — a small change that makes the intent clearer.

There's one area that's still a known rough edge: injection profiles. JMeter's model (threads, loops, duration) and Gatling's injection profiles don't map cleanly onto each other. The converter makes a reasonable attempt, but this is the part of the output you should review most carefully. For now, the skill's approach is to surface this as a post-conversion suggestion rather than silently produce something that looks right but isn't.

What you actually get

Let's be clear about the bar, because it matters.

What the converter produces is a compilable, structured Gatling simulation that captures the intent of your JMeter test. It's not a finished, verified load test. It's a starting point that's already further along than anything you'd want to write from scratch.

What you still need to do:

• Verify the injection profile: Make sure the number of users and the ramp pattern match what you actually want.
• Check scenario structure: Especially if you have loops — confirm they landed in the right place.
• Review any Groovy scripts: The converter translates them to exec blocks, which works well in straightforward cases, but complex Groovy logic deserves a human look.

The code-first nature of Gatling is an advantage here. If the conversion produces something wrong, it usually doesn't compile. Problems surface early, not silently at runtime.

And when you do need to iterate — whether that's adjusting the injection profile, fixing an extraction, or reworking a scenario — you're doing it in Claude Code with full context. What would take days to do manually, learning both tools deeply enough to get it right, can be done in hours with back-and-forth prompting from where the converter left off.

This isn't magic. It's a much better starting point than a blank file.

Try it

‍

You'll need:

• Claude Code
• The Gatling AI extensions

The JMeter converter is included in the extensions alongside our other skills. Once it's installed, open Claude Code in a project that contains a .jmx file and ask it to convert your JMeter test to Gatling. It'll take it from there.

We're actively looking for feedback — especially from teams with more complex JMeter plans. Real-world JMeter scripts vary a lot, and every edge case we learn about makes the converter better. If you try it and hit something it doesn't handle well, we want to know. Open an issue on GitHub or reach out directly.

The skill is plain text. If you have a specific use case that needs custom logic, you can fork it and adapt it. That's the point.

{{card}}