MikroTik Will Delete Everything. It’s Still the Right Choice.

Let me tell you about the 24-hour activation window.

When you install RouterOS on new hardware, you have 24 hours to activate your license. If you don’t complete activation in that window, MikroTik clears the disk and reboots. Your configuration is gone. Your work is gone. Everything you did in those 24 hours is gone. This isn’t a warning. It’s not a grace period extension. It’s an active penalty for not completing the process on their timeline.

I knew this going in. It was on the list of constraints that had to be weighed. MikroTik still cleared the bar. The bar was higher because of this, not lower.

---

What the Licensing Process Actually Looks Like

RouterOS licenses are tied to hardware IDs. If your hardware fails and you need to reprovision, you’re entitled to one re-issue for ten dollars, but it’s a manual process through their support team, and their support team operates on their schedule, not yours.

I found this out on a Friday night.

Hardware had failed. I had a legitimate claim to a replacement license. I had the license. What I didn’t have was any control over when MikroTik support would respond, and the 24-hour window was running. The practical answer, the one that gets you moving, is to just buy another license. Technically you shouldn’t have to. Practically, if you need it working before support responds, that’s your option.

This isn’t a support team failing to do their job. It’s the natural consequence of a licensing model built around manual processes and hardware binding in a world that increasingly doesn’t work that way. The support team will eventually respond. The 24-hour clock doesn’t care.

Add to this that a RouterOS config reset isn’t what you’d call pristine. Certain state persists in ways you don’t expect. If your automation assumes a clean slate and the slate isn’t clean, you find out the hard way. Building your provisioning process to account for this is the right call. Not accounting for it is how you end up debugging problems that feel like your fault but trace back to state you didn’t know was there.

---

Why It’s Still the Right Choice

Every one of those constraints was known before the hardware was purchased. The activation window. The support dependency. The hardware-bound licensing. The imperfect reset. They were on the list. MikroTik still cleared the bar.

The reason comes down to what’s on the other side of the friction.

MikroTik built their reputation on software-driven networking with commodity compute resources. RouterOS delivers routing, firewall, VLAN management, and API-driven configuration with a consistency and reliability that’s earned real credibility in the industry. The API-driven configuration model is good. Once the licensing process is behind you and the automation is running, the operational experience is solid. The feature set doesn’t have asterisks. The reliability isn’t conditional.

That’s not a close call. Software-driven networking on a standard server chassis, with an API that integrates cleanly with Ansible, running on hardware where IPMI provides out-of-band access regardless of RouterOS state. That combination serves the platform’s goals in a way that alternatives don’t match.

The x86 chassis argument deserves a moment. Replacing the hardware doesn’t require specific models, ASICs, or line cards. A modest CPU and more than enough RAM is easy to source. In this case it’s a Dell R630 with dual 16-core CPUs, 64GB of RAM I had sitting around, and dual 40GbE NICs that were already in the parts drawer. Four routed ports. 160Gbps of port capacity. Dirt cheap compared to dedicated routing hardware. The same chassis gives you IPMI as standard infrastructure rather than a vendor-specific add-on, which matters for exactly the reasons covered elsewhere. You get more capacity and capability out of a standard server than you’d expect, with all the operational advantages of hardware you already know how to manage.

This is what the open-source default actually means in practice. The default isn’t “free software only.” It’s “anything that adds thinking to your worst day gets a hard look.” MikroTik adds thinking to specific days: the install day, the licensing day, the hardware failure day. It doesn’t add thinking to the operating days, which are most of them. That calculus clears the bar.

---

What This Means for Automation

The licensing constraints have a direct implication for how automation gets built.

First: the 24-hour window means your provisioning process needs to be fast and complete. You can’t defer activation while you figure out the rest of the configuration. The activation is the first thing, not the last thing, and your tooling needs to treat it that way.

Second: the imperfect reset means your automation needs to account for pre-existing state. Don’t assume clean. Verify. Build idempotency around the actual state of the device, not the theoretical state after a reset.

Third: the support dependency means you need a contingency for hardware failure that doesn’t rely on a timely support response. Budget for a spare license. Or accept that hardware failure events may require purchasing a new license while the re-provision request works through the queue. Either is a reasonable choice. Neither should be a surprise.

These aren’t workarounds. They’re the operational reality of the tool you chose, and they belong in the automation design from the start. The ADR documents the decision. The automation reflects the constraints. That’s how you avoid discovering them at 11pm when something has gone wrong and you thought you had more options than you do.

---

The Honest Version of Tooling Evaluation

Most tooling evaluations optimize for the best case. How does it work when everything goes right? How fast is the onboarding? What does the happy path look like?

The honest version asks different questions. What happens when it goes wrong? What are you dependent on that you don’t control? What are the active penalties for getting the process wrong? What does recovery look like when the vendor isn’t available?

MikroTik fails the happy path evaluation on several counts. The onboarding friction is real. The support dependency is real. The 24-hour penalty is punitive.

MikroTik passes the honest evaluation because the operational experience after onboarding is solid, the feature set is differentiated, and the constraints are bounded and front-loaded. You pay the licensing cost once. You operate the tool every day.

Every tool that made the cut on this platform passed the same evaluation. Not “is the happy path good” but “what am I actually signing up for, and does the value on the other side justify it.” MikroTik does. The disk wipe and all.