Menu
|
Menu
If you run a Cisco Meraki network and your organization handles Controlled Unclassified Information (CUI), the next 12 months are going to require more planning than most teams have done.
Cisco Meraki for Government received FedRAMP Moderate authorization on February 18, 2025. That same year, the Department of Defense finalized the CMMC Acquisition Rule, which puts Level 2 certification requirements in DoD solicitations starting Phase 2 on November 10, 2026. The two events are not coincidentally timed. Meraki for Government is now the operational home for Meraki environments in scope for CMMC.
This playbook walks through what’s actually involved in moving from Commercial Meraki (dashboard.meraki.com) to Meraki for Government (dashboard.gov-meraki.com), what catches teams off guard, and how to scope the work realistically.
Meraki migrations between organizations are not new. Org consolidations, splits, and tenant transfers have been a routine engineering exercise for years. The Cisco Network Portability API has made the mechanics smoother.
Commercial-to-GovCloud is different from a typical org migration in five specific ways:
One-way license conversion. Cisco’s policy is that licenses converted from the Commercial dashboard to the GovCloud dashboard are not reversible. There is no path back. This changes the risk profile of the work. Configuration backup is no longer just operational hygiene, it is the only rollback you have, and it operates at the config layer, not the license layer.
Cisco support gating. License conversion does not happen through a self-serve portal. It happens through a Cisco support case. The case typically runs two to four weeks. The case has to be open and progressing during your migration window, not after. Teams that try to schedule the cutover before the conversion completes lose a weekend.
Hardware compatibility constraints. GovCloud does not support every device family or every SKU within a family. MS120 has limited TAA compliance per Cisco’s own documentation. MX67C-HW-WW (the MX67 with integrated cellular) and MX68CW-HW-WW (with cellular and Wi-Fi) are not currently supported. If you have these in production, they don’t migrate as-is. The replacement strategy is typically MX67 or MX68 plus a standalone MG cellular gateway, plus an MR access point if applicable.
FIPS firmware requirement. All devices in Meraki for Government run FIPS-validated firmware. This is not optional. If your Commercial environment is running standard (non-FIPS) firmware today, the migration includes a firmware staging step that has to happen pre-cutover. Some configurations don’t survive the firmware switch without explicit re-configuration. Plan for this.
Feature parity is asymmetric. GovCloud has added significant coverage since the February 2025 authorization, including MV smart cameras, MG cellular gateways, advanced security features (IDS/IPS, content filtering, geography-based firewall rules), and Enterprise Agreement support. It still differs from Commercial in places. Some features that exist in Commercial (Adaptive Policy, certain Cisco Umbrella integrations, specific MT sensor types) need per-release validation in GovCloud before you commit.
The combination of these five items is what makes the migration a project, not a configuration change.
Before scoping cost, time, or scope, do an inventory check against the current GovCloud support matrix.
You need to know:
The output of the compatibility check is a green / yellow / red flag per device family and per critical feature. Green moves. Yellow needs per-SKU validation with Cisco partner support. Red does not migrate as-is.
The three SKUs that flag red most often:
The most common feature flag is Auto VPN. Auto VPN is functionally available on Commercial Meraki, but it is not FIPS-validated outside the GovCloud region. NIST 800-171 control SC.L2-3.13.11 calls for FIPS-validated cryptography for CUI in transit. If your CUI crosses sites today on Commercial Meraki Auto VPN, that is a documented control gap a C3PAO assessor will see.
The compatibility check is also the right moment to address Systems Manager. Cisco announced end of sale for Meraki Systems Manager in December 2025. New 1-year and 3-year licenses are available through June 3, 2026. If you use SM today, plan a parallel MDM migration. Do not bundle it into the GovCloud cutover.
There is no universally correct migration window. The right window depends on three variables:
Change window availability. Some DIB contractors have a single available change window per quarter. Others have weekly maintenance windows. The cadence determines how aggressively the project can phase work. Single-window environments need more pre-cutover validation; the cutover itself is bigger and more concentrated.
Site count and geography. Multi-site environments with split time zones add coordination cost. Cutting over 30 sites across four time zones in one window is not impossible, but it requires a war-room cutover and more engineers on standby. Phased cutovers (a wave per weekend) reduce risk but extend the calendar.
Cisco support case timing. This is the variable most teams underestimate. The license conversion case does not move at your project schedule. Plan a four-week buffer between case open and cutover, and have a contingency plan if Cisco needs additional information mid-case.
A realistic timeline for a 25-site, 350-device environment:
| Week | Workstream |
|---|---|
| 1 | Inventory verified. Cisco support case opened. Compatibility matrix mapped. Migration runbook drafted. |
| 2 | FIPS firmware staging in test environment. GovCloud target org configured. Backup of source org. License conversion case progressing. |
| 3 | Dry run on a non-production network. Adjustments to runbook. Cisco case nearing completion. |
| 4 | Production cutover during change window. Auto VPN, IDS/IPS, policy validation. License conversion confirmed. |
| 5-8 | Post-cutover triage. Documentation pack delivered. Optional Safeguard deployment for ongoing evidence. |
Smaller environments compress this. Larger environments stretch it.
A migration that closes without an audit-ready documentation pack is incomplete for any contractor in CMMC scope.
The minimum pack includes:
If your migration partner doesn’t produce this on day one of project closeout, that is a process gap to surface before signing the SOW, not after.
For organizations on the Migrate Plus track, the pack expands to include ongoing configuration change history (typically via a configuration management product like Safeguard), drift detection logs, and additional Configuration Management control mappings (CM.L2-3.4.1 through CM.L2-3.4.9).
This is worth saying clearly because there is vendor confusion in the market.
FedRAMP authorization is granted to a cloud service provider. It tells the federal government that Cisco’s Meraki for Government platform meets the FedRAMP Moderate baseline of controls. It does not tell anyone that your organization is CMMC certified.
What you inherit from Cisco’s FedRAMP authorization:
What you still need to do yourself:
This is roughly 100 of the 110 CMMC Level 2 practices. The network migration helps you on the ten or so that touch network cryptography and configuration. Your C3PAO assesses the rest, and your remediation work touches everything.
If a vendor sells the GovCloud migration as a CMMC certification shortcut, get a different vendor.
After running migrations across DIB customer environments, the same five mistakes show up.
Skipping the dry run. Production cutover without a dry run on a non-production network turns small surprises into outages. Always dry-run.
Underestimating the Cisco support case. Teams plan their migration calendar from cutover backwards and discover the support case hasn’t progressed enough. Open the case in week one and treat it as a project dependency.
Bundling Systems Manager into the same project. SM is on a different lifecycle. Bundling adds project risk for no compliance benefit. Keep it separate.
Negotiating away the post-cutover documentation pack. This is the single most valuable artifact for the customer’s audit. It is the work the migration partner uniquely provides. Cutting it is short-term cost saving and long-term audit risk.
Assuming feature parity. GovCloud has expanded, but it still differs. Always validate the specific features the customer depends on against current Cisco documentation, not against a marketing summary.
The well-run Commercial-to-GovCloud migrations share four characteristics.
They start with a written runbook scoped to the customer’s actual environment, not a generic template.
They own the Cisco support case directly rather than asking the customer’s team to chase it.
They produce the documentation pack as a deliverable, not as an afterthought.
They scope what is in and what is out, in writing, before the SOW.
If the partner you’re evaluating doesn’t operate this way, find a different partner.
If you’re scoping a Commercial-to-GovCloud move and you don’t yet know your timeline:
The contractors who get ahead of this in 2026 are bidding on Phase 2 contracts in 2027 from a position of strength. The contractors who wait are competing on price for the contracts they can still bid on.
Boundless migrates Meraki networks and produces audit-ready configuration evidence for DIB contractors preparing for CMMC Level 2. We do not perform C3PAO assessments. We work alongside your C3PAO partner, or introduce you to one if you don’t have one yet.
1207 Delaware Ave #552, Wilmington, Delaware 19806
Americas: +1 (347) 464 6510 - EMEA: +33 (0) 181 22 12 80
