macOS · Migration Series
A staged set of standalone guides for moving an Apple silicon fleet off Jamf and onto Intune. Read them in order, or pick the one you need.
Each stage below is a complete, standalone guide. The order is the sequence I would follow on a real migration, audit what you actually enforce, enrol cleanly, secure the machine, then mature the identity model, but nothing stops you jumping straight to the part you need. Every published guide here is written from a build that was done and validated on real hardware. The last stage is not published yet, because it has not been built yet.
Every guide here builds a Mac from scratch: wipe, enrol, configure. None of them migrates a machine that is already in service with a user's data on it. That is not an omission I am embarrassed about, it is the method, and it is worth explaining before you decide this series is not for you.
One more boundary worth stating up front. This series assumes endpoint security tooling is already deployed, antivirus, EDR, the network filter, before you start any of the stages below. Standing that up is its own substantial project and is not covered here; the audit guide explains exactly what that tooling accounted for on the build behind this series, so you can see the shape of the gap rather than guess at it. If you do not already have equivalent tooling in Intune, treat that as a hard prerequisite to this whole series, not something these guides will hand you along the way.
You cannot debug a migration on top of a baseline you have never proven. If you take a machine that has years of accumulated state, move it to a new platform, and something breaks, you are now holding two unknowns: is the fault in the migration, or was your new configuration never right in the first place? So you build clean first, on a fresh machine, until the base is boringly repeatable. That build becomes your control. Everything that then goes wrong on a migrated machine is attributable to the migration, because you already know the configuration works. That is the whole reason the rebuild path comes first, and it is why the in-place migration stage below is not published yet: the control has to exist before the experiment means anything.
On the two enrolment paths. This series enrols without user affinity, and then treats affinity and Platform SSO as a later stage. I did both because they answer different questions. No affinity proves the fundamentals in isolation: does Automated Device Enrolment work, does FileVault enforce and escrow, does the break-glass actually break the glass, with no directory identity in the way to blame. It also suits stage-and-post, where IT builds a machine and hands it over, and it got the estate moving without waiting on the identity work. Affinity plus Platform SSO answers the question that matters next: can the login password, the directory identity and the FileVault credential all be the same thing, so the password collisions documented in these guides simply cannot happen.
Where this is heading: user affinity, on balance. It is the stronger identity model and it closes off a whole class of problem at the root rather than working around it. But affinity only earns its keep if the surrounding experience is genuinely low touch for the end user, one sign-in, no ceremony, no support call on day one, and sealing Intune up to that standard is very much a work in progress. Affinity with a clumsy first-run experience is worse than no affinity with a good one. So: no affinity works today and is documented here, affinity is where we are going, and its guide lands when the low-touch part is real rather than aspirational.
Export your Jamf profiles with their values and map them to Intune. Most turn out to be Jamf tooling that dies with Jamf, or near-empty, so the real build list is tiny. Start here: it shrinks everything that follows.
The stage-and-post enrolment model, the affinity choice you cannot reverse without a wipe, naming that propagates up to the console, and the group and rebuild traps that silently stop config applying.
Enable FileVault by policy so the key actually escrows, understand why a break-glass admin is always visible at pre-boot, and remove the compliance password setting that silently desyncs the encryption credential.
Ordinary applications are the easy part and barely worth a guide. The interesting part is everything that fights back: system-extension VPNs that need an allowlist and a privacy profile or the user gets an approval prompt on day one, connection profiles that resist automation, and the fact that on a no-affinity build the Company Portal is not available to you at all, so one of the usual levers is simply gone. Published once the awkward ones are actually solved rather than handled by hand.
The one everybody actually wants: moving a Mac that has a user, their data and years of state on it, without erasing it. It needs a proven clean build to measure against first, which is what the stages above are for, and it needs the already-encrypted disk problem solving, because a machine encrypted under the old platform has a recovery key the new one has never seen. Published when it has been done for real, not theorised.
Moving from no-affinity to affinity with Platform SSO, so the login password, the directory identity and the FileVault credential are all the same thing. This is where the series is heading, but it is a deliberate re-enrolment project and it only pays off if the end-user experience is genuinely low touch, which is still being sealed up. Published once it has been built and validated on hardware, not before.
Each guide above verifies its own piece. None of them proves the build, and those are different questions. A machine can pass every individual check and still be wrong in the joins, because the failures in this stack are quiet: nothing errors, things simply do not happen, and then happen eight hours later. So finish with an acceptance test, and run it on a machine you are willing to erase.
Take a Mac. Reinstall macOS via Recovery, so you are starting from bare metal rather than a logical wipe. Then watch, and note that what you are checking is as much the timing as the outcome:
# Encryption, and whether the disk is genuinely recoverable
fdesetup status
sudo fdesetup haspersonalrecoverykey
# Who can unlock at pre-boot, and does the bootstrap token exist
sudo fdesetup list
sudo profiles status -type bootstraptoken
# Is the password clean, with no forced change lurking (exit 0 = clean)
dscl . -authonly <account> '<password>' ; echo $?
# Did naming run, and did the config land
scutil --get ComputerName
ls -la /Library/Logs/Microsoft/IntuneScripts/
sudo profiles list
# The controls you rebuilt, on the device rather than in the console
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
spctl --statusLock yourself out deliberately and recover using only what the console gives you. Fifteen minutes, and it is the only thing that turns your break-glass from theoretical into real. Then reboot and confirm the pre-boot screen behaves as you expect, including the break-glass account being visible there, which is correct and unavoidable rather than a fault.
This is the acceptance test that matters to everyone who is not you, and it is worth stating plainly because it is the whole argument for the affinity work.
On a no-affinity machine, which is what these guides build: they open the lid, log in with the local account and password you set during staging, and start working. No sign-in ceremony, no Company Portal, no directory prompt, because there is no directory identity on the device at all. They will notice two things, and both should be in your handover note: an unfamiliar admin account at the pre-boot screen after a reboot, which is expected, and the fact that they must change their password in System Settings and nowhere else, or they will desync the FileVault credential and meet a pre-boot screen that rejects a password they know is right.
On a user-affinity machine, they would sign in with their directory credentials during Setup Assistant instead, and the password they use to log in would be the password they already know, kept in sync with the directory, which removes the entire class of collision described in the FileVault guide. That is the prize, and it is why the series is heading that way.
I have run the no-affinity acceptance test many times and the observations above are what actually happens. I have not run the affinity one, so I am not going to tell you what its screens look like. The drill is the same shape, wipe, watch, verify from the machine, break the glass, hand over, and the expected observations at steps 2 and 5 change. Those land with the affinity stage, once they have been seen rather than reasoned about.
Run this whole drill again on every major macOS release, and after any change to the enrolment policy, since those need a factory reset to take effect anyway. It costs an hour. The alternative is discovering that a release changed something on the morning somebody is locked out, which costs considerably more than an hour and is a worse conversation.
Two earlier guides sit alongside this series. Enforcing FileVault and escrowing the recovery key is the cross-platform grounding and covers both MDMs, so it applies here directly. Rescuing un-escrowed FileVault keys with Escrow Buddy is for a fleet that is already encrypted with no keys on file, but note it is Jamf-based: the tool and the thinking carry over to Intune, the deployment steps do not. An Intune version is on the list. And if you are building clean by following this series, you probably will not need it at all.