Why the migration needs a deliberate project plan

An MDM migration is easy to underestimate because the visible management console is only one part of the operating model. Behind the dashboard are device enrolment records, platform certificates, Apple and Google service bindings, application assignments, Wi-Fi and VPN settings, compliance rules, ownership information, tags, user identities, custom software packages, scripts and support procedures. A replacement platform can provide similar outcomes while implementing them in a different way. For that reason, a successful migration is a translation project as much as it is a device move.

The lifecycle deadline creates a useful planning boundary. Cisco announced the Meraki Systems Manager End-of-Sale on 3 December 2025, the last day for new one-year and three-year SM license purchases was 3 June 2026, and support is scheduled to continue until 3 June 2029. Existing organisations therefore have time to migrate, but delaying discovery until close to the support deadline can make the project harder. Large fleets often contain old or rarely connected endpoints, devices enrolled through different historical methods, shared tablets, personally owned phones, kiosk devices, custom business applications and desktops that need both MDM and software-management capabilities.

The best use of the remaining support period is to build an accurate inventory, decide the destination architecture, test representative devices and migrate in controlled waves. The project should be driven by business continuity and management coverage, not by a desire to remove the old console as quickly as possible. A device is only successfully migrated when the new platform can identify it, enforce the intended policy, deliver required applications, support the relevant user workflow and provide the operational team with enough visibility to manage the endpoint.

What the migration service can cover

Inventory elements that should be captured before migration

Device and owner inventory: preserve the relationships, not only the count

A device count is necessary for pricing and scheduling, but it is not sufficient for migration design. Two organisations with 500 endpoints can have completely different project complexity. One may have 500 centrally owned iPads using Automated Device Enrollment and standard profiles. Another may have a mixture of executive iPhones, Android BYOD, Windows laptops, shared tablets, kiosk devices and macOS systems with custom packages. The second environment requires more migration tracks even though the total quantity is identical.

Cisco’s migration guidance recommends exporting the enrolled-device inventory and owner information before changes begin. Owners in Systems Manager represent users associated with devices and can include usernames, email addresses, groups and owner tags. This relationship is useful when reproducing assignment logic in a replacement platform. Passwords for identity-provider users are not stored by Systems Manager, so a migration plan should treat the identity provider as the authoritative source for credentials and authentication continuity.

For project control, the exported inventory should become a living migration register. Each endpoint can be given a migration wave, destination ownership model, enrolment method, expected user action, status and exception reason. That register provides a measurable answer to questions such as how many devices have migrated, how many remain only in Meraki, which devices failed enrolment and which endpoints are deliberately excluded because they are being replaced. Without that reconciliation layer, a dashboard showing hundreds of newly enrolled devices can still hide a material group of devices left behind.

The same inventory helps the business make scope decisions. Very old or seldom-used endpoints may be better retired than migrated. Devices scheduled for hardware refresh can sometimes move to the new platform as part of replacement rather than through an in-place migration. Shared devices may require a different staging process from user-assigned devices. Identifying these categories early prevents the migration project from spending equal effort on endpoints with very different business value.

Applications, packages and assignment logic

Application migration should be treated as a portfolio exercise rather than a bulk export-and-import task. Cisco documents the ability to export application metadata from Systems Manager to CSV, but it also warns that the export is metadata only. Custom application files hosted through Meraki, such as IPA, APK, MSI or PKG packages, need to be retained separately so the new MDM can deploy them. That distinction is important because discovering a missing installer after the old platform has been retired can turn a simple application migration into a software-recovery project.

For each application, the migration register should capture platform, business owner, installation source, installation arguments where relevant, required or optional status, scope, version expectations and any managed configuration values. Applications that are no longer required should not automatically be rebuilt simply because they exist in Meraki. Migration is a useful opportunity to remove obsolete packages, consolidate duplicate deployment methods and confirm ownership of internally developed software.

Assignment logic also needs translation. A Meraki tag may represent department, ownership, device type, compliance state or another operational concept. The destination platform may use dynamic groups, filters, labels or assignments differently. Recreating the tag name without understanding its purpose can produce the wrong application or policy scope. The safer method is to document the business rule first—for example, all corporate iPads in a sales group receive a specific application—and then implement that rule using the destination platform’s supported assignment mechanism.

Testing should verify more than whether an icon appears. For required applications, confirm installation behaviour, update handling, licensing, managed configuration and removal behaviour where relevant. For custom Windows and macOS packages, test silent installation and any prerequisite or detection logic. A representative pilot device should be used for every application that could materially interrupt a business workflow.

Profiles and policies: rebuild the intended security outcome

Configuration profiles are usually the most important part of a migration because they encode how the organisation expects endpoints to behave. Cisco specifically advises administrators to record critical Systems Manager settings such as Wi-Fi, certificates, passcodes, restrictions, single sign-on, encryption and managed application configuration. These are not decorative settings. They can determine whether a device can join a corporate wireless network, access an application, satisfy security requirements or connect to protected business resources.

The migration team should avoid assuming that a setting with the same name produces identical behaviour in every MDM. Operating-system vendors expose native management controls, but each management platform can present, group, scope and report those controls differently. A policy-mapping document should therefore include the existing Meraki setting, its business purpose, the intended destination configuration, scope, prerequisites and test result. Where a Meraki configuration no longer has a direct equivalent, the project should record the gap and decide whether another control can achieve the same objective.

Certificate-based access deserves special attention. Certificates may support Wi-Fi, VPN, email, application authentication or device trust. The team needs to understand how certificates are issued, renewed and revoked, whether a certificate authority or SCEP-style service is involved, and what happens when the old management profile is removed. A device that is technically enrolled in the new MDM but cannot obtain a required certificate may be unusable for the employee’s actual work.

Policy migration should finish with a test matrix rather than a visual comparison of two consoles. The test matrix can confirm passcode enforcement, restrictions, encryption state, network access, required certificates, application configuration, compliance reporting and any conditional access or network-control integrations in scope. This produces evidence that the replacement platform is delivering the desired control, not simply that configuration objects have been created.

Android Enterprise migration: corporate ownership and BYOD require different workflows

Android migration planning starts by identifying enrolment mode. A corporate device managed as Android Enterprise Device Owner has a very different transition path from a personally owned phone using a Work Profile. Device Owner management is established at a privileged point in setup, so changing management platforms often involves a reset and re-provisioning workflow. Work Profile management, by contrast, separates a managed work container from the user’s personal space and can generally be removed and recreated without erasing the entire personal device, although the managed work data is removed as part of that process.

Cisco’s migration guidance advises keeping the Android Enterprise administrator binding in place until the organisation is ready to connect Android Enterprise to the new MDM. For corporate Device Owner endpoints using Android Zero-touch enrollment, the Zero-touch configuration should be changed to the new destination settings before the devices are reset. When those devices pass through initial setup again, the intention is for them to enrol into the replacement platform under the new configuration.

Corporate Android devices without Zero-touch usually require more hands-on work because the device must be put back into the correct setup state and manually enrolled into the new management product. That increases scheduling, user-support and logistics requirements. A fleet spread across multiple UAE offices or field locations may therefore benefit from local migration windows, device replacement where hardware is already near end of life, or a staging process that reduces the number of endpoints requiring ad-hoc user intervention.

For BYOD Android Work Profile devices, the communication plan matters as much as the technical plan. Removing the work profile removes managed work applications and data associated with that profile, and the user then needs to complete enrolment into the new platform. Instructions should clearly separate what happens to corporate work data from what happens to the user’s personal area. The pilot should include ordinary end users, not only IT staff, because unclear prompts or authentication steps often become the largest source of support tickets during a BYOD migration.

After re-enrolment, validate managed Google Play applications, required account configuration, compliance reporting and any network or application access conditions. A device appearing in the new console does not by itself prove that the user’s work profile is fully functional.

Windows migration: separate MDM profile, agent functions and software delivery

Windows endpoints can require extra discovery because Meraki Systems Manager supports management through an MDM profile and also through an installed agent. Cisco describes these as complementary components: the management profile provides native MDM functions, while the agent can add capabilities such as software deployment and remote desktop on supported desktop platforms. An organisation that has relied on both needs to map both sets of functions to the destination solution before uninstalling Meraki components.

Cisco’s migration guidance for Windows calls for uninstalling the Systems Manager agent and profile, optionally deleting the device record from the SM network, and then enrolling the device according to the replacement platform’s Windows strategy. For company-owned devices, Cisco points to Windows Autopilot as an option where supported by the new MDM. The practical design choice is whether the migration will be in-place on existing Windows builds, aligned with a device refresh, or performed through an automated provisioning workflow for new or reset devices.

The migration assessment should identify any MSI, EXE, scripts or other desktop software delivered through Meraki, along with installation arguments, dependencies, detection logic and update expectations. It should also identify remote-support features the service desk currently uses. Replacing MDM policy but forgetting desktop software delivery can leave an environment in which compliance settings work while important line-of-business software no longer installs or updates.

Identity and access should also be tested on Windows endpoints. If corporate Wi-Fi, VPN, email or protected applications depend on certificates or device compliance, the destination platform must establish those prerequisites before the old management relationship is removed or within a carefully controlled transition sequence. A pilot Windows laptop should be tested across normal user activities such as sign-in, network access, application launch, software update and help-desk support.

For remote or travelling staff, timing matters. Uninstalling old management and asking a user to re-enrol while they have weak connectivity can leave a device in an unmanaged state. Wave planning should therefore account for network quality, user availability and an escalation route if the endpoint cannot complete the new enrolment.

ChromeOS and specialist endpoint populations

ChromeOS may represent a small portion of a commercial fleet, but it should not be ignored if Meraki Systems Manager is integrated with the Google Admin environment. Cisco’s migration material states that ChromeOS devices need to be unenrolled from Meraki SM and re-enrolled into the new management platform, with the ChromeOS API setup disabled in the Meraki organisation and the replacement management connection established according to Google’s enrolment process.

Special-purpose devices deserve similar treatment even when they do not form a major percentage of the endpoint count. Shared tablets, meeting-room devices, warehouse handhelds, digital signage endpoints, kiosks, executive devices, development devices and devices used by contractors may each have unusual management requirements. The migration design should identify these populations explicitly rather than assuming that the dominant corporate-laptop workflow will cover everything.

The key principle is to assign a migration method to every endpoint category before mass cutover. If a device type has no tested migration path, it is an unresolved project risk. A short list of ten specialist endpoints can create more operational disruption than hundreds of standard devices if those ten systems support reception, logistics, point-of-service, meeting-room control or another business-critical function.

Choosing the replacement MDM or UEM platform

A Meraki Systems Manager migration project should not begin with the assumption that every replacement platform is interchangeable. Cisco identifies Ivanti Neurons for MDM as a replacement option through its SolutionsPlus program, but the correct destination still depends on the organisation’s endpoint mix, existing software ecosystem, security requirements, identity architecture, operational skills, commercial model and future roadmap. Current subscription terms and availability should be confirmed during quotation rather than assumed from historical documentation.

The evaluation should compare required outcomes rather than marketing checklists. Important questions include which operating systems and ownership models must be supported; whether the organisation needs Apple Automated Device Enrollment, Android Enterprise, Windows provisioning, BYOD separation, application distribution, scripting, remote support, certificate deployment, compliance reporting and integration with identity or network controls. A feature is only relevant if it fits the real endpoint population and support model.

Migration complexity should be included in the destination decision. A platform may meet long-term requirements but demand more user-driven re-enrolment, different application packaging or a redesign of current policy logic. That does not necessarily make it the wrong choice, but it affects project effort, user communication and cutover risk. Conversely, choosing the product that looks most similar to Meraki can be short-sighted if it does not fit the organisation’s broader endpoint strategy for the next several years.

FourTeck’s migration consultation can be scoped around the current environment and the customer’s selected destination. Where the destination has not yet been chosen, the assessment can concentrate on documenting requirements and migration dependencies so the business can compare alternatives using its actual device estate rather than generic feature lists.

Security continuity during the cutover

A migration creates a temporary period in which the same device may move from one management authority to another. The design should minimise the time between removal of old controls and establishment of new controls. That is especially important for devices that access sensitive applications, corporate Wi-Fi, VPN services or regulated data. The cutover procedure should define the expected management state at every step so the team knows when a device is protected by Meraki, when it is in transition and when the destination platform has taken over.

Compliance rules should be mapped carefully. A destination platform may calculate compliance differently or expose different remediation actions. If network access or identity access depends on compliance, the business should test how a newly migrated device is evaluated and how quickly a policy change affects access. A configuration that is technically present but not linked to the expected access-control workflow can create either unnecessary lockouts or an unintended security gap.

Administrative access also deserves review. The old Systems Manager environment may have accumulated dashboard administrators and operational roles over time. The replacement platform should start with a deliberate role model rather than reproducing every historical permission. Privileged roles should be limited to the people who need them, authentication controls should follow the organisation’s security standard, and service accounts or API integrations should be documented so they are not overlooked during retirement.

Migration logs and evidence can be retained according to business policy. Useful records include baseline exports, approved configuration mappings, pilot results, wave completion reports, exception lists and final reconciliation. These records help the organisation demonstrate what changed and provide a reference if an endpoint later behaves differently from its pre-migration configuration.

Identity, authentication and user ownership

Endpoint management is closely tied to identity because device ownership, enrolment authentication, application assignment and access decisions frequently depend on the user. Cisco notes that Systems Manager owners can be linked to identity providers and that Meraki does not store the users’ identity-provider passwords. A migration should therefore validate the identity system independently and make sure that the destination MDM can use the required authentication method without treating the Meraki owners export as a credential database.

The project should distinguish device identity from user identity. A shared tablet may be corporate-owned without a permanent user. A personally owned phone may have a strong user relationship but limited device-level control. A Windows laptop may be assigned to one employee yet also require device-based certificates for network access. These combinations affect how groups, policies and applications should be scoped in the new platform.

User authentication is also part of the migration experience. If the new MDM uses a different enrolment portal, sign-in sequence, multi-factor authentication prompt or terms-of-use step, those differences should appear in user instructions and pilot testing. An IT administrator who already understands the process can overlook a confusing screen that causes ordinary users to stop midway through enrolment.

Where possible, user communications should explain why the organisation is making the change, what the employee needs to do, what will happen to business applications and data, whether a reboot or reset is required, how long the interaction normally takes, and where to obtain help. Clear instructions reduce both user resistance and the number of devices that remain unmanaged because a prompt was ignored.

A practical phased migration journey

Pilot design: small enough to control, broad enough to reveal real problems

A pilot should not consist only of IT administrators using the newest devices. That approach can prove that the basic enrolment workflow functions while missing the problems that ordinary users and older endpoints will encounter. A useful pilot includes a representative sample of operating systems, ownership models, device ages, business units, locations and application requirements. If the organisation has Apple ADE devices, Android Work Profile users, Windows laptops with custom software and shared tablets, at least one or two examples from each meaningful group should be tested.

The pilot needs explicit success criteria. A device should be considered successful only after the new platform has enrolled it and the business has confirmed the required management outcomes. Those outcomes may include Wi-Fi connectivity, VPN access, certificate delivery, email or SSO access, required application installation, policy enforcement, compliance reporting, remote support and correct ownership or group assignment. The exact list depends on the environment, but it should be written before the pilot starts.

Failure criteria are equally useful. If an application cannot install, a certificate cannot be issued, a user cannot authenticate, a reset causes unacceptable data loss or a policy unexpectedly blocks a normal workflow, the pilot should stop expansion of that migration path until the issue is understood. This is the point of a pilot: to discover weaknesses while the blast radius is small.

After pilot completion, the runbook should be updated to reflect what actually happened rather than what was expected. Screenshots, user instructions, elapsed interaction steps, support notes and troubleshooting actions can all be refined before the first production wave. A well-run pilot turns a theoretical design into an operationally repeatable migration procedure.

Wave planning for Dubai and multi-site UAE environments

Migration waves should reflect operational reality. A business with one Dubai office may organise waves by department and device type. A company with offices, branches, warehouses or field teams across the UAE may need location-based windows, local support coverage and different approaches for devices that rarely visit a corporate site. The migration method should also account for users who travel or work remotely, because some enrolment steps are much easier when reliable internet access and support are immediately available.

Wave size should be chosen from support capacity rather than an arbitrary percentage of the fleet. If a migration requires user interaction, a batch that is technically easy for the MDM platform may still overwhelm the help desk. A smaller initial production wave gives the team a chance to measure real ticket volume, identify common questions and adjust communications. Later waves can be larger once the process is stable.

Business-critical groups may be deliberately scheduled later, after the migration procedure has been proven on lower-risk users. Executive devices, finance endpoints, operational tablets and other sensitive populations may need dedicated windows and faster escalation paths. Devices that require factory reset should be scheduled differently from devices that can transition with minimal user interruption.

The project register should show each wave’s planned population, actual completion count, exceptions and next action. This creates a clean handover from project activity to steady-state operations and prevents the final few difficult devices from being forgotten when the majority of the fleet has already moved.

User communication and service-desk readiness

A technically sound migration can still fail operationally if users do not understand what is happening. Communications should be written for the actual migration path. A user whose Apple device can transition with little interruption needs a different message from an Android BYOD user who must remove and recreate a Work Profile or a user whose corporate device requires a factory reset. Generic instructions create unnecessary anxiety and increase support volume.

Each communication should explain the reason for the change in practical terms, the date or window, actions required from the user, expected prompts, whether data or settings may be affected, what must be backed up, the expected state after migration and how to contact support. Where a reset is involved, the message should be especially clear about data preservation and application restoration. The project should never assume that an MDM backup is the same thing as a complete user-data backup.

The service desk should receive its own runbook. It should include device-identification steps, common enrolment failures, authentication issues, platform-specific removal and enrolment guidance, criteria for escalation, and a way to update the migration register. Support staff should also know the intended end state so they do not accidentally re-enrol a device into Meraki after it has been scheduled for the replacement platform.

For larger organisations, a migration knowledge base can be more effective than sending long email instructions. Short platform-specific guides, accompanied by a clear support contact, help users follow the correct process and reduce the chance that an employee uses instructions intended for a different ownership or enrolment model.

Data protection, backup and reset decisions

The word “migration” can suggest that all settings and data move automatically between platforms, but MDM migration does not work like moving a virtual machine from one host to another. Device-management systems control settings, applications and management relationships; they do not automatically transfer every user’s local data from the old MDM to the new one. Any workflow involving device erase or removal of a managed work container should therefore include a separate data-preservation decision.

For corporate devices, the business should identify where user data is expected to reside and whether that location is already backed up. Cloud-synchronised corporate data may be straightforward to restore, while local files, application-specific data or unmanaged content may require additional steps. For BYOD, the team should be precise about which managed work data is removed and which personal data remains outside the managed container. User instructions should match the platform and the selected migration method.

Factory reset should be treated as a deliberate technical choice, not a default cleanup step. It can provide a clean provisioning state and may be required for particular corporate enrolment models, but it increases user interruption and raises the importance of backup, authentication recovery and application restoration. Where an officially supported no-reset migration path is available and appropriate, it may reduce disruption, but it still needs testing and destination-platform compatibility confirmation.

A good runbook has a go/no-go checkpoint before destructive actions. The technician or automation process should know that the device is in the correct wave, the destination platform is ready, required data protection steps are complete, the user is informed and the fallback or escalation route is available. This is especially important for executive, field and operational devices where a failed reset can remove access to business systems for an extended period.

What happens to Meraki Systems Manager after the migration?

The old SM environment should remain available until the new management platform has been validated and the migration register shows that in-scope endpoints are complete or have an approved exception. Cisco’s EOL migration guidance states that, after the migration is complete, the Systems Manager network can be deleted. It also cautions that if Systems Manager is part of a combined Meraki network, the network should be split so only the SM portion is deleted. Other Meraki products in the combined environment should not be removed simply because Systems Manager is being retired.

License reconciliation is another useful final check. Cisco notes that if Systems Manager clients still appear in the licensing information, endpoints or networks may not have been fully removed. The project should therefore reconcile the old inventory, destination inventory and remaining SM count before closing the technical migration. A small number of residual devices should be investigated rather than dismissed as a reporting difference.

The organisation should also preserve agreed project records before deletion. This can include exported device and owner inventories, application lists, profile documentation, migration mappings, test results and sign-off. The purpose is not to keep the old management platform indefinitely; it is to make sure the business retains enough evidence to understand what was moved and how the new environment was designed.

Cisco’s current documentation warns that after the end-of-support date, SM-enrolled endpoints may retain their last configuration but will no longer communicate with the Meraki Dashboard for further changes. That is a strong reason not to treat 3 June 2029 as a date on which to begin planning. The safer objective is to complete migration, validation and decommissioning well before the management service reaches that boundary.

Common migration risks and how the project should address them

Migration sizing: what determines effort and quotation accuracy?

Device quantity influences project effort, but migration complexity is usually driven by diversity. A homogeneous fleet of supervised Apple devices with consistent policies can be easier to move than a much smaller environment containing several operating systems, BYOD, custom applications, certificates, field devices and historical enrolment methods. An accurate quotation therefore needs more than the total endpoint count.

Important sizing inputs include the number of Meraki SM networks, total managed endpoints, operating-system distribution, company-owned versus user-owned split, Apple Automated Device Enrollment use, Android Device Owner and Work Profile use, Android Zero-touch use, Windows agent use, application count, number and complexity of profiles, custom application packages, certificate dependencies, identity integrations, current API automation, locations, user-support expectations and the destination platform.

The required migration method has a major impact. A no-reset automated Apple transition can have a different support profile from a factory-reset migration. Corporate Android devices without Zero-touch can require hands-on re-enrolment. Remote Windows users may need scheduled assistance. A large BYOD population can create a communications and help-desk workload even if the console configuration is relatively simple.

Project scope should also distinguish advisory work from implementation. Some organisations need a discovery and migration design because their internal team will execute the waves. Others need destination configuration, pilot execution, user communications, onsite assistance and post-migration reconciliation. Defining these responsibilities before quotation avoids ambiguity about what “migration” includes.

Operational handover after the new MDM is live

The migration project should end with an operating model, not simply a populated dashboard. Administrators need to know how to enrol a new device, retire an old device, assign applications, manage groups, respond to a lost device, troubleshoot non-compliance, update policies and identify devices that have stopped checking in. Service-desk staff need clear escalation routes, and asset-management processes should reflect the new source of endpoint information.

Monitoring and reporting should be validated against business needs. If the organisation previously used Systems Manager reports, tags or API data for asset tracking, security review or operational dashboards, the replacement process should identify how those outputs will be produced. An MDM can be functionally successful at device control while still creating an operational gap if existing reports disappear without an agreed replacement.

Offboarding deserves a specific test. The team should verify how a departing user or retired device is handled, including application removal, corporate-data removal, account or certificate revocation and inventory updates. These day-two workflows often expose gaps that are not visible during initial enrolment testing.

Documentation should be updated to describe the new platform and remove obsolete Meraki instructions. Leaving old enrolment URLs, screenshots or support procedures in internal knowledge bases can cause confusion months after the migration is complete, especially when new staff join the IT team.

Who is a good fit for a structured Meraki SM migration service?

What should be confirmed before scheduling the project?

The first confirmation is destination readiness. If the new MDM has not been selected, the project should begin with requirements and assessment rather than endpoint cutover. If the destination is already chosen, confirm the subscription, tenant, administrative access and required platform integrations before scheduling production devices.

The second confirmation is source access. The migration team needs appropriate Meraki Dashboard permissions to export inventory and review the settings in scope. Apple, Google and identity administration may require different credentials owned by different teams. Those dependencies should be identified early so a cutover does not stop because a token cannot be downloaded or an administrator account is unavailable.

The third confirmation is device reachability and ownership. Know how many devices are company-owned, how many are BYOD, how many are remote, which devices can be reset, which devices cannot tolerate downtime and which endpoints are already candidates for replacement. This information shapes the wave plan and support model.

The fourth confirmation is application and data responsibility. Determine which applications are required, who owns custom installers, where user data is backed up and what data could be lost if a device or work profile is erased. Migration should not begin with unresolved assumptions about business-critical information.

Finally, define acceptance criteria. Decide what must be true before a device, a wave and the entire migration are considered complete. Clear acceptance criteria prevent the project from declaring success simply because most endpoints appear in the new console.

Cisco Meraki Systems Manager migration FAQs

Decision recap before you approve the migration plan