You have a hEX that has run for five years and an RB5009 sitting next to it on the table. The temptation is to restore the backup and be done. That does not work, and this chapter explains why, and what to do instead.
Why a backup cannot move between models
A .backup file is a binary image of that one device's configuration database. It holds things that belong to the hardware rather than to you: the interface names as that model knows them, MAC addresses, the licence level and the serial number. Restoring it on another model gives you, at best, interfaces that do not exist, and at worst a device that boots into a state you cannot reach.
MikroTik is clear about it: a backup belongs to the same device, the same architecture and the same RouterOS version. It is meant to put back what was there, not to move house.
Use an export instead
An export is readable text: the commands that build your configuration. On the old device:
/export hide-sensitiveWith hide-sensitive, passwords and keys stay out. That is fine for importing; the tool asks you to fill them in again later. Do note that your WireGuard keys are then not in that file either and have to come from somewhere else. The admin password is never in an export at all.
Paste that text into the configurator's import. What the tool recognises lands in the fields and stays editable; what it cannot capture in a field is carried over verbatim into the result. The report says, per section, which of the two happened. See Importing an existing configuration.
The v6 to v7 gap
If the old device still runs RouterOS v6, a conversion sits in between. The tool recognises a v6 export from its header line and offers the conversion. Routing marks become routing tables, /ip route rule becomes /routing rule, and the three NTP fields are merged into one servers=. What is genuinely built differently in v7, such as OSPF, BGP, routing filters, MPLS, VRF and User Manager, is not guessed: those lines are kept as comments with a pointer to the manual. See From RouterOS v6 to v7.
That part is still in beta. Read the result before you use it.
Different port names and counts
This is where most of the time goes. A configuration names ports, and those names differ per model:
- A hEX has
ether1throughether5; an RB5009 has eight plus ansfp-sfpplus1. Moving up, you have ports left over that appear nowhere. Moving down, rules point at ports that do not exist, and those rules fail when you paste. - SFP ports are called
sfp1,sfp-sfpplus1,sfp28-1orcombo1, depending on the model. - Wi-Fi is
wlan1on the old package andwifi1on the new one.
The import first reads the model line at the top of the export. If that model is not in the catalogue, it is derived from the interface names the configuration mentions and you get a made-to-measure device. After that, deliberately pick your new model in the tool, because the new port layout should lead, not the old one. Then walk through the port assignment: which port becomes WAN, which ports go in the bridge, which port is the trunk. See Bridge and ports and Choosing your device.
Wi-Fi packages
RouterOS v7 has two Wi-Fi packages, wireless (the old one, with /interface wireless) and wifi (the new one, with /interface wifi). Some devices can run either; newer ones only the new one. A Wi-Fi configuration from one package does not work on the other, and that is the trap people fall into: bridges, DHCP and leases are all present after the move, only the device broadcasts nothing.
So pick the package that belongs to your new device and expect to set the Wi-Fi up again: SSID, passphrase, bands, channels, and the VLAN per SSID. The same holds for CAPsMAN, where /caps-man and /interface wifi capsman are two separate worlds. See Wi-Fi settings and CAPsMAN.
Using the comparison
New hardware goes to factory defaults and gets the whole script pasted onto it. The comparison is for the moment after that: once the new device is running and you want to change something, compare the script from the tool against the /export of that running device. You then get only the lines that change something.
Two things to know. An object that exists on both sides is not deleted and recreated but adjusted, so your bridge is not torn down only to be rebuilt. And tables where order matters, the firewall filter, NAT, mangle and raw, cannot be patched rule by rule: if anything in them differs, such a table is replaced as a whole. The output says so when it does.
What to check afterwards
- The admin password and the Wi-Fi passphrases: those were not in the export.
- Certificates and WireGuard keys. Create them again, or move them over by hand.
- Scripts and the scheduler: they often refer to the old device's port names.
- Queues and static routes pinned to old interface names.
- Whether the old device may really be switched off. Keep it ready for a week. See Using the script.