Meraki licensing: Co-Term vs Subscription — which model fits?

Plan additional licences: Use the co-term calculator to simulate the new term. Procurement also depends on which licensing model carries the organisation: it determines when you renew, which networks share a deadline, and what happens after expiry and the grace period. And it cannot be swapped at will.

Three models, two of them still a choice

Meraki documents three licensing models: subscription, co-termination and per-device licensing (PDL). The third is effectively closed — it is no longer available to customers who would like to move to it in regions where subscription licensing is available. Existing PDL organisations carry on, but a fresh decision comes down to subscription or co-termination.

Co-termination: one date for everything

Co-termination brings every licence in an organisation onto the same expiration date. Meraki describes the arithmetic openly: all active licences are averaged together and divided by the licence limit count of devices in the organisation. The result is the remaining term — for every device at once.

For a branch estate that grows over years, that is the decisive property: additional licences for a new site can change the shared date. This is not a flaw but the purpose of the model — one deadline, one renewal, one invoice. It also means the renewal date of a growing organisation keeps moving and cannot simply be pinned to a fixed month.

Co-term licence calculator: simulate the shared date

Meraki's own licence calculator sits in the dashboard behind the login — useful in operation, out of reach at quoting time. For the order of magnitude before a purchase, the documented arithmetic is enough, and that is exactly what this calculator implements: existing positions with their remaining days, new licences with their full term.

Subscription: term per network, not per organisation

Subscription moves licensing from the organisation down to the network level. A network binds to exactly one subscription at a time; several networks in the same organisation can share a subscription. A separate site therefore does not automatically have a separate contract deadline. Different MX tiers are possible within one organisation under different subscriptions.

• Terms of 36 to 84 months, with start and end dates you determine — the deadline follows your contract year, not the accident of the order in which keys were claimed.
• Billing monthly, quarterly, annually or prepaid rather than prepaid only.
• Feature tiers can be upgraded without rebuilding the licence structure.
• Available globally except in Russia and Belarus. Cisco lists local purchasing for India and Canada, but claiming and management currently use meraki.com, not meraki.in or meraki.ca.

Essentials vs Advantage: the tier question

Within subscription licensing the second decision follows: the feature tier — Essentials or Advantage, chosen per network and product class (wireless, switching, security/SD-WAN). The vocabulary belongs to subscription; under co-termination the MX editions are instead called Enterprise, Advanced Security and Secure SD-WAN Plus. A quote that mixes the two naming worlds compares apples with pears.

The MX shows what the tier separates: Advantage bundles, among other things, the ThousandEyes integration including internet outage analysis, Adaptive Policy (SGT assignment), SD-Internet steering, and web app, WAN and VoIP health — Essentials carries the core feature set. One exception is documented explicitly: the vMX does not support the Advantage tier; a network with a claimed vMX cannot set it for that product class.

• Tier per network and product class — headquarters can run Advantage while a branch gets by on Essentials, in the same organisation.
• Upgrade without rebuild: moving from Essentials to Advantage is a documented upgrade path, not a new licensing project.
• A 30-day Advantage trial per network and product class, free of charge. Afterwards the class automatically drops back to Essentials — traffic and basic management continue, only the Advantage features end. The same class can be retried after 45 days.

What happens at expiry — where the similarity ends

Both models grant a 30-day grace period on non-compliance. After that they behave fundamentally differently, and that difference is the real reason to choose the model deliberately.

Under co-termination and PDL the affected hardware becomes non-operational: it can no longer be configured, and the network products no longer allow traffic to pass to the internet. A missed date is an outage.

Under subscription the network keeps running. Organisations that are both out of compliance and past the 30-day grace period continue to function and forward data traffic — Meraki sets this explicitly against the previous model's shutdown procedure. Automated enforcement instead withdraws manageability from the non-compliant devices, on a last-in, first-out basis.

Plan licence renewal and hardware lifecycle together

Licence expiry, end-of-sale (EOS) and end-of-support (EOST) are separate dates. EOS is the last ordering date for a product; EOST ends its affirmative vendor support. An installed device reaching EOS does not simultaneously lose its licence or automatically shut down. Renewing a licence likewise does not extend EOST. Use the specific product notice for the hardware plan, rather than an assumed service life.

1. 01

   Keep a planning record with a named owner

   Record organisation, networks, licensing model, subscription binding, product class and tier, hardware types and quantities, expiry, the EOS/EOST source, replacement date and owners. This is your planning register; it does not assume an automatic combined lifecycle report in Dashboard.

2. 02

   Set quantities and replacement scope before quoting

   For co-termination, reconcile deployed counts with licence limits by device type. A key claimed as a renewal replaces the earlier limits; missing items can leave the organisation out of compliance. For subscription, work from the networks actually bound to it and their required quantities.

3. 03

   Give each lead time an outcome

   As an internal planning rule, review inventory and hardware plans 120 days ahead, settle the quote and budget 90 days ahead, and complete renewal 30 days ahead. These are suggested working intervals, not Cisco deadlines. Procurement and migration may need longer.

4. 04

   Keep evidence of completion

   After renewal, reconcile the actual term, quantities and bindings with the order. Record the confirmed values and review date, then schedule the next deadline. Hardware replacement has its own work order and acceptance checks.

Filled example: three sites, two subscriptions

The resulting decision: SUB-A covers 18 APs across two networks, SUB-B another four. The proposed SUB-A renewal through 31 March 2030 needs a plan to replace generation A before the end of 2028; a valid licence would not establish hardware support through the contract end. Under co-termination the calculation would differ: all licences in this organisation would share one date. New licence positions for expansion can be modelled in the calculator; an order still depends on the actual licence data.

What follows for procurement

1. 01

   Decide the model before the hardware

   Because subscription keys cannot be claimed in an active legacy organisation, and the move from PDL to subscription is permanent, this is not a question for later.

2. 02

   Model the growth, not the current state

   Under co-termination additional licence positions affect the shared date. If you will have twice the sites in three years, you should know where the deadline lands then.

3. 03

   Put the expiry behaviour in writing

   Whether traffic stops or management stops at expiry belongs in the quote and in the operations manual — not in one person's memory.

4. 04

   Plan lead time, not grace

   The 30 days are a safety net, not a process. A renewal that only starts when the warning appears was scheduled too late.

How we run licence terms in day-to-day operations — consolidated dates, planned renewals, lead time before every deadline — is described under Cisco Meraki. The structure that comes with it once many sites are involved — templates, claiming and the order of work — is covered in the piece on the Meraki multi-site rollout.