Migration

How to migrate from QA Wolf to self-hosted agentic QA

2026-08-29 · The QA Reef team · 4 min read

QA Wolf's local flow runtime is open source, and it runs offline. We didn't take that from a license file: we cloned @qawolf/cli, built it, and ran real .flow.ts files with no QAWOLF_API_KEY set. The CLI's own JSON output went from {"type":"success","message":"Environment ready"} straight through to a pass. Only the platform commands (flows run --env, environment, issue, tag, auth) phone home.

So your flows are not hostages, and "migrate off QA Wolf" is not a rescue operation. It's three replacement projects of very different sizes. Plan those three and the migration plans itself.

Project 1: authoring (the real gap)

Without a paid account you lose Mapping AI and Automation AI, the parts that turn a recorded session or a prompt into new flow code. This is the piece that needs a real replacement. QA Reef's version: a mapping session records your clicks and types (or an OCR-driven operator drives the app from a plain-English goal), and a deterministic generator turns the recording into Playwright code. The model is only ever asked for a title and up to three assertions, never step logic, and every model output is stamped with the model id that proposed it.

If your team wants to keep authoring in QA Wolf's format, we wrote a converter (toQawolfFlow() in app/codegen-flow.js) that emits .flow.ts in their exact shape: same target convention, same locator-resolution order, same {param}-to-process.env secrets handling. We converted three real recorded flows and ran them through the unmodified QA Wolf CLI. Two passed. The third failed because its dev server wasn't running, not because of the format. Commands and output are in vendor/QAWOLF-OSS.md if you'd rather verify than believe.

Project 2: execution (smaller than it looks)

QA Wolf's pre-warmed Kubernetes grid (described in their own engineering blog) goes away with the subscription. The replacement is whatever already runs Playwright for you: GitHub Actions, a self-hosted runner, a cron job on a box you control, pointed at qawolf flows run or at your generated Playwright specs. You now own runner capacity instead of renting autoscaling. For most teams that's a line item, not an architecture project. If you'd rather rent than own, QA Reef's hosted plans meter the same unit at $0.015 per browser-minute, one tenth of QA Wolf's published $0.15 per runner-minute (as published 2026-08-30); the division.

Project 3: triage (the one teams underestimate)

Coverage as a Service includes humans who reproduce and confirm every failure before you see it (qawolf.com/service). No tool replaces that, ours included. When you leave, your team owns the question "flake, real bug, or broken test?" for every red run. Tooling can shrink the pile: a third verdict state so an ambiguous measurement never lands in the failure queue at all (see PASS / FAIL / UNMEASURED), and bugs auto-filed with a trace attached so triage starts from evidence instead of a Slack thread. Shrinking the pile is a smaller claim than eliminating it. Make sure whoever approves the migration knows which claim they're buying.

What doesn't migrate at all

Three things have no self-hosted equivalent here today: mobile testing (QA Wolf runs Appium; QA Reef is web-only), the hosted grid, and human-verified "zero flake" reporting. If one of those is the reason you bought QA Wolf, keep QA Wolf.

The short version

The flows and the runner are already yours, verified offline. What you're actually replacing is authoring, runner capacity, and triage, in ascending order of difficulty. Budget accordingly.