Surviving a platform migration without drowning your help desk

A colleague told a consultant, in the plainest possible terms, that if his boss made him change to a different MDM again, he was going to quit.

I have never heard a more accurate summary of how platform migrations feel from the inside.

Almost none of them start as a technical decision. Device management turned out to be bundled into a license the company already owns, or a contract came up for renewal at a number nobody wanted to sign, and the direction arrived downward as a fact. The people who will execute it get the mandate after that, usually with a date attached and no budget for the four months of support load it is about to generate.

Every migration document I have read has a section on tooling, a section on timelines, and a paragraph about "user communications." The help desk gets the paragraph and absorbs the entire event.

The fear worth naming out loud

Security and IT leadership share one specific nightmare, and it deserves saying out loud so it can be planned against: devices sitting fully unmanaged during the transition window. Unreachable, uncommunicable, invisible to compliance.

That gap is real in most migration methods. You remove the old management profile, trigger re-enrollment into the new one, and in between there is a machine on a network with nobody holding the leash. How long it lasts depends on whether the person at the keyboard finishes what they started.

They usually do not.

Break one machine on purpose, first

The best first step in a migration is deliberately destructive, and I resisted it for years because it felt like theater.

Take one representative machine, fully unenroll it, and then sit there and watch. What still logs in, and which apps still function. Which pop-ups appear, in what order, and how many of them a normal human would understand. Write all of it down.

Thirty minutes of vandalism buys an accurate risk picture to hand security and support before anybody commits to a timeline. Not a prediction. An observation.

I skipped this once because I was confident I already knew the dependencies. I was wrong about two of them, and I found out from the help desk queue on a Wednesday, in volume.

Inventory by user impact, not by admin structure

Everyone tells you to catalog your configurations, scripts, and apps before you move. Fewer tell you how to organize the catalog, which is where the value hides.

Do not browse your existing console and copy its own categorization. That structure was designed around how the admin tool thinks. Re-sort everything by user-facing topic instead: identity, enrollment, software, notifications, system extensions. Then compare that list against what the new platform can do.

Gaps then become visible by user impact. "We have no equivalent for this notification suppression profile" reads as a minor omission in an admin list and as forty tickets in a user-facing one. Same fact, and only one version gets prioritized.

A side effect worth having: the audit is where legacy junk goes to die. Antiquated technologies, launch agents nobody remembers writing, profiles targeting a group with two members left. Migrations are forced cleanup, and you should let them be. Porting something blindly because it exists today is how a five-year-old workaround gets a fresh lease.

The parade of prompts

This is the section your migration plan does not have, and it should be the longest one.

When a device leaves one management platform and joins another, the user gets a sequence of unrelated system dialogs, in an order nobody designed, over several minutes. They will click through them out of order. Some they will dismiss outright. Some they will report as a virus.

Here is roughly what comes at them:

The allow-migration prompt. The one thing they actually need to approve. Naturally, it looks like every other prompt they have been trained to ignore.

Re-authentication to the identity provider. Sometimes twice. If a password manager autofills a stale credential, they are stuck at a screen they cannot reason about.

VPN reconnect prompts. The old network extension approval dies with the old enrollment, so the VPN client asks permission again, in language written by a security vendor rather than a human.

Wi-Fi re-selection. Profiles get wiped along with the old enrollment, including simple pre-shared-key Wi-Fi. The user is now on a laptop with no network, being asked to complete a network-dependent process. It sounds absurd because it is.

Wired certificate failures. Certificate-based wired authentication breaks when the certificate payload leaves with the old profile, so the desk-bound person with an ethernet cable ends up worse off than the one on a laptop.

Security agent system-extension dialogs. The least predictable part. Endpoint agents pop approval dialogs during the unmanaged gap, and the practitioner description is exact: it is 50/50 whether something will pop, and it is not the same one every time. You cannot write a screenshot walkthrough for a dialog that appears half the time and varies by machine.

The summary that should get this section funded: all it takes is one wrong click and they call the help desk.

The mitigation that actually works

Hide the whole thing.

Stage a full-screen blocking dialog immediately after enrollment that only lifts once the required profiles are confirmed installed. The user sees one calm screen, goes to get coffee, and the interstitial mess happens behind a curtain. Every prompt they never see is a ticket you never get.

One consultancy went further and built a tool that locks the screen with an un-dismissable dialog, backed by a launch agent that re-triggers on reboot. The reason is behavioral: once the device is unenrolled, the user has no incentive to complete step two. Their machine works. Their email loads. Why would they finish?

Skip that and you get, in their phrase, half-enrolled zombies across your organization that IT then has to clean up one at a time. I have cleaned up a few dozen. Each is a scheduling problem with a human attached.

The conversation with security that goes badly

One clean mitigation for the unpredictable security-agent dialogs is to uninstall the agents before migration and reinstall them after.

Try that sentence on your security team.

It requires explicit sign-off to accept a window in which devices are unmanaged and unprotected, and in the words of people who do this for a living, that generally does not go over particularly well. Sometimes you get it for a pilot cohort. Rarely for the whole fleet. Ask early either way, because the answer determines your staffing.

Your documentation will not be followed

I used to treat the migration guide as the deliverable. Write it well, add screenshots, record a short video, done.

The consultants who do this repeatedly are blunt: if you produce documentation and assume everyone will do exactly what you do, you are wrong. Users interpret instructions in ways you would not predict.

The fix costs an afternoon. Watch pilot users attempt the migration live, without helping, while they read your guide. You will learn that step four is ambiguous, that two people scrolled past the warning, and that one opened the wrong application because your screenshot was cropped.

One detail this exercise reliably surfaces: the user has to be the one authenticating. If a technician does it for them with hands on the keyboard, user affinity binds to the wrong identity and every dynamic group and policy assignment downstream lands wrong. The device looks enrolled. It is enrolled to nobody useful.

Notice does not work, and structure does

A government IT organization moving about 3,000 devices sent a 30-day notice. Ignored. They sent a 7-day notice, also ignored at scale, and ended up phoning individual users through a QR code fallback.

Now the useful contrast. One department with a strong internal tech liaison and 200 devices completed its self-service move in a couple of days. Departments without that structure were, in their words, the most painful thing ever, and only moved once given no choice.

The variable there was ownership, not communication quality. Somebody local cared whether it finished.

That team's fix outlasted the migration: they distributed view and manage access to departmental tech liaisons, so a 200-device department can add and remove apps and reassign devices itself and escalates only real problems. Delegation looked like a loss of control on the org chart and functioned as a fifteen-person expansion of the support organization.

An embarrassing logistics detail

Consultants routinely advise staff at large enterprises to complete their migration from home, or from a coffee shop.

The corporate network requires a managed-device certificate just to get online. The migration strips exactly that certificate. So the safest place to re-enroll a corporate laptop turns out to be an open network the company does not control. Asking network teams for an "enrollment network" with narrow connectivity is still an unusual request, and it gets declined regularly.

Ask for the enrollment network, expect no, plan for the coffee shop.

Eligibility gotchas that fail silently

These are the ones that ruin a weekend, because none of them throw an error.

• Setting a migration deadline before confirming the device is on the required OS version forfeits the guided option for that device. Bulk deadline-setting does not fail loudly, it skips ineligible devices. Audit afterward or you will never know.
• Devices originally enrolled by manual profile install or account-driven enrollment are silently ineligible for the easy guided path. Identify that split before you promise anyone a single process.
• Rotating local-admin password features do not apply retroactively to devices enrolled before the feature was switched on. Those need a full re-enrollment, meaning a second touch on machines you thought were finished.

The two weeks before cutover

Not a project plan. Just what keeps your queue survivable.

1. Staff for double volume, in writing. If a normal week is 120 tickets, plan for 240 and give your manager that number now rather than during.
2. Write three canned responses in advance, for the three failures your test-machine teardown actually produced. The specific dialogs, with the specific next click.
3. Confirm the blocking dialog works on a machine with no network, one with a security agent installed, and one that reboots mid-process.
4. Publish a QR code fallback somewhere a person with no Wi-Fi can reach from their phone. Print it if that is what it takes.
5. Audit deadline eligibility and produce the list of devices that silently skipped. That list is your phone-call cohort.
6. Name a liaison per department and delegate access before cutover. One named human per group beats any all-company email you will ever write.
7. Watch two pilot users do the whole thing with your hands off the keyboard.
8. Get the security agent decision in writing. Uninstall and reinstall, or accept the unpredictable dialogs and staff for them.
9. Book a daily 15-minute check-in for the migration window, and cancel it happily if you do not need it.

Last thought

The technical work in a migration is usually the easy half, and the only half that gets a project plan.

What the help desk absorbs is the distance between how a system was designed to behave and how a distracted person on a Tuesday actually behaves. Better documentation does not close that distance. Better staging and a local human who owns the outcome will.

Nobody gets promoted for a migration that produced no stories. It is still the outcome worth wanting.