Most Mac fleets arriving at Intune aren’t starting from zero. They’re either managed by Jamf and the organization is consolidating to Intune, or they’re unmanaged – devices that have accumulated years of local configuration, user-installed software, and no management footprint at all. Both scenarios have different risks and different approaches.
Migrating from No MDM
Unmanaged Macs are in many ways the easier migration – there’s no existing management configuration to untangle, no profile conflicts to worry about, and no user expectations around management behavior to manage. The challenge is that unmanaged Macs are often in significantly varied states. Local accounts with no relationship to the organization’s identity infrastructure, years of user-installed software, FileVault keys that were never escrowed anywhere, and security configurations that are entirely user-controlled.
For unmanaged Macs without ABM, enrollment is user-initiated through Company Portal. The management profile installs, Intune begins delivering policies, and the device enters managed state. The practical challenges: FileVault may already be enabled with a recovery key nobody has, which needs to be rotated and escrowed to Entra ID after enrollment. Local accounts may have simple passwords that conflict with the password policy being delivered. Applications installed locally may conflict with managed application deployment. None of these are blockers – they’re remediation items that surface during the pilot phase and need to be addressed before broad rollout.
Unmanaged Macs enrolling into Intune will surface everything that was previously invisible – password policy violations, unrecognized applications, FileVault keys that were never escrowed. That’s useful information. Expect it and plan the remediation.
ABM simplifies future enrollments significantly even if existing devices need to be enrolled manually. Devices purchased after ABM is connected to your reseller will enroll automatically through ADE. For the existing fleet, a one-time user-initiated enrollment is the practical path – combined with a communication explaining what’s happening and why.
Migrating from Jamf
Migrating from Jamf to Intune is a more complex project, and the complexity scales with how extensively Jamf has been used. A Jamf environment that deployed a few configuration profiles and enforced FileVault is a relatively straightforward migration. A Jamf environment with hundreds of policies, scripts, extension attributes, patch management workflows, and deeply customized configuration is a significant undertaking that requires careful inventory before any migration begins.
The first step is a Jamf configuration inventory – understanding what Jamf is actually doing that Intune will need to replicate or replace. Configuration profiles, scripts, policies, patch management, self-service applications. Not everything in Jamf will have a direct Intune equivalent, and identifying the gaps before migration begins prevents discovering them at the worst time.
The migration itself typically follows a parallel management period. Devices remain enrolled in Jamf while Intune is configured and validated. A pilot group of devices is migrated to Intune-only management – removing the Jamf MDM profile and enrolling into Intune. The pilot validates that Intune replicates the necessary configuration, that applications deploy correctly, that compliance policies evaluate as expected, and that Platform SSO registers and functions correctly. Only after the pilot is validated does the broader migration proceed.
Removing the Jamf MDM profile is the irreversible step. Once it’s removed, the device is no longer Jamf-managed – any Jamf-delivered configurations that Intune hasn’t replicated will be gone. The order matters: Intune enrollment and validation first, Jamf removal second. Never the other way around.
The Jamf migration isn’t a cutover – it’s a parallel deployment that graduates devices from one management plane to another. Rushing the transition to hit a deadline is how you end up with unmanaged Macs in production.
One practical consideration for Jamf migrations: Jamf’s self-service application has often become part of users’ workflows. Users know how to install approved software through Self Service, and removing it without a Company Portal replacement that covers the same catalog disrupts that workflow. Deploy Company Portal and populate it with the available applications that users relied on through Jamf Self Service before removing Jamf from the device – not after.
Whether migrating from Jamf or from no MDM, the intune-my-macs baseline provides a validated starting point for the Intune configuration side of the migration. The migration complexity is in inventory, sequencing, and user communication – not in the Intune configuration itself, which is the most manageable part of the project.
If you’re migrating from Workspace ONE, Meraki, or another MDM platform rather than Jamf, the broader MDM migration picture – including the iOS 26 native Apple Business Manager migration that removes the need to wipe Apple devices when switching MDMs – is covered in the standalone article on MDM-to-MDM migration.
Intune Deployment Guide · Phase 11: Mac Management
‹ Previous: [11.5] Mac Baselines: Configuration Profiles vs Settings Catalog
Next: [11.7] Apple Software Update Management: Moving to Declarative Device Management ›
