Moving from VIA to Raw QMK Firmware: When to Switch

October 20, 2026 · by Noah Fischer · 4 min read

What’s the Real Difference Between VIA and Raw QMK?

VIA sits on top of QMK like a dashboard sits on top of an engine. It lets you remap keys, build layers, and tweak lighting through a clean GUI, no compiling, no terminal, nothing scary. Raw QMK strips that away. You write your keymap by hand in keymap.c and build the firmware yourself with QMK’s CLI or QMK MSYS.

Here’s a simple way to picture it: VIA is the automatic transmission. Raw QMK is the manual. The automatic gets you there faster on a normal Tuesday, but the manual gives you access to every gear the engine actually has, including the ones you didn’t know existed.

Signs You’re Ready to Switch

You don’t need to jump to raw QMK just because you feel “advanced” now. Switch because VIA is genuinely blocking something you want to build. Here’s what that usually looks like in practice:

• You want custom keycodes. VIA has no way to send a string of text on a single keypress, run a macro with conditional logic (if layer X, do A, else do B), or stack multiple actions onto one tap/hold key.
• You need tap dance, combos, or leader key sequences. These live in keymap.c (sometimes rules.mk too), and VIA’s interface simply doesn’t have a menu for them.
• You want OLED or RGB matrix behavior beyond the presets. Reactive per-key lighting, custom animations, an OLED screen that shows your current layer or live WPM count, all of that is C code, not a dropdown.
• You’re chasing lower latency or tighter matrix scanning. Raw QMK lets you touch rules.mk and config settings that VIA quietly hides from you.
• Your board isn’t officially VIA-compatible. Some boards need you to hand-build a via.json, or don’t support VIA at all. At that point raw QMK isn’t really optional.
• You want real version control. Tracking a keymap.c file in Git, with diffs, commits, and branches, beats exporting and re-importing VIA JSON blobs every time you change something.

If none of this applies to you yet, stay on VIA. It’s not a training-wheels tool you’re supposed to graduate from. For a lot of setups, it’s genuinely the right tool, full stop.

What You Gain by Switching

• Full QMK feature access: combos, tap dance, key overrides, custom macros, RGB matrix effects, encoder logic, and anything else QMK supports.
• Precise compile-time control: flip features on or off in rules.mk to free up firmware space or unlock capabilities VIA never exposed.
• Real debugging tools: QMK’s console output and dprintf logging will show you exactly what’s happening when a key doesn’t behave, something VIA can’t do at all.
• Portability: your keymap is now a plain text file. Share it, fork it, drop it into another board, no export dance required.

What You Lose (Trade-offs)

• No live remapping. Want to move one key? Edit the code, compile, flash, test. Every tweak now takes minutes instead of seconds.
• A real learning curve. You’ll need to know basic C syntax and feel comfortable typing commands instead of clicking buttons.
• No visual lighting preview. Changing an RGB matrix effect means changing numbers, flashing the board, and seeing if you guessed right.

How to Migrate Safely

1. Back up your current VIA keymap first. Export the JSON from VIA before you touch anything else. This is your safety net.
2. Clone the QMK firmware repo and find your keyboard’s folder under keyboards/.
3. Make a new keymap folder, something like keymaps/yourname, instead of overwriting the default one. This keeps your work separate and safe from future QMK updates.
4. Rebuild your layers in keymap.c, using your VIA export as the cheat sheet for keycodes and layer order.
5. Add advanced features one at a time. Write one macro or one combo, compile it, test it on the actual board, then move to the next. Don’t try to port everything in one go, you’ll spend hours hunting a single typo.
6. Use the QMK CLI (qmk compile, qmk flash) so your workflow is repeatable and scriptable instead of a pile of manual steps.
7. Keep a VIA keymap folder around as a fallback. If your new raw keymap breaks mid-week, you can flash the old VIA build back in seconds instead of debugging under pressure.

A Middle Ground: VIA + Custom Keycodes

This isn’t actually all-or-nothing. Plenty of experienced users keep VIA running for day-to-day remapping, then quietly build custom keycodes and macros into a VIA-compatible keymap.c with VIA_ENABLE = yes sitting alongside their hand-written code. You still get live remapping for the small stuff, a key swap here, a layer tweak there, while the heavier logic runs underneath, untouched by the GUI.

Conclusion

Make the move when you hit an actual wall: a macro VIA can’t build, a combo it can’t express, hardware tuning it can’t reach. That’s the real signal, not a vague sense that you’ve “outgrown” the GUI. Yes, you trade convenience for control, but if you’ve backed up your keymap and kept your changes in their own folder, the whole migration is low-risk and fully reversible. Most people don’t need to abandon VIA completely. They just need to know the exact moment raw QMK’s extra effort starts paying for itself.