Swapping vendors tempts people into a big-bang weekend: rip out the Cisco, cable in the MikroTik, pray the config translation was complete. It rarely is, and the rollback is “put the old one back” at 3am. The calmer way treats the two vendors as a temporary mixed network: stand the new box beside the old, make them peers, and move the network across one subnet at a time, keeping both until nothing depends on the old.
A vendor migration is not a config translation exercise — it is a live-network change where the two devices speak different dialects of the same protocols. The danger of the big-bang swap is that config translation is never perfect: a QoS policy, an ACL subtlety, a timer, a feature that does not map one-to-one. You find the gap after the old box is already unplugged.
The surgical approach runs both vendors in parallel as a temporary mixed network. They interoperate over the protocols that are standards — a trunk for VLANs, OSPF for routing, VRRP for the shared gateway (standards, unlike Cisco-only HSRP) — so traffic can flow through either while you migrate subnet by subnet. Each VLAN’s gateway moves from Cisco to MikroTik one at a time, provably reversible, and the WAN moves last. The old box leaves only when it is idle.
01
The MikroTik joins beside the Cisco as an OSPF/VRRP peer; gateways move across one subnet at a time; the Cisco leaves when it carries nothing.
02
Peer over standards, migrate gateways with VRRP priority, move the WAN last — every step reversible by flipping a priority or a link.
| Step | Do | Rollback |
|---|---|---|
| 1 · Parallel + trunk | Rack the MikroTik, trunk it to the Cisco carrying all VLANs. No gateways on it yet. | Unplug the trunk. |
| 2 · Peer the routing | Bring up OSPF between Cisco and MikroTik; verify both learn each other’s routes. Still no user traffic on the MikroTik. | Shut the OSPF interface. |
| 3 · Shared gateway (VRRP) | For a pilot VLAN, add the MikroTik to a VRRP group as backup (Cisco master). The virtual IP is unchanged for hosts. | Remove the MikroTik from the group. |
| 4 · Flip the master | Raise the MikroTik’s VRRP priority so it becomes master for that VLAN. Sub-second, same virtual IP/MAC. | Lower priority — Cisco resumes master. |
| 5 · Repeat per VLAN | Migrate each subnet’s gateway the same way, pacing by risk. | Per-VLAN priority flip. |
| 6 · Move the WAN last | Once all gateways are on the MikroTik, cut the internet uplink across; retire the Cisco when idle. | Move the WAN back to the Cisco. |
Two interop traps. Use VRRP, not HSRP, for the shared gateway — HSRP is Cisco-proprietary and the MikroTik cannot join it, whereas VRRP is a standard both speak. And the spanning-tree dialects are not identical: Cisco’s per-VLAN PVST+ and MikroTik’s (R)STP/MSTP interoperate only with care — agree on a common mode (MSTP or plain RSTP) and set the root deliberately, or the trunk between them can blackhole a VLAN or trigger a reconvergence. Feature idioms differ too (QoS, NAT, ACL vs firewall) — translate behaviour, then verify it, do not assume the config maps one-to-one.
03
| Before you start | Why |
|---|---|
| Behaviour map, not a config copy | QoS/ACL/NAT idioms differ — translate what each rule does, then verify. |
| VRRP (not HSRP) for the shared gateway | The standard both vendors speak; HSRP excludes the MikroTik. |
| Common spanning-tree mode + explicit root | PVST+ vs RSTP/MSTP interop is where a mixed trunk bites. |
| OSPF adjacency proven before any gateway moves | The parallel path must route before you depend on it. |
| WAN moved last, Cisco retired only when idle | Keep the fallback until nothing needs it. |
Takeaways
A vendor migration is low-risk when both run in parallel and traffic moves gradually. I peer the old and new with a routing protocol, migrate gateways one at a time with VRRP, and cut the WAN last.
Book a Discovery Call →