MDM-migrering uten wipe: Dette gjør macOS 26 mulig

Hvis nullstilling av enheter har vært grunnen til at du ikke har samlet Apple-enhetene dine på én MDM-plattform, er den grunnen nettopp borte.

Med macOS 26 Tahoe og iOS/iPadOS 26 innførte Apple MDM-migrering uten wipe – ingen tilbakestilling til fabrikkinnstillinger, ikke noe datatap og ingen fysisk håndtering av enhetene. Migreringen styres via Apple Business Manager, og brukerne får et varsel de kan handle på i løpet av minutter. For IT-avdelinger som administrerer fragmenterte Apple-enhetsparker på tvers av flere MDM-løsninger, er dette konsolideringsvinduet du har ventet på.

Det er også en annen endring som gjør dette mer presserende: De eldre MDM-kommandoene for programvareoppdatering – inkludert MDM-kommandoer, restriksjoner, com.apple.SoftwareUpdate-payloaden og MDM-forespørsler om oppdateringer – svarer ikke lenger på iOS 27, som Apple lanserte 14. september 2026. Hver enhet som oppdateres, havner utenfor rekkevidden til policyer som bygger på disse kommandoene, og det oppstår et hull i administrasjonen som vokser for hver enhet som oppdateres.

Dette innlegget går gjennom hva migreringen innebærer, hvilke krav som gjelder, og hvordan du kan bruke dette vinduet til å samle Apple-endepunktene dine på én plattform for enhetlig administrasjon.

Dette gjør Apples innebygde MDM-migrering

Tidligere krevde det en full nullstilling av enheten å flytte iOS-enheter mellom MDM-løsninger via Automated Device Enrollment. Det eneste alternativet var manuell ny innrullering, og da kunne sluttbrukeren fjerne MDM-profilen – med risiko for uadministrerte enheter. For macOS var ny innrullering uten wipe teknisk mulig, men tungvint i praksis.

Den nye migreringsfunksjonen endrer dette fullstendig. Arbeidsflyten går via Apple Business Manager eller Apple School Manager og lar IT-administratorer tilordne innrullerte enheter til en ny MDM-server – uten tilbakestilling til fabrikkinnstillinger, uten datatap og uten at Activation Lock må fjernes. Det betyr at også skoler og kommuner som bruker Apple School Manager, kan flytte enhetene sine på samme måte.

For brukeren ser det slik ut: Brukeren får et systemvarsel, klikker på Start Enrollment, og migreringen fullføres i bakgrunnen. Administratorer kan sette en frist for migreringen i ABM. Etter hvert som fristen nærmer seg, kommer varslene oftere. Når fristen er nådd, blir migreringen obligatorisk.

Dette overføres ved migreringen

• Administrasjonen av enheten overføres til den nye MDM-en

• Brukerdata og apper forblir intakte

• Status for Activation Lock bevares

• Virksomhetsapper som administreres via VPP, overføres – forutsatt at det er satt opp separate VPP-tokener for begge MDM-ene

• Eksisterende MDM-konfigurasjoner erstattes: Policyer, restriksjoner og samsvarsprofiler fra den gamle MDM-en overskrives av den nye. Konfigurasjonene må gjenskapes i mål-MDM-en og testes før migreringen starter – enhetene kjører under de nye policyene fra det øyeblikket migreringen er fullført

Krav – dette må være på plass

Migrering er ikke tilgjengelig for alle Apple-enheter. Alle kravene nedenfor må være oppfylt før en enhet kan migreres:

• Operativsystem: macOS 26 Tahoe, iOS 26 eller iPadOS 26 eller nyere må være installert

• Innrulleringstype: Enhetene må være eid av virksomheten og innrullert via Automated Device Enrollment (ADE). Enheter som er innrullert via Apple Configurator, må først gjennom en provisorisk eierskapsperiode på 30 dager

• Medlemskap i ABM/ASM: Både kilde- og mål-MDM-en må være registrert som servere i samme konto i Apple Business Manager eller Apple School Manager

• Støtte for MDM-API-er: Begge MDM-løsningene må støtte Apples migrerings-API-er og Declarative Device Management (DDM)

• Tokener: Oppdaterte MDM-sertifikater, servertokener og separate VPP-tokener må være satt opp for begge MDM-ene

BYOD og privateide enheter følger ikke denne migreringsveien. Migreringen gjelder bare enheter som er eid av virksomheten og innrullert via ADE.

DDM-fristen: Derfor kan dette ikke vente

Muligheten for MDM-migrering kommer samtidig som Apple tvinger gjennom en grunnleggende endring i administrasjonsarkitekturen sin. Eldre MDM-kommandoer for programvareoppdatering – mekanismene de fleste virksomheter brukte til å sende OS-oppdateringer til Apple-enheter – svarer ikke lenger på iOS 27. Virksomheter som fortsatt er avhengige av dem, styrer ikke lenger oppdateringene på enheter som har gått over til iOS 27.

Declarative Device Management er et grunnleggende arkitekturskifte. I stedet for at MDM-servere spør enhetene og sender kommandoer reaktivt, lar DDM enhetene ta i bruk konfigurasjoner ut fra deklarative policyer, rapportere status asynkront og fungere konsekvent også når de er frakoblet. For IT-avdelingen betyr det at policyer for programvareoppdatering settes opp som deklarasjoner i stedet for som eldre kommandoer.

Den praktiske konsekvensen er enkel: Hvis dagens MDM-løsning ikke fullt ut støtter DDM, trenger du en ny MDM. Og hvis du trenger en ny MDM, betyr den innebygde migreringsfunksjonen at du kan bytte uten å nullstille hele enhetsparken.

Slutten for Intel-baserte Mac-er: Et naturlig tidspunkt for konsolidering

Tidspunktet betyr noe av en annen grunn også: macOS 26 Tahoe er den siste versjonen som støtter Intel-baserte Mac-er. For virksomheter som allerede planlegger å skifte ut maskinvare, gir den nye migreringsfunksjonen en naturlig mulighet til å samle både maskinvare og administrasjonsarkitektur på en gang. Nye Mac-er med Apple Silicon rulles inn direkte i mål-MDM-en via ADE fra første dag – uten behov for migrering fra gammel løsning.

Slik bruker du vinduet til å samle Apple-enhetene

Migreringsvinduet er åpent nå for virksomheter med enheter som oppfyller kravene. Her er en strukturert framgangsmåte:

• Kartlegg dagens Apple-enheter. Finn ut hvilke enheter som er ADE-innrullert, hvilken OS-versjon de kjører, og hvilken MDM som administrerer dem i dag. Enheter som ikke oppfyller kravene, trenger en egen plan.

• Kontroller at mål-MDM-en støtter Apples migrerings-API-er og DDM. Dette er et absolutt krav. Hvis mål-MDM-en ikke støtter begge deler, vil migreringen ikke fullføres.

• Registrer begge MDM-løsningene i Apple Business Manager. Både kilde- og mål-MDM-en må være satt opp som servere i samme ABM-konto før migreringen kan startes.

• Sett opp separate VPP-tokener for begge MDM-ene. Det sørger for at administrerte App Store-apper overføres riktig til den nye plattformen, uten hull i lisensstyringen.

• Gjenskap konfigurasjonene i mål-MDM-en før du starter migreringen. Policyer, restriksjoner, samsvarsprofiler og apptildelinger bør være på plass og testet på en pilotenhet før migreringen av hele enhetsparken starter.

• Sett en frist for migreringen i ABM, og informer brukerne om den. Brukerne får varsler og kan fullføre migreringen selv. Fristen sørger for at de som henger etter, blir håndtert uten manuelt arbeid.

• Gå over til DDM-policyer for programvareoppdatering med en gang. Eldre oppdateringskommandoer svarer ikke lenger på iOS 27. Sett opp DDM-policyer for oppdatering nå, og kontroller at hver enhet med iOS 27 har en.

For virksomheter som bruker dette vinduet til å samle seg på én plattform, betyr valget av mål-MDM like mye som selve migreringen. Plattformen må støtte Apples migrerings-API-er og DDM, rulle inn enheter via ADE og administrere resten av enhetsparken – Android og Windows – uten å legge til enda en fragmentert konsoll.

Slik passer CapaOne Mobile Manager inn i migreringen

CapaOne-plattformen for endepunktadministrasjon omfatter Mobile Manager, som samler innrullering, konfigurasjon, etterlevelse og levering av apper for iOS, iPadOS og Android i én samlet plattform for styring av endepunkter.

For virksomheter som samler iPhone- og iPad-parken på én plattform, støtter Mobile Manager ADE-basert innrullering via Apple Business Manager og styrer programvareoppdateringer både med eldre MDM og med Declarative Device Management. Den støtter Apples migrerings-API-er, så ADE-innrullerte enheter med iOS 26 eller nyere kan flyttes dit gjennom Apples innebygde migreringsflyt uten wipe.

For virksomheter med blandede enhetsparker dekker Mobile Manager iOS, iPadOS og Android på ett sted, og fjerner de separate MDM-konsollene som i dag gir et fragmentert bilde av etterlevelsen. Innrullering, konfigurasjon, dokumentasjon for etterlevelse, levering av apper og de viktigste fjernhandlingene kjører på én plattform, sammen med Application Manager, Privilege Manager og Security Monitor for full styring av endepunktene.

For virksomheter i EU der etterlevelse for mobile enheter er en del av et bredere dokumentasjonskrav under NIS2, gir Mobile Manager den dokumenterte innrulleringen, konfigurasjonen og policyhåndhevingen som kravene NIS2 stiller til endepunktene forutsetter – for alle administrerte enheter i parken, i ett samlet driftslag.

Apple Business Manager orkestrerer selve migreringen. CapaOne administrerer iPhone- og iPad-enhetene du innrullerer i Mobile Manager, sammen med resten av enhetsparken. Book en demo av CapaOne-plattformen for endepunktadministrasjon for å se hvordan Mobile Manager støtter samling av iPhone og iPad, Declarative Device Management og enhetlig styring av endepunkter i blandede enhetsmiljøer.