TL;DR: Gatling's AI converter transforms your exported VuGen scripts into production-ready Gatling simulations — in Java, Scala, Kotlin, JavaScript, or TypeScript — directly in your IDE. It maps HTTP functions, correlations, think time, session variables, and parameter files automatically, flags what it can't handle, and compiles to verify. No manual rewriting. Files never leave your machine.
You've decided to move from LoadRunner to Gatling. But then you open Action.c and remember exactly why this has been on the backlog for months.
There's the C-style HTTP calls. The web_reg_save_param correlation rules you tuned over weeks. Think time config buried in default.cfg. Parameter files with custom selection logic. And if you miss any of it, your new tests won't reflect production behavior — and you won't find out until something breaks under load.
Manual migration isn't just slow. It's a reliability risk.
What the converter actually does
Gatling's LoadRunner converter is an AI skill that runs inside your IDE via Claude Code, Cursor, or any compatible coding assistant. It reads your full VuGen export — scripts, config, parameter files — and generates a working Gatling project in your language and build tool of choice.
- Languages: Java, Scala, Kotlin, JavaScript, TypeScript
- Build tools: Maven, Gradle (JVM), npm (JS/TS)
- Works with: open-source Gatling — no Enterprise account required
- Data stays local: VuGen files and test data never leave your machine
.arcade-embed { position: relative; width: 100%; max-width: 1100px; margin: 32px auto; border-radius: 16px; overflow: hidden; box-shadow: 0 12px 30px rgba(0,0,0,0.2); background: #000; } .arcade-embed iframe { width: 100%; height: 620px; border: none; display: block; } @media (max-width: 768px) { .arcade-embed iframe { height: 480px; } } @media (max-width: 480px) { .arcade-embed iframe { height: 380px; } }
The workflow
1. Find your LoadRunner project: The converter scans for an exported VuGen ZIP. If it finds multiple, it asks you to pick one.
2. Detect or create a Gatling project: It detects an existing Gatling project in your directory, or scaffolds a new one if none exists.
3. Choose your language and build tool: Java, JavaScript, TypeScript, Scala, or Kotlin. Maven or Gradle. The generated code is idiomatic to your choice.
4. Convert: Every LoadRunner element is mapped to its Gatling equivalent and written into your project. Parameter files, body templates, and runtime settings are carried over automatically. The code is then compiled to verify it builds.
The mapping table: what goes where
LoadRunner to Gatling command mapping MIGRATION • CHEAT SHEET
| LoadRunner | Gatling |
|---|---|
web_url() |
http(name).get(url) |
web_submit_data() |
http(name).post(url).formParam() |
web_submit_form() |
http(name).post(url).formParam() |
web_custom_request() |
http(name).httpRequest(method, url) |
web_add_header() |
.header() on the next request only |
web_add_auto_header() |
httpProtocol.header() persists from that point |
web_reg_find() |
.check(bodyString().contains()) |
web_reg_save_param() |
.check(regex("LB(.*?)RB").saveAs()) |
web_reg_save_param_json() |
.check(jmesPath(...)) |
{ParamName} substitution |
#{paramName} |
lr_save_string() |
.exec(session -> session.set()) |
vuser_init section |
before block |
Action section |
scenario |
vuser_end section |
after block |
| Single-request transaction | Dropped — use the request name directly |
| Multi-request transaction |
group() block |
The web_add_header / web_add_auto_header distinction matters: one-shot headers that LoadRunner applies only to the next request must not be hoisted into httpProtocol. The converter handles this correctly.
Configuration fidelity: default.cfg Is not ignored
This is where most manual migrations lose fidelity. The converter reads default.cfg and translates runtime settings into Gatling equivalents:
LoadRunner runtime settings to Gatling mapping MIGRATION • SETTINGS
| LoadRunner think time setting | Gatling equivalent |
|---|---|
Options=NOTHINK |
.disablePauses() on setUp
|
Options=RECORDED |
Pauses kept as-is |
Options=RANDOM |
.uniformPauses() with ThinkTimeRandomLow / ThinkTimeRandomHigh bounds |
Options=MULTIPLY |
Flagged — no direct equivalent, user is informed |
ContinueOnError=1 |
exitHereIfFailed() added between requests |
SearchForImages=1 |
.inferHtmlResources() on httpProtocol
|
CustomUserAgent |
.userAgentHeader() on httpProtocol
|
Parameter files: feeder strategies are preserved
For .prm files, the converter reads each [parameter:<name>] entry and maps the selection strategy:
LoadRunner feeder behavior mapping DATA • FEEDERS
| LoadRunner SelectNextRow | Gatling feeder |
|---|---|
Sequential |
.circular() |
Random |
.random() |
Unique |
.queue() ¹ |
| Same line as | Matched to that parameter’s feeder configuration |
¹ .queue() consumes records once and fails when exhausted
¹ No exact Gatling equivalent — the converter uses .queue()\ and flags it for review.
Data files are copied to the Gatling project's resources\ directory automatically.
What gets flagged (not silently dropped)
Two LoadRunner features have no direct Gatling equivalent and are explicitly called out rather than silently removed:
-
Rendezvous points (
lr_rendezvous): removed, and the user is informed there's no direct equivalent in Gatling - IP spoofing: flagged for manual handling at the infrastructure level
Hardcoded credentials and environment-specific values found in the script are also surfaced for parameterization.
Try it
Install the Gatling plugin in Claude Code or Cursor, export your VuGen project, and run /gatling-convert-from-loadrunner. The converter maps your scripts, generates idiomatic Gatling code in your language of choice, and compiles to verify — without leaving your IDE.
Hit an edge case or a LoadRunner pattern that didn't convert cleanly? The skill is open source — contributions welcome on GitHub. Or if you're a JMeter user, try our JMeter converter too!
Top comments (0)