MikroTik RouterOS v6 to v7 Migration: Complete Upgrade Guide

0 Shares

AMoving a MikroTik router from RouterOS v6 to RouterOS v7 is more than installing a newer package. RouterOS v7 changes parts of the routing architecture, introduces new configuration models, and may convert supported legacy settings during the upgrade. A router can boot successfully while still having routing filters, BGP policy, OSPF behavior, wireless settings, or scripts that need manual review.

This guide provides a cautious, repeatable RouterOS v6 to v7 migration process for production networks. It covers preparation, backups, upgrade paths, configuration conversion, routing and wireless changes, validation, rollback planning, and common troubleshooting scenarios. Examples are intended as operational guidance, not a promise that every v6 configuration converts identically on every hardware model or release.

Important: test the migration on the same model and a representative configuration before changing a production router. Keep console or out-of-band access available. Do not rely on a remote session as your only recovery path.

What Changes Between RouterOS v6 and v7?

RouterOS v7 is a major platform evolution. It retains many familiar RouterOS concepts and CLI conventions, but some subsystems have new configuration paths and different behavior. The most migration-sensitive areas are:

Routing: BGP, OSPF, routing filters, route selection, and routing-table handling use newer configuration structures.
Routing policy: legacy filter expressions and attributes may need translation and careful review rather than a blind copy.
Wireless: supported devices and packages may use the legacy wireless menu or the newer WiFi configuration menu. Package and driver availability depends on hardware.
Hardware and drivers: support and performance characteristics can differ by model, switch chip, architecture, and RouterOS release.
Scripts and automation: scripts that parse CLI output, depend on menu paths, or use changed properties can fail even if the router itself is healthy.
Packages and firmware: package availability and RouterBOARD firmware compatibility should be checked as part of the upgrade plan.

Do not assume that every v6 command has a one-to-one v7 equivalent. Treat the conversion as a starting point, then compare the effective configuration and operational behavior against the v6 baseline.

Pre-Migration Checklist

Before upgrading, establish exactly what is running and what the router is expected to do. Record the model, architecture, RouterOS version, RouterBOARD firmware, installed packages, storage capacity, and available RAM. Check the target v7 release notes and the MikroTik product documentation for device-specific limitations.

Confirm that the exact router model and architecture support the intended RouterOS v7 release.
Check free storage and package requirements before downloading or installing updates.
Identify whether the device uses legacy wireless, newer WiFi drivers, special LTE/modem packages, containers, or other optional packages.
Inventory routing protocols, routing tables, routing rules, filters, VRFs, tunnels, IPsec, queues, NAT, firewall rules, VLANs, DHCP, DNS, and monitoring.
List every external dependency: RADIUS, TACACS+, syslog, SNMP, NTP, DNS, authentication, scripts, API clients, and configuration-management jobs.
Record critical routes, BGP peers, OSPF neighbors, default gateways, VPN peers, and service reachability before the change.
Arrange a maintenance window and a tested local console or out-of-band recovery path.

For a general package and upgrade workflow, review How to Upgrade and Downgrade MikroTik RouterOS Safely. This migration guide adds the configuration and compatibility checks that are specific to the v6-to-v7 transition.

Back Up and Document the RouterOS v6 Configuration

Create both a binary backup and a text export. They serve different purposes: a binary backup is useful for restoring a compatible device to its prior state, while a text export is readable, searchable, and useful for comparing configuration before and after conversion.

/system/resource/print
/system/package/print
/system/routerboard/print
/system/identity/print
/export file=pre-v7-export
/system/backup/save name=pre-v7-backup

Download the resulting files from the router and store them securely outside the device. Protect backups as credentials: exports and binary backups can contain sensitive network details, and depending on how secrets are exported they may expose credentials or other security-relevant information. Restrict access and use encrypted storage.

Also capture operational state, not just configuration:

/ip/address/print detail
/ip/route/print detail
/ip/firewall/filter/print stats
/ip/firewall/nat/print stats
/interface/print stats
/log/print

For routing-heavy deployments, save the BGP peer and route state, OSPF neighbor state, routing table contents, and key counters using the commands available on your installed v6 release. Record the output somewhere outside the router so you can compare it after the upgrade.

If you need to export selected tables for documentation or analysis, see how to export ARP, DHCP, and routing tables from MikroTik.

RouterOS v6 to v7 Upgrade Procedure

1. Confirm the upgrade path

Read the release notes for the current v6 release, the target v7 release, and any intermediate release recommended for your device. Do not assume that the newest long-term or stable channel is automatically the right choice for every production network. Select a release that is supported by your hardware and tested features.

2. Update the v6 router to a suitable maintenance release

Where appropriate, first bring the router to a current, supported v6 maintenance release and verify normal operation. This can reduce the number of variables in the migration, but follow MikroTik’s published upgrade guidance for the particular model and release.

3. Transfer backups off the device

Confirm that the export and backup files are present on another system and can be downloaded. A backup that exists only on the router is not a reliable recovery plan if storage or boot problems occur.

4. Install the selected RouterOS v7 release

Use the supported update mechanism or upload the correct packages for the device architecture. Verify package names and architecture before installation. Avoid mixing packages from different releases. Allow the router to complete the reboot without interrupting power.

5. Review RouterBOARD firmware

After RouterOS boots, inspect the RouterBOARD firmware version and the upgrade status. Upgrade RouterBOARD firmware when recommended for the device and release, then reboot if required. RouterOS package version and RouterBOARD firmware version are related but distinct items; do not assume one automatically updates the other.

6. Inspect conversion messages before changing anything

Review the system log and any migration or configuration-conversion messages generated during startup. Save the messages externally. Resolve conversion warnings deliberately rather than repeatedly rebooting or applying broad configuration resets.

Configuration Conversion: What to Expect

During a major-version upgrade, RouterOS may convert supported parts of the saved configuration into the newer internal format. Conversion is not a guarantee that every feature, policy, script, or third-party integration is fully migrated. Some configuration can remain syntactically present but behave differently because the underlying subsystem changed.

Use this three-way comparison:

Original v6 export: the known-good source configuration and baseline.
Converted v7 configuration: what the router has after the upgrade and any automatic conversion.
Operational state: routes, neighbors, interfaces, firewall counters, tunnels, and service reachability after migration.

Compare sections individually. Do not paste the entire v6 export over the v7 configuration as a shortcut. That can reintroduce legacy syntax, duplicate objects, or settings that are no longer appropriate. Prefer targeted, reviewed changes using the v7 menu paths and syntax.

Keep a change log that records the original setting, the converted setting, the manual adjustment, and the validation result. This makes troubleshooting and later audits much easier.

Routing Changes to Review Carefully

BGP

RouterOS v7 uses a revised BGP configuration model, including templates and connection-oriented configuration. Inspect the converted BGP configuration and confirm that each peer has the intended local and remote AS, address families, local address, multihop behavior, authentication, timers, and routing policy.

Do not validate BGP only by checking that a TCP session is established. Confirm that the expected address families are negotiated, prefixes are received and advertised as intended, and import/export policy is effective. Review route filters and attributes explicitly; a peer that is Established can still exchange the wrong routes or no useful routes.

OSPF

Check OSPF instance and area configuration, router IDs, interface participation, authentication, timers, passive-interface behavior, and redistribution. Validate neighbor state and the resulting routes. A Full neighbor state is useful evidence, but it does not prove that the correct prefixes are being originated or installed.

Routing filters and policy

Routing filter syntax and the routing policy model changed between major versions. Rebuild and test filters using the v7 filter rule syntax and confirm the order and action of each rule. Pay particular attention to prefix matching, communities, route attributes, default actions, and policy direction. Never assume that an old filter expression has retained its original meaning merely because it appears in the converted configuration.

Routing tables, rules, and policy routing

Review custom routing tables and ensure that tables used for forwarding are configured appropriately for the v7 routing model. Confirm that routes are installed in the intended table and that routing rules, marks, and next-hop resolution still produce the intended path. If the router uses multiple gateways or traffic-specific routing, compare the design against MikroTik policy-based routing with different gateways.

Static routes and recursive next hops

Verify route distance, scope/target-scope behavior where used, gateway resolution, check-gateway settings, and route selection. Check that recursive routes resolve through the expected next hop and that failover behavior still works during a controlled test.

Wireless, VLAN, Firewall, NAT, and Scripts

Wireless packages and interfaces

WLAN migration depends on the router model, wireless chipset, installed packages, and supported driver family. Some devices continue to use the legacy wireless menu; others can use newer WiFi packages and menu structures. Do not assume that every legacy wireless setting is automatically translated into an equivalent new WiFi setting.

After the upgrade, confirm that radios and interfaces exist, country and regulatory settings are correct, security profiles are intact, SSIDs are broadcast, and clients can authenticate and roam as expected. Check CAPsMAN compatibility and controller/client versions where centralized wireless management is used.

Bridge VLAN filtering and switching

Validate bridge membership, VLAN filtering, tagged and untagged port membership, PVIDs, ingress filtering, and the CPU-facing bridge port. Hardware offload depends on device and switch-chip support, so confirm both forwarding and performance after migration. Use the MikroTik bridge VLAN filtering guide when reviewing tagged and untagged port behavior.

Firewall and NAT

Review firewall rules, address lists, interface lists, connection tracking, NAT rules, and any rules that depend on routing marks or interface names. Confirm that the expected counters increment and that management access remains restricted. Test outbound access, port forwarding, VPN traffic, and inter-VLAN policy from real clients. The RouterOS 7 MikroTik NAT configuration guide is a useful reference for reviewing translation behavior.

Scripts, schedulers, and automation

Search scripts for old menu paths, changed property names, assumptions about command output, and string parsing that may break in v7. Test scheduled jobs, Netwatch actions, API clients, backup jobs, and configuration-management tools individually. Do not assume that a script is healthy because it remains in the script list; execute it in a controlled test and inspect its logs and resulting state.

Post-Upgrade Validation Plan

Use a service-by-service acceptance test rather than relying on a successful reboot. At minimum, validate:

Management: WinBox, SSH, API, local console, user permissions, and management ACLs.
Interfaces: link state, negotiated speed, duplex, bonding, bridge membership, and error counters.
Layer 2: VLAN tagging, spanning tree, MAC learning, and hardware-offload status where applicable.
Layer 3: connected and static routes, routing tables, policy rules, recursive routes, and default route failover.
Dynamic routing: BGP sessions and prefixes, OSPF neighbors and LSAs, and redistribution policy.
Security: firewall and NAT behavior, IPsec, WireGuard or other tunnels, authentication, and management exposure.
Services: DHCP leases, DNS resolution, NTP synchronization, RADIUS, logging, SNMP, and monitoring alerts.
Performance: CPU, memory, throughput, latency, packet loss, queue behavior, and hardware offload.

Capture the same command outputs and test results that you recorded before the migration. Compare them rather than relying on memory. For a structured CLI workflow, see MikroTik CLI troubleshooting and diagnostic techniques.

Troubleshooting Common RouterOS v6 to v7 Migration Problems

The router boots, but routing is broken

Check route installation, routing-table membership, next-hop resolution, routing rules, and protocol policy. For BGP or OSPF, inspect both neighbor/session state and the actual prefixes received, advertised, and installed. Review conversion messages and rebuild unsupported filters instead of copying legacy expressions.

BGP is established but routes are missing

Confirm negotiated address families, input/output filters, prefix limits, remote advertisements, and whether accepted routes are eligible for installation. Check that routing filters use v7 syntax and that policy does not reject all routes unintentionally.

OSPF neighbors do not reach Full

Compare area, network type, authentication, timers, MTU, router ID, and interface participation at both ends. Verify that the correct interfaces are enabled for OSPF and that firewall rules permit the protocol on the relevant links.

Wireless interfaces disappeared or clients cannot connect

Inspect installed packages and the supported wireless driver for the hardware. Confirm whether the device should use the legacy wireless package or a newer WiFi package. Rebuild wireless configuration only after checking the exact model’s supported package and driver path.

Throughput dropped or CPU usage increased

Check interface errors, link negotiation, bridge and VLAN configuration, hardware-offload flags, firewall processing, queues, and CPU load by process. A change in forwarding path can increase CPU use even when the configuration appears similar. Compare results using the same traffic pattern and test endpoints as before the migration.

Scripts fail after the upgrade

Run the affected script manually, inspect the error, and test each changed command or property independently. Replace assumptions about old menu paths and output formatting. Avoid changing several scripts at once; make one controlled correction and verify its effect.

Remote management was lost

Use the planned out-of-band or console access. If you still have a stable management path, make only one change at a time and use Safe Mode for risky remote edits. Review MikroTik Safe Mode for remote network changes before making further changes over a fragile connection.

Rollback and Recovery Planning

Do not treat downgrade as a guaranteed undo button. RouterOS downgrade availability, package compatibility, configuration restoration, and hardware support depend on the device and versions involved. A binary backup created on one RouterOS version should not be assumed to be a portable configuration migration file for another major version or another hardware model.

Before the change, decide what conditions trigger rollback: for example, loss of critical routing, inability to restore management, failed VPN services, or unacceptable performance. Define who makes the decision and how long troubleshooting may continue during the maintenance window.

If recovery requires reinstalling RouterOS, use the documented procedure for the device. MikroTik Netinstall may be appropriate for supported recovery scenarios; prepare the correct packages and follow the device-specific process. See MikroTik Netinstall and RouterOS recovery. Keep the original v6 backup and export safely stored, and restore only to a compatible device/version after verifying the recovery plan.

Final RouterOS v6 to v7 Migration Checklist

☐ Confirm hardware, architecture, package, and target-release compatibility.
☐ Read the relevant v6 and v7 release notes and device-specific documentation.
☐ Export the v6 configuration and create a binary backup.
☐ Download backups and operational snapshots off the router.
☐ Record routing, firewall, VPN, VLAN, wireless, and service baselines.
☐ Arrange a maintenance window and reliable recovery access.
☐ Upgrade using the supported package path and verify RouterBOARD firmware.
☐ Review conversion messages and compare the v7 configuration with the v6 export.
☐ Rebuild and validate routing filters, BGP, OSPF, and custom routing tables.
☐ Test wireless, VLANs, firewall, NAT, tunnels, scripts, and automation.
☐ Run end-to-end service tests and compare performance with the baseline.
☐ Document exceptions, manual changes, and rollback decisions.

Frequently Asked Questions

Can I upgrade directly from RouterOS v6 to v7?

Many supported devices can upgrade through the normal RouterOS package process, but the correct path depends on the device, current release, and target release. Check MikroTik’s release notes and upgrade guidance before proceeding; some environments may need an intermediate maintenance release or special package handling.

Does RouterOS automatically convert the entire v6 configuration?

No. RouterOS can convert supported configuration components, but conversion is not a guarantee that every feature, policy, script, or external integration will work unchanged. Review conversion messages and validate operational behavior.

Will my BGP and OSPF configuration migrate automatically?

Some supported settings may be converted, but the v7 routing architecture and policy syntax differ. Inspect peers, address families, filters, route selection, OSPF areas, and redistribution after the upgrade. Test the actual routes, not just protocol session state.

Can I restore a RouterOS v6 backup on RouterOS v7?

Do not rely on a binary backup as a cross-major-version configuration conversion mechanism. Keep a text export for review and follow MikroTik’s documented restore and downgrade guidance for the specific device and version.

Should I upgrade all MikroTik routers at once?

For production networks, use a staged rollout. Test a representative lab device first, then a low-risk production device, and finally the remaining routers in controlled groups. This limits the impact of model-specific or configuration-specific problems.

How long should I keep the v6 backup?

Keep the original export and binary backup for as long as your rollback and audit policy requires. Store them securely, label them with the device identity and software version, and verify that the files are downloadable before the maintenance window ends.

Conclusion

A successful RouterOS v6 to v7 migration is measured by preserved network behavior, not simply by a successful reboot. Back up and document the v6 router, upgrade through a supported path, review automatic conversion, manually validate routing and other changed subsystems, and test every critical service against a recorded baseline. A staged migration with a tested recovery plan is the safest way to adopt RouterOS v7 without turning a software upgrade into an avoidable network outage.

Check our list of MikroTik guides