MikroTik or Cisco for a 30-person branch?

For a 30-person branch, I usually choose MikroTik when the network is simple, the company will maintain a reference configuration, and a configured spare router sits on a shelf. Cisco makes sense when the branch belongs to a corporate WAN, the security team requires consistent policies and logs, and the support contract must provide a clear escalation path.

Employee count by itself tells you almost nothing. An accounting office that uses cloud applications over one internet connection puts less load on a router than a small site with IP telephony, cameras, two providers, a site-to-site VPN, and a local server. Compare specific architectures, licenses, and recovery procedures, not two logos.

The failure scenario matters more than the brand

A modern MikroTik is enough for a typical branch when its actual job is NAT, VLANs, a firewall, two internet links, voice prioritization, and one or more VPN tunnels. The RB5009UG+S+IN, for example, has seven gigabit ports, a 2.5 Gbps port, and a 10 Gbps SFP+ cage. It is a useful reference for the device class, not a finished specification: an LTE modem, PoE for access points, and the required optical modules may change the model.

Do not buy a router using a rule such as one user equals a certain number of megabits. First record the peak speed of each WAN, the number and type of VPNs, expected traffic between VLANs, application inspection needs, IP telephony, and acceptable downtime. Performance with encryption and complex rules is usually lower than the attractive number in the first row of a data sheet.

The same Cisco decision does not begin with office size. If headquarters already uses Cisco Catalyst SD-WAN, centralized management, shared templates, and corporate support, a branch router extends that system. Without that system, a Catalyst 8200 can become an expensive way to do work that a simpler device can handle.

A third option is often incorrectly grouped with conventional Cisco IOS XE: Cisco Meraki. Cloud management simplifies routine operation across several sites, but it adds an ongoing licensing dependency. The statement "we are buying Cisco" is therefore not enough for a budget or a technical decision.

Cisco comes with different cost models

Cisco Catalyst and Cisco Meraki cannot be compared with MikroTik in a single row. Their management, licensing, and support models differ even though the same name appears on the case.

Catalyst 8200 runs IOS XE and fits a branch that needs advanced routing, segmentation, corporate WAN integration, and an operating model familiar to a large network team. In the official Catalyst 8200 data sheet, Cisco states directly that the platforms are offered only with a Cisco DNA Software subscription. The Network Essentials or Network Advantage tier, subscription term, and extra features affect the order. A bare appliance without itemized licenses is not the full solution price.

Meraki MX is managed through a cloud dashboard and requires a cloud license to manage every device. Meraki documentation describes Subscription and Co-Termination models, while Per-Device remains available to existing customers. Under Subscription, the device continues to pass traffic after the grace period ends, but management is disabled. Under Co-Term, an overdue license can shut down the organization after the grace period. The old claim that "a Meraki license expires and the network always switches off immediately" is no longer accurate, but you still cannot ignore the licensing model.

A MikroTik RouterBOARD has its RouterOS license preinstalled. MikroTik's manual says the licenses never expire and include unlimited software upgrades. That removes the annual charge for the right to manage the router, but it does not buy an engineer, guaranteed replacement, or help during a difficult outage. Free updates and paid support solve different problems.

A license is not a support contract

A license term answers whether you may use a feature or manage a device. A service contract answers a different question: who accepts the case, helps isolate the fault, and replaces hardware within an agreed period.

Cisco access to TAC and advanced hardware replacement depends on the service coverage purchased. In its Smart Net Total Care description, Cisco states separately that a customer does not receive advance replacement without an RMA service level. A supplier's phrase "Cisco support is included" means nothing without a contract number, service level, covered serial numbers, and confirmation that the level is available at the branch address.

A MikroTik buyer usually relies on the seller's warranty, a local integrator, documentation, and in-house skill. MikroTik's official catalog lists distributors and resellers in Almaty and Astana, but a company appearing in the catalog does not mean the required RB5009 or power supply is in stock in your city. It certainly does not promise a four-hour replacement in a regional center.

Ask each bidder to answer four questions separately: who takes a call at night, who can access the configuration, where the spare device is stored, and who will physically travel to the branch. If the answer to all four is one administrator's name, the network has no support, however impressive the contract title sounds.

A five-year estimate must include labor and downtime

Total cost includes procurement, mandatory subscriptions, implementation, annual operations, spare parts, and the expected cost of downtime. Counting only the appliance particularly favors the offer whose other costs will appear after selection.

Use a single worksheet for the same period, such as five years:

For each cost item, fix the same scope. Hardware includes the router, power supplies, transceivers, and a spare kit. For Cisco, list the chassis and modules separately because the price of an empty appliance rarely matches the price of a working node.

The license row for MikroTik RouterBOARD normally has no annual RouterOS renewal. For Cisco Catalyst, enter the network tier, Cisco DNA term, and required add-ons. For Meraki, specify the cloud licensing model, feature tier, and expiration date.

Implementation includes the design, configuration template, circuit migration, VPN verification, failure test, and documentation. If one offer includes this work and another only promises to configure the internet, the comparison is already distorted.

Annual operations include updates, backups, monitoring, log review, account administration, and engineering time. For subscription products, add term tracking and license renewals.

The cost of a failure depends on the spare device, logistics, travel time, and service agreement. The same router produces a different outcome when a replacement is available today in Almaty but takes several days to reach a remote branch.

The formula for an internal calculation is simple:

TCO_5 = CAPEX + LICENSES_5 + IMPLEMENTATION + OPERATIONS_5 + SPARES + DOWNTIME_RISK
DOWNTIME_RISK = INCIDENTS_PER_YEAR × HOURS_PER_INCIDENT × COST_PER_HOUR × 5

Do not insert a made-up failure probability. Use your own incident history or calculate several cases: one two-hour outage over five years, one outage a year, and a failure lasting a full working day. For an accounting office, the hourly cost may equal the lost time of 30 employees. For a checkout, warehouse, or medical site, it also includes stopped operations and specialist travel.

Count labor honestly as well. A cheap router that requires a costly engineer to adjust it manually every month can lose to a managed platform. A subscription does not make a network self-sufficient, though: someone must still check updates, policy changes, backups, and alerts.

Check Kazakhstan availability by exact SKU

The phrase "the brand is available in Kazakhstan" does not tell you when the branch will recover from a failure. The commercial offer should state the exact SKU, power supply version, compatible transceivers, lead time, spare location, and warranty replacement procedure.

Selection and logistics are usually broader in Almaty and Astana than in a remote district center. I therefore check the supplier's warehouse and the last mile. Tomorrow's courier delivery is useless if nobody can transfer the configuration, connect two WANs, and test telephony tonight.

For MikroTik, a practical way to reduce downtime is to buy a second identical device. Its price often makes it possible to keep a cold spare near the branch. The spare needs a compatible RouterOS version, a configuration export, and clear cabling instructions. An unopened box without configuration only reduces delivery time.

For Cisco, you can buy a spare or rely on a replacement agreement. The second route works when the contract names the address, coverage hours, and actual delivery time. Cisco warns that advance replacement options depend on the purchased RMA service level and availability. Verify this before ordering, not during an outage.

Do not accept a model replacement described only as "an equivalent" without testing. A different revision may need another image, license, module, or configuration syntax. Each site needs a list of approved substitutes rather than faith in the duty engineer's ingenuity.

Lab testing costs less than a specification error

Before signing the acceptance certificate, both platforms should pass the same loads and failures. A demonstration of an empty router with one laptop tells you nothing about a branch: firewall rules, encryption, queues, and logging change device behavior. The test confirms the selected model and configuration rather than staging a brand contest.

Build the lab with the same circuit types used at the site. If the primary provider assigns an address by DHCP while the backup uses PPPoE or LTE, reproduce that exact combination. Connect test telephony, several VLANs, and a VPN to headquarters. A traffic generator helps, but even copying a large file through the tunnel during a call will reveal prioritization errors that remain invisible on an idle network.

Record the healthy state before causing a failure. DNS, time synchronization, access to approved corporate systems, blocked unwanted traffic between VLANs, and log forwarding must all work. Check the time on the router and log server. If their clocks differ, a later investigation becomes an attempt to guess the order of events.

Then disconnect the primary WAN physically. The route should move to the backup link without an administrator logging in. Test more than a website: check VPN reestablishment, an outgoing call, access to a corporate application, and return to the main circuit. Some designs detect loss of link well but miss the case where the interface remains up while the internet beyond the provider's gateway is unavailable. That design needs a remote health target and careful thresholds, or a brief packet loss will keep moving routes.

Agree on acceptable failover time. Tens of seconds may be fine for browser work, but an active call or checkout application session can still drop when the public address changes. A router cannot preserve every session while switching between independent providers. If the business requires a particular application to remain uninterrupted, that is a separate architecture problem, not a failover checkbox.

Test the limits of the backup circuit. LTE or a cheaper second connection may offer lower speed, a different MTU, and no inbound connections. Essential systems should receive priority on the backup, while backups and updates can wait. Otherwise, the first large file consumes the circuit and employees conclude that failover failed.

The next test concerns configuration. Save the current version, introduce a prepared faulty rule, and follow the rollback instructions. The error must be safe and used only in an isolated lab. The goal is to confirm that a second engineer can find the right file, understand the version, and restore access within the agreed time. Acceptance is incomplete when rollback depends on the project author's memory.

Test software upgrades before the branch as well. Confirm that the selected release supports every module and VPN algorithm, save the configuration, update the spare appliance first, and repeat the main checks. Do not deploy a fresh release merely because the dashboard offers it. Read the release notes and known limitations, then let the version run on the spare or in the lab.

For Cisco Catalyst, add license registration, account permissions, and support access to acceptance. An engineer should see which entitlements are active, when the subscription expires, and who may open a case. For Meraki, verify the organization owners, licensing model, and that at least two corporate administrators can see the site configuration.

For MikroTik, perform a recovery on the spare device. Importing a readable export may require adjustments for interfaces and the hardware model, while a binary backup fits an identical appliance better. A spare of the same model is therefore simpler and safer. After recovery, compare rules, addresses, routes, and VPNs, then send real traffic.

Document the lab result in a protocol containing the firmware version, control configuration, measured failover time, and deviations. Do not write a vague "works normally." An acceptance criterion should let another engineer repeat the action and obtain the same result.

This test sometimes proves that the cheaper appliance fully meets the need. Sometimes it finds insufficient performance, a missing license, or a missing interface before the hardware goes to another city. In either case, the lab has paid for itself because changing a specification on a desk is easier than changing it after a branch outage.

Monitor the design separately. The branch must expose the state of both WANs, VPN availability, processor load, memory or storage consumption, temperature where a sensor exists, and evidence of a reboot. Alerts should reach a corporate channel and include the site name, time, and observed symptom. A message saying "node unavailable" without an address or history gives the duty engineer little help.

Do not confuse a successful ping with a healthy service. A router may answer on its management address while DNS, a tunnel, or an application route is already broken. Important services need checks from the branch viewpoint: name resolution, a connection to the required port, and, where safe, a simple application request. MikroTik and Cisco need these checks equally.

Finally, photograph the lab cabling before shipping and put the same labels on the diagram and cables. A remote employee should be able to locate WAN1, WAN2, LAN, and spare power over the phone without pulling cables one at a time. This small task cuts recovery time more than another page of general network description.

The technical owner and a business representative sign the protocol. The first confirms the configuration and recovery, while the second accepts the agreed downtime and backup circuit limits. Expectations then become part of the design: nobody promises an uninterrupted video call where the architecture allows a short break during provider failover.

MikroTik requires configuration discipline

RouterOS gives engineers considerable freedom, which is exactly why two administrators can build two entirely different networks. One uses bridge VLAN filtering, another assigns VLANs across interfaces, and a third exposes management services on the wrong side. The device does not force the team to follow a shared design.

The most dangerous configuration is not necessarily complicated. I have seen branches where a new engineer feared changing rules because their names looked like rule1 and temp, the addressing scheme lived in a chat thread, and the latest backup existed only on a former employee's laptop. The router kept running, but every change became a gamble.

A minimum MikroTik handover pack should contain an export without secrets, an encrypted backup, a port diagram, a VLAN table, a VPN list, management access rules, and a tested recovery procedure. These commands produce two different artifacts:

/export hide-sensitive file=branch-30-export
/system backup save name=branch-30-backup password="LONG_RANDOM_PASSWORD"
/file print detail where name~"branch-30"

The export creates a readable .rsc file that is convenient to review and migrate with allowances for model and version. Backup creates a binary .backup file that helps restore a compatible device quickly. They are not interchangeable. After every material change, store both files in a corporate repository with access control, not in an administrator's personal folder.

Cisco IOS XE does not eliminate complexity. Its CLI is consistent and well documented, but an advanced platform offers more ways to solve the same problem. Its advantage appears when the team already has standards, automation, and suitably trained people. Buying an expensive appliance without that system gives you complexity without the return.

Meraki lowers the barrier for routine operations through its dashboard, but a simple interface does not replace a network design. A wrong VLAN, an overly broad rule, or an incorrect route breaks access regardless of how polished the form looks.

Requirements, not headcount, justify Cisco

Consider Cisco first when the branch must join an existing Cisco architecture, use centralized SD-WAN policies, support complex dynamic routing, or receive support through a corporate contract. In that environment, another platform creates more work than its price saves.

A security requirement must also be specific. The phrase "we need a Cisco firewall" does not say whether the site needs stateful filtering, IPS, URL filtering, application analysis, or integration with a cloud security service. In the Catalyst 8200 data sheet, some security capabilities depend on the model and licenses. Request a list of included functions by SKU and verify it with a test case.

MikroTik is more sensible when the branch uses clear VLANs, standard IPsec or WireGuard, two providers, and a basic firewall, and the central team can support RouterOS. With that set of requirements, there is no reason to buy a large corporate system for the name on the case.

Meraki suits a distributed network where a small team wants consistent site management and accepts recurring payments. First, however, record the licensing model and expiration behavior. Meraki documentation distinguishes disabled management under Subscription from the harsher consequences of Co-Term, so another organization's old experience may mislead you.

If the requirements still say only "the internet must work," do not choose a brand. Approve the VLANs, permitted traffic between them, VPN, WAN redundancy, logging, monitoring, and acceptable downtime first. Extra capabilities and missing functions will then become visible without a supplier presentation.

An administrator's departure tests network maturity

A network is ready for an administrator change when another engineer can obtain legitimate access, understand the diagram, and recover the branch without calling the former employee. The router brand neither prevents nor guarantees that result.

Corporate accounts should control access. Remove personal addresses from cloud dashboards, licensing portals, and support contacts. Assign at least two owners, enable multifactor authentication where available, and store emergency access according to company procedure. A password on paper in the rack and a single cloud administrator are equally poor controls.

Documentation must answer the duty engineer's questions, not the project author's. They need the connection diagram, management addresses, providers and contract numbers, port mapping, VLANs and subnets, routes, VPN peers, license terms, backup location, and rollback procedure. Every change records the date, author, reason, and test result.

Run a replacement drill. Disconnect the main router during an approved window, give the instructions to an engineer who did not configure the site, and measure the time until internet, VPN, and telephony return. The test quickly exposes a missing module, an old backup, an unknown password, or an unlabeled cable. It is more useful than another document nobody has opened.

A Meraki cloud dashboard can make visibility easier to transfer, while corporate Cisco templates reduce configuration variation. Templates, exports, and automation can bring MikroTik to the same operational standard. In every case, the process determines the result, not the marketing name of a feature.

The choice for a typical branch

For an independent 30-person branch with two providers, several VLANs, a VPN to headquarters, and no corporate Cisco SD-WAN, I would choose a suitably sized MikroTik, often in the RB5009 class, plus a second identical appliance. I would spend the budget difference on design, monitoring, cable labels, documentation, and a recovery test. Without that work, hardware savings quickly become fictional.

I would choose Cisco Catalyst when the central network already runs Cisco, its routing and segmentation features are required, and the organization buys TAC and replacement with an appropriate service time. I would consider Meraki separately when cloud management matters more than local configuration flexibility and finance accepts recurring licensing.

Before procurement, ask suppliers for the same deliverables:

1. A specification with SKUs, licenses, and five-year terms.
2. A branch diagram and an access matrix between VLANs.
3. A migration plan, WAN failure test, and VPN acceptance criteria.
4. A support procedure for the specific city and a hardware replacement model.
5. A complete handover pack with access, configurations, backups, and recovery instructions.

If the company has no network team, commission these deliverables from an integrator and accept them separately from the boxes. GSE.kz works as a system integrator independent of a single vendor and states that it provides round-the-clock technical support through a service network across Kazakhstan, so its role can be to design and supply the agreed solution and define responsibility for ongoing service.

Do not sign an offer where MikroTik is priced as one appliance while Cisco includes five-year licenses and support, or the other way around. Equalize the term, functions, and recovery time. The choice then usually becomes dull and obvious, which is exactly how a branch router decision should be.