I want to migrate my configuration from an RB1100Hx2 (13 ether ports) to a CCR1036-12G-4S (12 ether ports).
The old router has the ether ports renamed, instead of "ether1" (default) I use "eth1-SWITCH1", and so forth.
Before migration, I make sure I use the same RouterOS Version on the old and new hardware.
However, when I import the configuration to the new hardware (with 1 less ether port), the names of the ether-ports are left on their default name (ether1 .. 12). This turns all rules that reference the ether name to red, displaying a warning (since it cant find an ether port with the given name).

What is the best way to work around this?
Would it help to rename back the ether ports to their default name (ether1 .. 12) before creating a backup of the configuration?
Note: ether13 is actually unused on the old hardware.

The export should contain lines like
set [ find default-name=ether1 ] name=ether1-renamed in the /interface ethernet section.
Is that the case? If so, what default-name values are shown in the export of the RB1100Hx2? Are they the same like on the CCR1036?

Thank you for your reply!

I am sorry, I wasn't clear what "type of migration" I used... I used backup/restore via files. That is probably not the right way to migrate to a different type of hardware?

Instead I should use export terse show-sensitive file=config correct?

Yes, when using the export command, it indeed starts with interface naming commands. I will try that tomorrow.

NO DO NOT!! use backup from one device to another!!!

One approach to consider is to export your file and open in notepadd++

/export file=anynameyouwish

Then you will have to edit the file to remove things that are specific identifiers to the old router.
Then you can use terminal to paste entries directly into the new router.

You cannot just go from the top down because the order of a config is not setup for this kind of HACK.
What I do would do is take the new router and USING SAFE MODE, replace chunks as you go.


GLuck.........

A big +1 on previous remark. NEVER import binary backup into another router having different HW. (Even for same HW, it is not really advised IMHO since you will also copy MAC addresses over causing possible problems on your network if both devices remain active).

If you already imported that binary backup into your new device, it is advisable to netinstall it again.
Because chances are there bits and pieces of config imported in your new device which may cause problems later (because it was for a different kind of hardware).

The new device is not within the same network as the old device. In fact they are physically at different locations. The idea was to setup the new machine with the SAME MAC addresses (and configuration) as the old device, and then replace it (remove the old, add the new device). So I actually wanted to migrate the same MAC addresses on purpose, so that the surrounding network believes it is dealing with the same router.

If you think that is a bad idea (or not necessary) then I will do without - and use the default MACs of that device.

Will a factory reset restore MAC addresses? Or is there any other way how to restore ALL MAC addresses on the device (preferably in one go)?

If you think that is a bad idea (or not necessary) then I will do without - and use the default MACs of that device.

It's not a matter of what a random forum user thinks (you know neither of us three who have responded, do you), it's a matter of what Mikrotik says in the manual: "can be re-applied on the same or a different device (with the same model name/number)". I guess the wording could be better (like "on the same device or on another device of the same model name/number"), but the message is clear.

Will a factory reset restore MAC addresses? Or is there any other way how to restore ALL MAC addresses on the device (preferably in one go)?

It may, but as @holvoetn wrote, a netinstall is a better option because cleaning up after a restore of a backup taken on another device model is not a typical task so /system reset-configuration may not remove 100 % of the wrong bits. But these are just random forum user opinions, as Mikrotik doesn't give any instruction for this scenario they have never anticipated. So maybe /system reset-configuration is actually enough.


As for changing the MAC addresses to be the same like on the old device - nothing is wrong about that per se if you have your reasons to do so. You can edit the .rsc file created by /export before running it on the target router and add the mac-address=xx:xx:xx:xx:xx:xx items to the /interface ethernet set ... commands to have it all done in one go. But as @anav has pointed out, even an export from the very same ROS version may fail to import completely. The configuration export is a regular script, and execution of scripts stops at first error. And sometimes the order of items in the export is wrong so a row of the script refers to an object that has not been created yet. That's why importing it manually row by row, or at least section by section, is a better approach.

As the topic is not that old, and I'm also planning to migrate my setup to new hardware, i'm answering to this thread instead of opening a new one.
Im running a hexs and 2 Cap-ACs in CAPSman local forwarding mode, require peer certs enabled (from hexS).
Additionally I'm running VLANs/network segmentation (so bridge MAC might differ later on)
Is there a best practice on how to migrate from my hexS (mips) to a RB5009 (arm), without setting up the CAPSman/firewall rules etc. again?

my approach (with downtime) would be:
- unset "require peer certificate on hex-S
- export config on hex-S
- adapt config to be able to run on rb5009
- initially configure rb5009 and import config
- generate new capsman-cert and deploy it to APs
- set "require peer certificate on rb5009
- enjoy

You can use /certificate export-certificate to copy the certificate from the hEX S to the 5009. Just remember that you have to specify the passphrase for the export, otherwise the private key will not be exported. When importing, import the certificate file first (it will ask for a passphrase but it can be left blamk) and then the private key file (and here you must enter the correct passphrase).

Importing of the configuration is best done manually, line by line or at least section by section, to handle surprises.