iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in
Apple löst eines der lästigsten Probleme in der Apple-Enterprise-Welt: Mit iOS/iPadOS/macOS 26 könnt ihr eure Geräte direkt im Apple Business Manager zwischen MDM-Lösungen verschieben – ohne Wipe, ohne Nachtschicht, ohne Drama. Fast.
Ab iOS/iPadOS/macOS 26 könnt ihr ADE-enrolled Corporate Devices direkt im ABM einem neuen MDM zuweisen – kein Factory Reset nötig. Ihr setzt eine Deadline, der User bekommt eine Notification, das Gerät enrollt sich neu. Persönliche Daten bleiben erhalten. Managed Apps auf iPhone/iPad werden entfernt und müssen vom neuen MDM neu ausgerollt werden. VPP-Lizenzen wandern nicht automatisch. Vorbereitung ist trotzdem Pflicht.
Was ist neu – und stimmt das wirklich?
In den letzten Wochen macht ein LinkedIn-Post die Runde, der das neue Feature von iOS 26 beschreibt. Kaum gelesen, weckte dieser Post mein Interesse.
Im Kern stimmt er – aber ein paar Details sind ungenau oder fehlen komplett. Ich hab das Ganze gegen die offizielle Apple-Dokumentation, Microsoft Intune Docs und mehrere MDM-Hersteller-Guides gecheckt. Hier kommt der vollständige Faktencheck.

Abb. 1: MDM-Migration bisher vs. ab iOS/iPadOS/macOS 26
Was stimmt (korrekte Claims im Umlauf)
|
Was fehlt oder ist ungenau (wichtige Details)
|
Wie funktioniert das technisch?
Apple hat den nativen MDM-Protokoll-Stack erweitert. Der ABM koordiniert jetzt aktiv den Wechsel zwischen zwei MDM-Servern und kommuniziert gleichzeitig mit beiden. Das Gerät wird vom alten MDM unenrollt und enrollt sich direkt in das neue – alles gesteuert durch das OS, ohne manuellen Eingriff.
Technisch relevant: Das Feature basiert auf Declarative Device Management (DDM). Die Logik läuft direkt auf dem Gerät, wodurch die Abhängigkeit vom MDM-Server reduziert wird. Apple rotiert dabei automatisch sicherheitsrelevante Keys – z.B. den FileVault Personal Recovery Key auf macOS.
| Was bleibt auf dem Gerät, was wird entfernt? |
| Was | iPhone/iPad | Mac |
| Persönliche Daten | Bleiben vollständig erhalten | Bleiben vollständig erhalten |
| MDM-Konfigurationsprofile | Werden entfernt | Werden entfernt |
| Managed Apps (MDM-deployed) | Werden entfernt (*) | Bleiben ggf. erhalten |
| App-Daten (bei Preservation) | Bleiben bei korrektem Setup | Bleiben bei korrektem Setup |
| VPP-Lizenzen | Manuell migrieren! | Manuell migrieren! |
| Activation Lock / Bypass Code | Wird vom neuen MDM neu erstellt | Wird vom neuen MDM neu erstellt |
| FileVault Key (macOS) | N/A | Wird automatisch rotiert |
(*) Managed Apps können bei korrektem Setup preserviert werden: Das neue MDM muss die Apps per await_device_configured installieren, bevor DeviceConfigured gesendet wird. Declarative Managed Apps werden immer behalten.
Voraussetzungen
Bevor ihr loslegt, müssen folgende Punkte erfüllt sein:

Abb. 2: Voraussetzungen auf einen Blick
- Gerät läuft auf iOS 26, iPadOS 26 oder macOS 26
- Gerät ist per Automated Device Enrollment (ADE) enrolled – kein User Enrollment, kein BYOD
- Gerät ist in Apple Business Manager (ABM) oder Apple School Manager (ASM) erfasst
- Neues MDM ist als MDM-Server in ABM konfiguriert (Token-Austausch abgeschlossen)
- APNs-Zertifikat im neuen MDM ist aktiv
- VPP/Apps & Books Token für das neue MDM ist eingerichtet (falls Apps per VPP deployt werden)
- Neues MDM ist vollständig vorbereitet: Profile, Policies, Apps und Scripts nachgebaut
Einschränkungen
|
How-to: MDM-Migration mit iOS 26 – Schritt für Schritt
Phase 1: Vorbereitung (vor dem ersten Klick in ABM)
Die Migration selbst dauert Minuten – aber die Vorbereitung entscheidet über Erfolg oder Chaos. Hier solltet ihr keine Abkürzungen nehmen.
| # | Aufgabe | Prio |
| 1 | Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status | Pflicht |
| 2 | Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail | Pflicht |
| 3 | Compliance-Policies, Security-Baselines und Scripts erfassen | Pflicht |
| 4 | App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs | Pflicht |
| 5 | Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen | Pflicht |
| 6 | VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren | Kritisch |
| 7 | Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout | Empfohlen |
| 8 | User-Kommunikation vorbereiten: Was passiert, wann, was müssen User tun | Empfohlen |
Phase 2: Migration in ABM starten
- Anmelden bei business.apple.com als Administrator oder Device Enrollment Manager
- Im Seitenmenü auf ‚Devices‘ gehen
- Geräte suchen und auswählen (Seriennummer, Order-Nummer oder Filter ‚Eligible Devices‘ nutzen)
- Auf das Gerät klicken → ‚…‘ (Ellipsis-Menü) oder ‚Edit‘ → ‚Assign Device Management‘
- Neuen MDM-Server auswählen
- ‚Add Deadline‘ klicken und Datum/Uhrzeit setzen (kein Deadline = kein automatisches Erzwingen)
- ‚Continue‘ → Prompt lesen → ‚Confirm‘
Hinweis: Ohne Deadline kein Zwang!
Wenn ihr keine Deadline setzt, migriert das Gerät nur bei einem nächsten Erase oder wenn ihr manuell den profiles-Befehl ausführt. Für einen kontrollierten Rollout immer Deadline setzen.
Troubleshooting: „Add Deadline“ nicht verfügbar
Wenn der „Add Deadline“-Button im ABM ausgegraut ist oder gar nicht erscheint, liegt das fast immer an einem der folgenden drei Gründe:
| Problem | Ursache | Lösung |
| OS < iOS/iPadOS/macOS 26 | ABM zeigt die Option erst ab iOS 26 an – das Feature ist OS-seitig implementiert | Gerät auf iOS 26 updaten, dann erneut in ABM prüfen |
| Gerät nur „Assigned“, nicht „Enrolled“ | Migration setzt aktives, laufendes Enrollment voraus – „Assigned“ allein reicht nicht | Gerät normal enrollen, dann Migration starten |
| Gerät im Status „Pending“ | Gerät frisch ausgepackt oder noch im Setup Assistant – Enrollment-Flow noch nicht abgeschlossen | Setup abschließen und einmalig enrollen, dann Option prüfen |
| Enrolled, aber Option fehlt trotzdem | Letzter Check-in zu weit zurück oder MDM-Push ausstehend | Force Check-in über MDM senden, ABM-Seite neu laden |
| Quelle = „Apple Configurator“ | Gerät wurde manuell über Configurator 2 in ABM eingebracht – nicht über Reseller/DEP | Siehe nächster Abschnitt |
| Schnellcheck: Enrolled vs. Assigned
Den Enrollment-Status „Enrolled“ bzw. „Assigned“ findet ihr nicht in ABM, sondern im jeweiligen MDM (z.B. Intune: Geräte → Gerät auswählen → Übersicht). ABM zeigt unter „Geräteverwaltungsdienst“ nur den zugewiesenen MDM-Server – keinen separaten Enrolled/Assigned-Status. Was ihr direkt in ABM prüfen solltet: das Feld „Quelle“ unter Details. Steht dort „Apple Configurator“ → siehe nächster Abschnitt. Steht dort „Apple“ oder ein Reseller-Name → Migration sollte funktionieren, sofern das Gerät auf iOS 26 läuft und aktiv enrolled ist. |
Sonderfall: Quelle „Apple Configurator“ – Migration nicht möglich
Wenn im ABM-Gerätedetail unter „Quelle“ der Wert „Apple Configurator“ steht, wurde das Gerät manuell über Apple Configurator 2 in ABM eingebracht – und nicht automatisch über den Kaufprozess via Reseller oder direkt bei Apple. Die Quelle ist fest gesetzt und lässt sich nachträglich nicht ändern. Die Option „Add Deadline“ erscheint für diese Geräte nicht.
| Optionen und Lösungswege
Option 1 – Einmaliger Reset auf iOS 26 (empfohlen): Factory Reset des Geräts auf iOS 26. Beim Neuaufsetzen enrollt es sich sauber im ADE-Flow. Danach funktioniert die nahtlose MDM-Migration – dauerhaft, ohne weiteren Reset. Der einmalige Wipe ist der „Eintrittsbonus“ für den neuen Mechanismus. Option 2 – Aus ABM entfernen und neu hinzufügen: über Configurator 2 möglich, ändert aber nichts – die Quelle bleibt „Apple Configurator“. Für dieses Problem kein sinnvoller Weg. Option 3 – Für neue Geräte: Geräte künftig direkt über einen Apple Authorized Reseller oder Apple selbst kaufen. Diese landen automatisch mit Quelle „Apple“ bzw. Reseller-Name in ABM und sind von Anfang an für die nahtlose Migration geeignet. |
Phase 3: User-Experience und Monitoring
Was der User sieht, hängt vom Zeitpunkt ab:

Abb. 3: Notification-Verhalten je nach Zeitpunkt bis zur Deadline
| Zeitpunkt | Notification-Verhalten |
| Deadline gesetzt | Tägliche Benachrichtigung |
| 24h vor Deadline | Stündliche Benachrichtigung |
| Letzte Stunde | Benachrichtigung alle 60, 30, 10 und 1 Minute(n) |
| Deadline erreicht | Nicht-wegklickbarer Vollbild-Dialog, Enrollment wird erzwungen |
| Wann erscheint die erste Notification? Kann man das beschleunigen?
Die initiale Notification erscheint bei einem online Gerät in der Regel innerhalb weniger Minuten nach der ABM-Zuweisung. Der Ablauf dahinter: ABM benachrichtigt das alte MDM über das MDM-Protokoll → das alte MDM schickt einen APNs-Push ans Gerät → das Gerät checkt beim alten MDM ein, holt sich die Migration-Instruction und zeigt dem User die Notification an. Ist das Gerät offline, wartet APNs auf die nächste Verbindung. Wichtig: Die täglichen, stündlichen und minuten-genauen Benachrichtigungen aus der Tabelle oben sind der Reminder-Rhythmus für den Fall, dass der User noch nicht reagiert hat – nicht der Zeitplan für die initiale Erstbenachrichtigung. Beschleunigen möglich? Ja – aber nur über das alte MDM: einen manuellen Force Check-in / Sync-Befehl ans Gerät schicken. Das triggert sofort ein Check-in, das Gerät holt sich die Migration-Instruction und zeigt die Notification ohne Wartezeit an. Ein ABM-Sync im neuen MDM hat darauf keinen Einfluss – die User-Notification läuft ausschließlich über das alte MDM und APNs. |
Phase 4: Was auf dem Gerät passiert (User-Flow)
Auf iPhone/iPad:
- User erhält eine Notification ‚Enrollment Required‘
- Tippen auf die Notification öffnet Einstellungen → VPN & Geräteverwaltung
- ‚Enrollment starten‘ antippen
- Gerät startet neu – nach dem Neustart enrollt sich das Gerät automatisch im neuen MDM
- Alle neuen MDM-Konfigurationen werden direkt im Anschluss OTA verteilt
Auf Mac:
- Notification erscheint im Notification Center
- Klick öffnet Systemeinstellungen → Geräteverwaltung
- ‚Enrollment starten‘ → Vollbild-Dialog → ‚Enroll‘
- MDM-Profile werden entfernt, Gerät enrollt sich neu
- Nach erfolgtem Enrollment: alle neuen MDM-Konfigurationen werden OTA verteilt
| Was wenn’s schiefläuft?
Schlägt das Enrollment fehl (z.B. kein WLAN), wird das Gerät nicht mehr vom alten MDM verwaltet und gilt als ‚unmanaged‘. In diesem Fall: Gerät wie ein neu zu enrollendes Gerät behandeln. Es gibt keinen automatischen Rückfall zum alten MDM. |
Wie sieht das konkret für Intune und Workspace ONE aus?
Beide Lösungen unterstützen das Feature. Die Vorbereitung auf Intune-Seite laut Microsoft:
- APNs-Zertifikat in Intune hochladen
- ABM/ASM-Token in Intune registrieren (gegenseitiger Token-Austausch)
- Enrollment Profile in Intune erstellen und Geräten zuweisen
- Danach in ABM: MDM-Server auf Intune umstellen und Deadline setzen
Für Workspace ONE gilt dasselbe Prinzip. Da ich in nächster Zeit den ganzen Prozess selbst teste, folgt dazu ein detaillierter Praxisbericht – Stay tuned.
Best Practices für die Praxis
- Immer mit einer Pilot-Gruppe anfangen: 5–10 Geräte, alles prüfen, dann skalieren.
- Separate ABM-Server-Tokens: Für altes und neues MDM je einen eigenen Token verwenden.
- await_device_configured nutzen: Dadurch können Apps (inkl. deren Daten) preserviert werden – wichtig für nahtlose User-Experience.
- VPP-Migration zuerst planen: Token aus altem MDM ZUERST entfernen, dann im neuen registrieren. Deadline max. 30 Tage bei VPP-Apps.
- User-Kommunikation: Vorab informieren, was passiert. Kein Datenverlust, aber der Enrollment-Dialog kommt – das kann erschrecken.
- Offline-Fälle einplanen: Geräte ohne WLAN nach der Deadline landen im Setup-Assistant, bis sie sich verbinden.
Schreibe einen Kommentar