MikroTik / RouterOS · Tutorial · July 2026

MikroTik
Upgrading RouterOS Safely

Upgrades close the exact holes the offensive posts abuse — but a botched upgrade to a router 40km away, up a mountain, behind a locked taverna, is its own disaster. This is the safe procedure: pick the right channel, back up first, do the two-part upgrade everyone forgets, and keep a rollback path. The Cisco "Upgrading Safely" post, in RouterOS.

MikroTik RouterOS Upgrade Firmware Maintenance

Staying current is a security control — the Winbox and SMB bugs that built botnets were all patched before they were mass-exploited; the victims simply hadn't upgraded. But RouterOS upgrades have a trap that catches almost everyone: there are two things to update, not one. The RouterOS packages (the OS) and the RouterBOARD firmware (the bootloader/hardware layer) are separate, and check-for-updates only handles the first. Skip the second and you leave firmware-level fixes on the table for years.

This post is the discipline that keeps a remote upgrade from becoming a site visit: the right release channel for the box's role, a backup that can actually restore it, the two-part upgrade in the right order, and a known rollback. It mirrors Cisco IOS: Upgrading Safely and leans on Backup and Recovery.

Prerequisites

Management access you won't lose if the box reboots (ideally out-of-band or via a second path)
A maintenance window — upgrades reboot the router

Pick the Channel, Check for Updates

RouterOS has release channels of decreasing conservatism. Production edge routers belong on stable; only lab gear should ever see testing. Long-term deployments can pin to long-term for fixes-only.

Terminal — channel, then check (don't install yet)

> /system package update set channel=stable
> /system package update check-for-updates
   installed-version: 7.15.2
      latest-version: 7.15.3
            status: New version is available
# Read the changelog before every upgrade. 'stable' for production;
# 'long-term' if you want only backported fixes, no new features.

Back Up First — Both Kinds

Take both a binary backup (restores the exact box, same model) and a text export (portable, diff-able, survives a model change). Pull them off the router before you touch anything.

Terminal — belt and braces before an upgrade

> /system backup save name=pre-7.15.3       # binary, full state
> /export file=pre-7.15.3                    # text, portable
# Copy BOTH off the box (WinBox Files drag-out, or scp) — a backup
# that only exists on the router you're about to reboot is not a backup.

The Two-Part Upgrade Reboots

First the OS packages, reboot. Then — the forgotten step — the RouterBOARD firmware, reboot again. Do them in this order; the new firmware often depends on the new OS.

Terminal — packages, then RouterBOARD firmware

# PART 1: RouterOS packages. This downloads and reboots into the new OS.
> /system package update download
> /system reboot

# ...box comes back on 7.15.3. Now PART 2, the step people miss:
> /system routerboard print
    current-firmware: 7.15.2
    upgrade-firmware: 7.15.3        # mismatch = firmware not yet applied
> /system routerboard upgrade
> /system reboot                     # firmware only takes effect after this reboot

⚠ Gotcha — current-firmware ≠ upgrade-firmware Means You're Not Done

After the OS upgrade, /system routerboard print shows the two firmware fields disagree — that's RouterOS telling you newer firmware is staged but not applied. It only takes effect after routerboard upgrade and a reboot. Fleets that upgrade OS-only for years carry firmware from whenever they were unboxed, missing low-level fixes. Make this the second half of your checklist, every time.

Rollback & Trimming the Attack Surface

If the new version misbehaves, RouterOS keeps the previous packages so a downgrade is one command. And while you're here, remove packages you don't run — less code, less to patch.

Terminal — downgrade path + package pruning

# Roll back to the previously-installed version (kept on the box):
> /system package downgrade       # confirms, then reboots to the old version

# Disable packages this box doesn't use — e.g. no wireless on a router:
> /system package disable hotspot,ppp
> /system reboot
# If an upgrade ever leaves a box unreachable, Netinstall reflashes it
# from a PC — the ultimate rollback. Have the .npk for your model handy.

Takeaways

Upgrading is a security control — the famous MikroTik botnets hit boxes that simply hadn't patched.
Production on stable (or long-term), never testing. Read the changelog before each upgrade.
Back up both ways first — binary for exact restore, text export for portability — and pull them off the box.
The upgrade is two parts: RouterOS packages then RouterBOARD firmware, each with its own reboot. The firmware step is the one everyone forgets.
current-firmware ≠ upgrade-firmware means you're not finished — apply and reboot.
Keep a rollback path — package downgrade for software, Netinstall for a brick — and prune packages you don't run.

Remote sites on RouterOS versions you're afraid to touch?

NOCTIS runs staged, backed-up, rollback-ready upgrade programmes for MikroTik and Cisco estates across Crete — including the firmware step your last integrator skipped — without the site visit.

Book a Discovery Call →