GUIDE / UPGRADES

Upgrades.

Keeping RouterOS current is a security item, not just a feature one — most of the published CVEs are fixed in patch releases on the same minor. The catch is that downgrades are partly one-way (config schemas evolve) so you want to back up before every upgrade and read the channel descriptions before picking one.

Release channels

RouterOS publishes four parallel channels:

  • stable — the recommended track for production. Bugfixes and security patches; new features only after they've baked in testing.
  • long-term — older minor with extended security backports. For boards in environments where you'd rather pay nothing in feature churn but still get CVEs patched. v6.49.x lives here.
  • testing — newer features, exposed-to-the-wild stability. Useful on a lab device; risky in production.
  • development — pre-release. Don't.

Most homelab / SOHO setups want stable. Production WISP edges sometimes pin long-term for change-management reasons.

Setting the channel

v62 lines · 82 bytes
/system package update set channel=stable
/system package update check-for-updates
v72 lines · 82 bytes
/system/package/update set channel=stable
/system/package/update check-for-updates

check-for-updates queries MikroTik's update server and populates the installed-version / latest-versionfields. It doesn't install anything yet.

The upgrade flow

Three commands, in order:

v610 lines · 345 bytes
# 1. take a backup BEFORE upgrading (always, no exceptions)
/system backup save name=pre-upgrade-$(date +%Y%m%d)
/export file=pre-upgrade-config-$(date +%Y%m%d)

# 2. download + reboot to apply
/system package update install

# 3. after reboot, verify the new version
/system resource print
# look for "version: 7.x.y" matching what you intended
v710 lines · 345 bytes
# 1. take a backup BEFORE upgrading (always, no exceptions)
/system/backup save name=pre-upgrade-$(date +%Y%m%d)
/export file=pre-upgrade-config-$(date +%Y%m%d)

# 2. download + reboot to apply
/system/package/update install

# 3. after reboot, verify the new version
/system/resource print
# look for "version: 7.x.y" matching what you intended

Step 2 reboots automatically. The router is unreachable for ~30–60 seconds on most hardware; longer on RouterBOARD with slow flash. Plan for the interruption.

Don't forget the RouterBOARD firmware

The RouterOS install you just did is the OS. The RouterBOARD also has its own bootloader/firmware ("RouterBOOT") which can lag behind the OS after an upgrade — and the OS will frequently ship features or security fixes that depend on a newer RouterBOOT. Check for an available firmware update after the OS reboot finishes, then a second reboot applies it:

v66 lines · 207 bytes
# show current firmware vs the version bundled with the new OS
/system routerboard print

# if "current-firmware" lags behind "upgrade-firmware", upgrade and reboot
/system routerboard upgrade
/system reboot
v76 lines · 207 bytes
# show current firmware vs the version bundled with the new OS
/system/routerboard print

# if "current-firmware" lags behind "upgrade-firmware", upgrade and reboot
/system/routerboard upgrade
/system/reboot

On a healthy upgrade you'll see current-firmware equal toupgrade-firmware in the print output — that's the all-clear. Skipping this step often shows up later as an "unexplained" feature silently not working (e.g. SFP modules failing to negotiate, or a new POE behaviour not taking effect).

Downgrading

Downgrades are partly supported. RouterOS keeps the old image around as a fallback, but the config schema may have evolved during the upgrade — settings that didn't exist in the older version get silently dropped.

v62 lines · 73 bytes
# downgrade to the previously-installed version
/system package downgrade
v72 lines · 73 bytes
# downgrade to the previously-installed version
/system/package downgrade

Downgrading is riskier on v7

RouterOS v6

v6 downgrades within the 6.x series are generally safe. Config changes between 6.x patch releases are minor.

RouterOS v7

v7 has had several config-schema breaking changes within the 7.x series itself. Downgrading from a recent 7.x to an older 7.x can lose containers, WireGuard interfaces, IPv6 firewall rules and anything in /interface bridge that depends on newer VLAN matching. Treat v7 downgrades as nuclear: take a config export, downgrade, restore by hand from the export.

v7 → v6 is a one-way trip. Don't attempt without a Netinstall plan and a backup of the v6 config from before the original v6→v7 upgrade.

v6 → v7 migration

The v6 → v7 jump is a major version transition. MikroTik's official guidance:

  • Upgrade to the latest v6.49.x first (closest to v7 in feature parity).
  • Export the config to text (/export) — not the binary backup, which is version-bound.
  • Run the v7 installer.
  • Most config carries over, but expect to manually fix anything that used /interface wireless (WiFi packaging changed) and anything bridge-VLAN-related.

See RouterOS v7 migrationon help.mikrotik.com for the full list of breaking changes.