Direct answer: what does a Cisco Meraki migration involve?

Cisco Meraki migration services are professional planning and implementation activities used to move a business network toward Meraki cloud-managed switching, wireless, security, SD-WAN, camera or systems-management operations, or to restructure an existing Meraki deployment. The work can involve replacing legacy network equipment, moving branches in phases, separating or consolidating Meraki organizations, rebuilding configuration that cannot be moved directly, or refreshing hardware while preserving required addressing, VLAN, wireless, firewall, VPN, identity and monitoring behavior.

The service is mainly used by organizations that need controlled migration rather than an ad-hoc device swap: multi-site businesses, offices with production-critical connectivity, companies with aging Cisco or third-party infrastructure, organizations inheriting Meraki networks after a merger, and teams that want centralized Meraki Dashboard operations without losing essential network policy during the transition.

The most important factor to confirm is not a single hardware model. It is the exact migration boundary: source and target organization structure, licensing model, device inventory, configuration dependencies, WAN and identity integrations, feature equivalence, acceptable outage window and rollback path. Cisco documents that organization-level items such as licensing, administrators and policies do not automatically travel with every network move, so these dependencies must be evaluated before cutover.

FourTeck can help determine the practical migration route, which settings can be reused or cloned, which items require recreation, whether a network move or a rebuild is more appropriate, what licenses and hardware are required, how to stage the change by site, and what evidence should be collected before the old platform is retired.

Migration is an architecture project, not only an equipment replacement

A successful Cisco Meraki migration starts by defining what must remain stable from the user’s point of view. Employees still need DNS, DHCP, internet access, application reachability, voice services, printers, corporate wireless, guest access, branch-to-head-office connectivity and approved access to cloud applications. Behind those familiar services may sit years of accumulated VLANs, static routes, firewall rules, NAT behavior, RADIUS or identity dependencies, public IP assignments, remote-access expectations, switch port settings, wireless authentication methods, monitoring integrations and operational shortcuts. Moving the management plane to Meraki does not make those dependencies disappear. It makes them easier to centralize only after they have been understood and translated correctly.

For that reason, FourTeck treats migration as a sequence of decisions. First comes discovery: what exists, who owns it, what talks to what, and which services are business-critical. Next comes target design: which Meraki product families, organization model, networks, templates, licensing approach and administrative model are appropriate. The design is then converted into a build plan that identifies settings to pre-stage, dependencies to coordinate with other teams, test cases to run, and conditions that trigger rollback. Only after that preparation does physical or logical cutover begin.

This discipline is especially important when the source network is not already Meraki. A legacy firewall may express objects, zones, NAT rules, VPN policies and logging differently from a Meraki MX design. A traditional controller-based wireless system may handle radio profiles, authentication and guest services differently from Meraki MR. A campus switch environment may use spanning-tree assumptions, link aggregation, routing design or access-control behavior that needs explicit mapping before an MS deployment is introduced. Feature names that sound similar are not automatically operationally identical.

Even Meraki-to-Meraki moves need structure. Cisco’s Dashboard organizes equipment and configuration within independent organizations. Licensing, inventory, administrators and configurations are associated with that structure, and newer network portability functions still have defined conditions and restrictions. A migration therefore needs to distinguish between moving a network, moving devices, cloning configuration, recreating organization-wide settings, changing licensing, and creating a new operating model. Those are related tasks, but they are not the same task.

Typical Cisco Meraki migration scenarios in Dubai

Phase 1: discovery and migration readiness assessment

Discovery creates the factual baseline for every later decision. FourTeck begins by identifying the sites and services that are in scope and separating them from systems that should remain unchanged. The inventory should include network devices, device models, serial numbers where available, current software or firmware, WAN circuits, public addressing, interface usage, transceivers, power requirements, wireless access points, switches, firewalls, routers, VPN peers and any management platforms that will be retired or retained. For a Meraki-to-Meraki move, the Dashboard organization, network names, device inventory, licensing model and administrative ownership are equally important.

The configuration baseline goes deeper than inventory. VLANs, subnets, gateways, DHCP scopes, reserved addresses, static routes, dynamic-routing relationships where used, firewall rules, NAT rules, VPN networks, traffic shaping, content or security settings, switch trunks, access VLANs, link aggregation, spanning-tree roles, SSIDs, authentication methods, RADIUS servers, certificates, splash or guest workflows and logging targets should be documented at a level that allows someone to test the target platform later. The goal is not to copy every historical line of configuration. It is to identify every behavior that the business still depends on.

Application dependency mapping is a separate exercise because infrastructure teams may not know which flows are essential to business operations. ERP systems, payment platforms, voice systems, CCTV, building controls, printers, warehouse devices, cloud-hosted services, remote desktop systems and partner VPNs may depend on particular IP addresses or paths. A migration plan should identify application owners and decide how success will be tested. Saying that “the internet works” is not enough if finance users cannot reach a banking portal through the expected allowlist or a branch cannot reach the central application server after a VPN change.

The readiness assessment also looks for undocumented single points of failure. One ISP circuit may be carrying both primary internet and site-to-site VPN. A switch may have a single uplink to a critical server rack. A wireless authentication server may reside on a subnet that will move later. The existing network might already contain faults or temporary workarounds that should not be reproduced. These findings influence the migration order and can change whether the best approach is an in-place replacement, a parallel build, a temporary coexistence design or a larger redesign.

At the end of discovery, the useful deliverable is not simply a spreadsheet of devices. It is a migration dependency map: what is moving, what is staying, what must be changed elsewhere, who owns each dependency, what is tested before and after cutover, and what condition would make the team stop or roll back.

Phase 2: target Meraki organization and network design

Cisco Meraki Dashboard is organized around organizations and networks. Cisco generally recommends one network per physical location or branch, although the right design depends on the actual device mix and operational model. An organization is a stronger administrative and licensing boundary: inventory, users, licensing and configuration are treated independently. This matters during migration because combining everything into one organization may simplify centralized management, while separating business units may be appropriate when licensing, ownership or administration needs to remain independent.

FourTeck evaluates the target structure before devices are claimed or moved. Naming conventions should make sites easy to identify. Network boundaries should support clear troubleshooting and access control. Administrative roles should follow least-privilege principles and avoid shared personal credentials. Where a business operates many similar branches, templates or repeatable configuration methods can reduce inconsistency. Where sites differ significantly, forcing every location into an overly rigid template can create operational friction. Standardization should reduce complexity without hiding legitimate local requirements.

A target design also needs to state where network services will live after migration. DHCP may remain on Windows servers, move to a security appliance or stay on another network device. DNS may be internal, cloud-based or ISP-provided. Authentication may depend on RADIUS, identity providers or certificates. Syslog and monitoring data may be sent to security operations platforms. Site-to-site VPN topology may be hub-and-spoke or more distributed. These choices affect both configuration and testing, so they should be agreed before the first production cutover.

For organizations already using Meraki, the design phase distinguishes between a network move, a device move and a configuration recreation. Cisco’s current network portability documentation notes that network moves do not automatically carry organization-level features such as administrators, licensing or policies. It also identifies dependencies such as identity-provider resources, trusted certificates and certain licensing attachments that can block or complicate a move. The migration method must therefore be chosen based on the source organization, destination organization, shard, licensing state and the actual resources referenced by the network.

Licensing is part of the migration architecture

Cisco currently supports three licensing models in Dashboard: Subscription, Co-Termination and Per-Device Licensing, with PDL restricted to existing customers already operating under that model. The licensing model is organization-level; models are not mixed within the same organization. That makes licensing a design constraint during consolidation. Two organizations that look similar from a network standpoint may require different preparation if their licensing models differ.

The project should therefore capture the licensing model, license status, expiration or subscription dates, device classes, feature tiers, expected new device counts and any pending renewals. A migration can be technically ready but commercially blocked if the destination organization does not have the required entitlement or if moving a network creates a licensing condition that has not been resolved. Cisco’s network move documentation currently lists specific supported combinations and preparation steps; for example, subscription-bound networks may need to be unbound before certain moves, while PDL moves can require license removal from devices. These rules can change, so they should be checked again immediately before execution.

License planning should also consider timing. If a hardware refresh and licensing renewal are close together, the organization may have an opportunity to simplify its future model rather than extend a legacy arrangement without review. Conversely, changing hardware, organization structure and licensing simultaneously can add risk. The appropriate sequence depends on commercial terms, renewal dates, support status and the desired long-term operating model.

Configuration mapping: preserve business behavior, not historical clutter

A migration is an opportunity to distinguish required behavior from obsolete configuration. Old environments often contain firewall rules for retired servers, unused VLANs, stale static routes, disabled SSIDs, temporary port configurations and monitoring entries that no longer have an owner. Blindly copying everything preserves technical debt and makes troubleshooting harder. Deleting everything without verification creates risk. The correct approach is to classify each configuration item as required, replace, redesign, retire or confirm.

Wireless migration to Meraki MR

Wireless migration requires more than mounting replacement access points. The project should document each SSID, its business purpose, VLAN mapping, client addressing, authentication method, security policy, guest behavior, bandwidth controls and any dependency on RADIUS, Active Directory, certificates or captive portals. If an SSID is retained with the same name and security method, client reconnection can be easier, but that does not eliminate the need to verify authentication, roaming expectations, radio coverage and VLAN reachability.

Physical design also matters. A one-for-one access-point replacement is not always valid because radio characteristics, antenna patterns, supported bands, mounting positions, client density and building materials influence coverage. An office that has changed floor layout or device density since the original wireless installation may benefit from a revised RF plan rather than copying old AP locations. Ceiling height, warehouse racking, meeting-room density, concrete walls and outdoor areas can all change the required design.

The wired network must be ready for the wireless migration. Switch ports need the appropriate access or trunk configuration, PoE capacity must support the selected access points, and uplinks must carry the required VLANs. Authentication servers and DNS services must remain reachable during the cutover. If the wireless network is being migrated before the switching layer, temporary compatibility between old switching and new APs should be tested. If switching and wireless are changing together, the rollback plan needs to consider both layers.

Validation includes association, authentication, DHCP, DNS, internet access, internal application access, voice or collaboration behavior where relevant, guest isolation, roaming in representative areas and performance at expected client densities. Coverage complaints that existed before migration should be recorded separately so the new deployment can be measured against a realistic baseline rather than assumed to be caused by the new platform.

Switching migration to Meraki MS

Switch migration begins with port-level truth. A switch may contain dozens of interfaces that look simple in a configuration export but serve very different functions: user access, IP phones, wireless access points, cameras, printers, uplinks, server trunks, storage, building management devices or unused ports. The migration workbook should map physical port, connected device, VLAN behavior, PoE requirement, link speed, aggregation membership and any special access-control or spanning-tree requirement. Unidentified ports are investigated rather than copied blindly.

Capacity planning should check port count, copper speed, fibre uplinks, SFP or SFP+ requirements, PoE budget, stacking requirements, uplink redundancy and expected growth. Buying a switch with enough ports today but insufficient power budget for access points, phones or cameras can create a second project immediately after migration. Likewise, existing optics should not be assumed compatible simply because the connector type appears similar. The target switch, optic, fibre type and distance should be verified as a combination.

Layer 2 behavior needs deliberate review. VLAN trunks, allowed VLAN lists, native VLAN assumptions, spanning-tree root placement, link aggregation and redundant uplinks can affect the whole site if misapplied. Where layer 3 switching is used, routing, gateway placement, DHCP relay, static routes and any dynamic routing must be mapped into the target architecture. A site that is changing both core and access switching may need a phased migration that preserves temporary adjacency between old and new environments.

Cutover testing should move from infrastructure to applications. Link lights and Dashboard status are useful but not sufficient. Representative devices on each VLAN should receive the correct address, reach their gateway, resolve DNS, access required internal services and reach the internet as expected. Phones should register, access points should receive power and appropriate VLAN connectivity, cameras should stream, and business-specific equipment should be checked by its owner.

Security appliance, VPN and SD-WAN migration

A security-edge migration is usually the most dependency-heavy part of the project because it sits between internal users, internet services, remote sites and third parties. The source firewall or router configuration should be converted into a traffic-flow model: inside networks, WAN circuits, public addressing, default routes, static routes, NAT behavior, inbound publishing, outbound policy, VPN peers, remote access, DNS paths, security inspection requirements, logging destinations and any ISP-specific handoff. Each of these items has an owner and a test method.

For internet migration, the team confirms whether the ISP presents DHCP, PPPoE or static addressing, whether the public IP can move to the new appliance, whether a circuit is locked to a MAC address or customer-premises device, and whether upstream routing changes are required. For dual-WAN designs, failover behavior and application sensitivity should be documented. If public services are published through NAT, external DNS, allowlists and third-party references to the old public address need to be checked before changing the edge.

VPN migration can involve both Meraki Auto VPN relationships and third-party IPsec peers. The design needs to identify local and remote subnets, encryption requirements, peer addresses, authentication details, routing expectations and maintenance windows with external organizations. A tunnel showing as established is not a complete validation; applications across the tunnel must be tested. For partner-managed peers, coordination time can exceed the physical appliance cutover time, so those dependencies should be scheduled early.

SD-WAN migration adds path-selection and resilience decisions. The target should reflect real application priorities and available circuits rather than using default settings without analysis. Branches with business-critical cloud applications may require different policies from a small office using a single broadband connection. The project should record expected failover behavior and test it deliberately so the operations team knows what normal recovery looks like.

Security policy should be reviewed rather than indiscriminately replicated. Old rule bases often contain broad permits added during incidents or projects that were never removed. A migration is a good point to identify rule owners, remove confirmed obsolete entries and document required exceptions. However, rule cleanup should be controlled; combining an aggressive security-policy redesign with a platform cutover can make troubleshooting harder because a failed application may have several possible causes.

Meraki-to-Meraki organization moves need special care

Cisco’s newer network move capability can simplify certain migrations, but it does not make every organization resource portable. Cisco specifically notes that network moves do not move organization-level features such as administrators, licensing or policies. Its portability checks also identify dependencies including device tags, organization-level Dashboard messages, trusted certificates, identity-provider integrations and some managed SIM conditions. A network that depends on these resources may require changes before it can move cleanly.

Licensing is another gate. Cisco’s currently documented move matrix supports only certain source and destination combinations. A Co-Term network can move to another Co-Term organization under supported conditions. A PDL environment may require licenses to be removed from devices before a supported same-model move. A subscription-licensed network may need to be unbound from its subscription before migration. Cross-model moves are not universally supported. These details should be rechecked in current Cisco documentation at the time of execution because platform capabilities evolve.

The destination organization also needs operational preparation. Required administrators must have the right access. Organization-wide policies and integrations that the moved network depends on must exist or be recreated. Trusted certificates referenced by wireless or encrypted logging may need attention. Identity-provider resources should be validated. If the organization uses standard naming, tagging or alerting conventions, the moved network should be aligned after the technical move rather than left as an exception that complicates support.

For some situations, cloning or rebuilding is more appropriate than a direct move. This can be true when the project intends to change network structure significantly, when organization dependencies cannot be transferred cleanly, or when the migration is part of a larger redesign. The selection between move, clone, rebuild and device replacement is made from the actual source state rather than from a generic migration template.

A staged implementation journey

Pilot design and maintenance-window planning

A pilot should represent the complexity of the production estate closely enough to expose design weaknesses. Migrating the easiest office first can prove basic procedure, but it may not validate dual-WAN failover, voice, partner VPNs, enterprise wireless authentication or a large access-switch stack if those features do not exist at the pilot site. For a multi-site project, FourTeck classifies branches into patterns and selects a pilot that covers the most common pattern plus any high-risk variations that need separate testing.

The cutover runbook is written as an executable sequence rather than a narrative. It identifies who starts the change, who handles Dashboard actions, who changes physical cabling, who coordinates with the ISP, who validates applications and who has authority to declare rollback. Pre-checks are completed before the maintenance window wherever possible. New equipment should be inventoried, claimed or staged appropriately, required licenses should be in place, physical rack and power conditions should be checked, and configuration should be peer-reviewed.

Rollback criteria must be objective. Examples include inability to restore WAN connectivity within an agreed threshold, failure of a critical application with no identified remediation, unresolved VPN impact to a business partner, or loss of authentication affecting a defined user population. The team should know what can be rolled back easily and what changes are harder to reverse. DNS changes, public IP changes, external allowlists and organization-level moves can have different reversibility from swapping a local access switch.

The maintenance window should include stabilization time after the visible change. A network that passes the first ten minutes of testing may still reveal DHCP lease issues, authentication delays, failover behavior or application session problems later. Post-cutover observation and a clear support channel reduce the risk that users discover an issue after the project team has already dispersed.

Validation should be service-based, not device-based

Dashboard health, interface status and reachability are useful operational signals, but they do not prove that the business is ready to resume normal work. Validation is stronger when it follows the same services users depend on. A workstation on each important VLAN should obtain the expected IP settings, resolve internal and external DNS, reach the required gateway, access approved internet destinations and connect to relevant applications. Wireless users should authenticate through the intended mechanism and land in the right network. Phones should register and make test calls where voice is in scope.

Security and VPN tests should check both permitted and denied behavior. A rule base is not validated only because allowed traffic works; important segmentation boundaries should also continue to block prohibited traffic. Partner VPNs should be tested with the partner application or host, not only by tunnel status. Public services should be tested from an external network. Remote users should follow the approved remote-access workflow if that service changes during migration.

Infrastructure tests should include link redundancy, WAN failover and power behavior where these are part of the design. If dual uplinks are intended to survive a link failure, the test plan should prove the expected recovery path under controlled conditions. If access points depend on PoE, switch power consumption should be checked against the target design. If branch sites rely on a central service, loss of a WAN path should be understood rather than left to assumption.

The test matrix becomes part of the handover record. It documents what was tested, by whom, at what time, with what result and what exceptions remain. This is useful for support because it separates pre-existing issues from migration defects and creates a reference point for future troubleshooting.

Operational handover after the migration

A migration is not finished when the old device is powered off. The operations team needs a supportable environment with clear ownership. Handover should identify the Meraki Dashboard organization, network naming standard, administrator roles, authentication method for administrators, license model, renewal responsibility, alerting destinations, monitoring integrations, escalation path and hardware inventory. Documentation should reflect the final implemented state rather than the design that existed before last-minute changes.

Configuration ownership is particularly important in a cloud-managed platform because authorized administrators can make changes remotely. Role design should give people the access they need without unnecessarily broad organization-wide permissions. Departing staff and third parties should not retain access indefinitely. If a managed service provider or integrator has administrative access, the customer should understand the scope of that access and the process for review or removal.

Licensing and lifecycle responsibilities should also be recorded. The business should know which licensing model it uses, who monitors compliance, when renewal decisions are expected, how new devices will be added, and which team tracks hardware lifecycle. Cisco Meraki licensing behavior differs between Subscription, Co-Term and legacy PDL organizations, so the support process should match the actual model rather than use a generic renewal checklist.

Finally, the project should leave behind a short list of deferred improvements. Migration windows often prioritize continuity over redesign. Non-critical rule cleanup, naming standardization, alert tuning, RF optimization, WAN policy refinement or documentation enhancements may be intentionally deferred. Recording them prevents useful improvements from being forgotten while keeping the production cutover focused.

What can make a Meraki migration unsuitable or more complex?

Meraki is not automatically the right answer for every existing design simply because centralized cloud management is attractive. The target hardware and feature set must fit real requirements. A highly specialized data-centre network, unusual routing design, niche firewall feature, proprietary identity integration or extremely specific operational requirement may need a different Cisco platform or another architecture. Migration planning should identify such gaps before hardware is ordered.

Complexity also increases when the current network is poorly documented. If no one knows which firewall rules are active, which VLANs are still used or who owns third-party tunnels, the discovery phase may require traffic analysis and stakeholder interviews. That is not wasted project time; it is the work required to reduce the probability of cutting off an unknown business dependency.

Organization restructuring can add another layer of difficulty. Networks that reference organization-level identity, certificate, policy or licensing resources may not be portable without preparation. Cross-model licensing moves have restrictions. A business that wants to consolidate several historical Meraki organizations should therefore expect some administrative and commercial work alongside the technical configuration tasks.

A final source of complexity is trying to change too many things in one window. Readdressing the network, replacing the firewall, redesigning wireless, changing identity, moving applications and switching licensing at the same time can make every fault ambiguous. Sometimes that level of change is unavoidable, but where possible, FourTeck sequences independent changes so each stage has a clear success condition.

Migration deliverables can be tailored to the project

Dubai and UAE deployment considerations

A Dubai migration can involve a mix of head offices, retail locations, warehouses, hospitality sites, clinics, schools, construction offices and regional branches, each with different uptime expectations. The implementation plan should account for local business hours, building access rules, data-centre access procedures, mall or free-zone maintenance windows, landlord coordination where cabling is involved, and the lead time required for telecom-provider changes. A network cutover that depends on a circuit upgrade cannot be scheduled reliably until the carrier-side scope is confirmed.

Hardware availability and licensing should be synchronized with the project schedule. Where equipment must be ordered, exact models, quantities, power supplies, rack accessories, optics and licenses should be confirmed against the bill of materials. Substituting a nearby model because it is available locally may be reasonable, but it should be treated as a design change and checked for port type, capacity, PoE, uplinks, feature support and licensing impact.

Multi-site UAE projects may benefit from a wave approach. Dubai can serve as the pilot where technical teams are concentrated, followed by Abu Dhabi, Sharjah or other locations after the baseline is proven. However, the rollout order should follow risk and business value rather than geography alone. A small remote branch may be a better pilot than a headquarters that cannot tolerate extended troubleshooting, while a warehouse with specialized handheld devices may require its own pilot pattern.

FourTeck can scope migration services around on-site activities, remote Dashboard work, design review, configuration preparation, cutover assistance and post-change support. The quotation depends on the actual number of sites, devices, networks, integrations, migration waves and after-hours requirements rather than on the product name alone.

Questions buyers should resolve before requesting a migration quote

Frequently asked questions about Cisco Meraki migration services

Decision recap: the choices that determine migration success

What FourTeck needs for an accurate Cisco Meraki migration scope

The more accurately the current environment is described, the more useful the migration plan and quotation will be. A perfect configuration archive is not required, but the following inputs reduce assumptions.

Plan the Cisco Meraki migration around your real network, not a generic checklist

Share your site count, current platform, Meraki organization details if applicable, WAN and VPN requirements, critical applications and target timeline. FourTeck can use those inputs to define the discovery effort, migration method, licensing checks, cutover sequence, validation scope and support requirements for a practical Dubai deployment.