Meraki Org Consolidation Checklist: How to Merge Organizations Without Losing Configs

April 4, 2026
Blog
The Boundless Crew

You have five Meraki orgs. You need two. Maybe one.

The reasons are always similar: an acquisition brought in duplicate orgs, a previous MSP created orgs you now manage directly, or your environment grew organically and now you’re paying for licensing complexity that shouldn’t exist.

Meraki doesn’t have a “merge orgs” button. Consolidation is a multi-step process that involves moving devices between organizations, which means unclaiming from the source org, reclaiming into the target org, and reconfiguring. If you don’t plan carefully, you lose config history, break licensing, and create downtime.

Here’s the checklist we use after dozens of org consolidation projects.

Before You Start: The 5 Things That Break

Before diving into the checklist, understand what’s at risk. These are the items that catch people off guard during consolidation:

1. Config history doesn’t transfer. When you unclaim a device from Org A and reclaim it in Org B, the config history from Org A is gone. Dashboard change logs, API call history, and any org-scoped reporting start fresh in the new org. If you need historical data for compliance or audit purposes, export or back it up before the move.

2. Network names and structures are org-scoped. You can’t “move” a network between orgs. You recreate the network in the target org and reconfigure it. Templates, group policies, and network-level settings need to be rebuilt.

3. Licensing doesn’t automatically follow devices. If Org A has a co-term license pool and Org B has an Enterprise Agreement, moving a device from A to B doesn’t move its license. You need to coordinate licensing transfers with Cisco or your channel partner separately from the device migration.

4. API keys and integrations break. Any third-party integration that uses org-scoped API keys will stop working when the source org is decommissioned. Webhooks, SNMP destinations, syslog servers, and SAML configurations are all org-scoped.

5. Admin access needs rebuilding. Org admins don’t transfer. You need to set up admin accounts and permissions in the target org before migration, not after.

Phase 1: Discovery and Planning

Inventory Everything

For each org in scope, document:

Total device count by product type (MR, MS, MX, MV, MT)
Number of networks and network types (combined, switch-only, wireless-only, etc.)
Number of templates and which networks they’re bound to
Admin accounts and permission levels
SAML/SSO configuration
API keys in use (internal tools, third-party integrations, webhooks)
SNMP, syslog, and monitoring configurations
Current licensing model (co-term, per-device, EA) and expiration dates
Any compliance or regulatory requirements for config retention

Define the Target State

Which org becomes the “target” (surviving) org?
What’s the target network structure? (Will you consolidate networks too, or just move them as-is?)
What’s the target template strategy?
Who gets admin access in the target org, and at what level?
What’s the target licensing model post-consolidation?

Identify Dependencies

Which networks have active VPN tunnels that will break during migration?
Which sites have on-premises RADIUS or DHCP servers that reference org-specific settings?
Are any devices in the source org claimed to a different Cisco Smart Account than the target?
Are there any devices under active RMA or support cases?

Phase 2: Pre-Migration Preparation

Backup Everything

This is non-negotiable. Before unclaiming a single device:

Export full configuration backup of every network in every source org
Export device-level configurations (port configs, switch ACLs, AP radio settings)
Export template configurations
Export group policies
Export VLAN definitions
Export firewall and traffic shaping rules
Document RADIUS secrets, pre-shared keys, and other encrypted fields (these can’t be exported via API and must be recorded manually)
Take screenshots of dashboard org settings, SAML config, and alert settings
Export any org-level API or webhook configurations

Prepare the Target Org

Create all required networks in the target org (matching structure from source)
Configure templates if using template-based management
Set up admin accounts and permissions
Configure SAML/SSO
Set up SNMP, syslog, and monitoring destinations
Configure API keys and webhooks for integrations
Configure alert profiles

Coordinate Licensing

Contact your channel partner or Cisco account team to initiate license transfer
Confirm that the target org’s licensing model can accommodate the incoming devices
If moving from co-term to EA (or vice versa), confirm the commercial terms with Cisco
Document the expected license count post-consolidation
Confirm timeline for license activation in the target org

Phase 3: Migration Execution

Per-Network Migration Steps

For each network being migrated:

Verify backup is complete and validated for this network
Notify affected users/sites about the maintenance window
In the target org: confirm the destination network is pre-configured and ready
In the source org: unclaim devices from the network
In the target org: claim devices into the destination network
Apply device-level configurations (port assignments, AP settings, etc.)
Verify device connectivity and check-in status in the dashboard
Test client connectivity at the site
Verify VPN tunnels are re-established (if applicable)
Confirm RADIUS/802.1X authentication is working
Verify DHCP is functioning correctly
Run a spot-check on firewall rules and traffic shaping
Mark network as migrated in your tracking document

Migration Order

Don’t migrate everything at once. Follow this sequence:

Lab/test networks first. Validate your process on non-production networks.
Low-risk sites. Small offices, low-traffic locations.
Medium-risk sites. Standard office locations during maintenance windows.
High-risk/critical sites. Data centers, headquarters, high-traffic retail locations. These go last, after you’ve refined the process.

Rollback Protocol

For each batch of migrations, define:

At what point do you stop and roll back?
Can you reclaim devices back to the source org if needed?
Is the source org still active and configured as a fallback?
Who makes the rollback decision?
What’s the maximum acceptable downtime per site?

Phase 4: Post-Migration Validation

Verify the Target Org

All devices showing online and checked in
All networks configured correctly (compare against pre-migration backup)
All VPN tunnels active
All admin accounts functional
SAML/SSO working
All integrations (API, webhooks, SNMP, syslog) confirmed operational
Monitoring and alerting confirmed active
Client connectivity verified at all migrated sites

Clean Up Source Orgs

Don’t decommission source orgs immediately. Wait 30 days:

Keep source orgs active but empty for 30 days as safety net
After 30-day validation period, archive source org configurations
Contact Cisco/channel partner to formally decommission source org licensing
Remove API keys and admin access from source orgs
Document the consolidation in your change management system

Automation vs. Manual

For consolidations involving fewer than 20 networks, the manual process above works with discipline and time.

For larger consolidations (50+ networks, hundreds of devices), automating the config backup, network creation, and device reclaim process is the difference between a 2-week project and a 3-month project.

Boundless provides both the tooling (Safeguard for config backup, Config Bridge for network provisioning) and professional services for org consolidation projects. The platform handles config capture, migration staging, and post-migration validation programmatically.

Available through the Cisco Networking App Marketplace or direct engagement for professional services scoping.

Noel-Edouard Chenu is the CEO of Boundless, a Cisco ecosystem software company specializing in Meraki lifecycle management including org consolidation, migration, and config governance.

Meraki Org Consolidation Checklist: How to Merge Organizations Without Losing Configs

Before You Start: The 5 Things That Break