Skip to main content

Migration Assistant and MDM Enrollment: What to Expect and How to Fix Common Issues

This article explains expected behaviors and known limitations when using Apple’s Migration Assistant (also called Transfer Assistant) on Macs managed by Swif MDM, along with practical recovery steps if enrollment appears broken after a migration.


Overview

Apple’s Migration Assistant is designed to move user accounts, apps, and data between Macs. It does not migrate MDM enrollments or re-establish MDM trust on the destination Mac. In certain scenarios, migrating from a Mac that was enrolled in a different MDM can leave behind inconsistent management files or references that interfere with proper enrollment on the new device.

When this happens, you may see:

  • A missing or incorrect MDM profile in System Settings

  • MDM commands not reaching the device

  • Swif agent running but device reported as not fully managed

  • Incorrect or stale device states (e.g., disk encryption status)

  • Profile renewal failures such as:
    Enrolling with management server failed. Update to MDM profile contains different serverURL


What Migration Assistant Does and Doesn’t Do

What Migration Assistant can transfer

  • User accounts, home folders, and many app settings

  • Local files, some system preferences, keychains (as applicable)

What Migration Assistant does not transfer

  • An MDM enrollment or a working trust relationship to the MDM server

  • DEP/ADE supervision state on the destination Mac

  • Cleanup or reconciliation of conflicting MDM artifacts from a different MDM vendor

Important note for ADE/DEP:
For Automated Device Enrollment (ADE/DEP) devices purchased through Apple Business Manager (ABM), MDM supervision and assignment are applied during Setup Assistant on the destination Mac if that hardware is listed in ABM and assigned to Swif. Migration Assistant does not change ADE assignment.


Common Scenarios

Scenario A: ADE Mac (assigned to Swif) receives data from a non-ADE Mac enrolled in a different MDM

Expected behavior: The destination Mac remains assigned to Swif via ADE, but migrated MDM-related files from the source can cause conflicts.
Common symptoms: Profile renewal errors, Swif warnings in System Settings, commands fail to reach the device.

Scenario B: Non-ADE to Non-ADE transfer where the source had Swif Installer enrollment

Expected behavior: The destination Mac will not automatically be enrolled. You must enroll again (via Installer or Enrollment SSO) on the destination Mac.
Common symptoms: No MDM profile present after migration; agent not connected until re-enrollment.


How to Verify the Current State

Use these checks on the destination Mac:

  • System Settings → General → Profiles (or Device Management on newer macOS): confirm whether a Swif MDM profile is present.

  • Terminal:

    • profiles status -type enrollment (shows enrollment status)

    • sudo profiles renew -type enrollment (attempt renewal; record the error output)

If sudo profiles renew -type enrollment fails with a “different serverURL” (or similar), it typically indicates conflicting or stale MDM metadata on disk. Follow the recovery steps below.


Recovery Steps (ADE / DEP Devices)

Use these steps if the hardware is in Apple Business Manager and assigned to Swif.

  1. Restart the Mac and try:
    sudo profiles renew -type enrollment
    If it fails, continue.

  2. Remove any non-ADE or conflicting MDM enrollment profile you see in System Settings.

  3. Choose one path:

    • Option 1 (no data loss): After removing the conflicting profile, run:
      sudo profiles renew -type enrollment
      In many cases, this installs the Swif ADE profile successfully.

    • Option 2 (cleanest): Erase the Mac and complete Setup Assistant so it picks up the Swif assignment from ABM, then sign in. ADE will install the correct Swif MDM profile and supervision automatically.

  4. Confirm the Swif MDM profile appears under Device Management and that Swif commands succeed.

Why this works: ADE enrollment is tied to the device’s serial in ABM. As long as the Mac is assigned to Swif in ABM, a renewal or a fresh Setup Assistant flow will re-apply the correct supervised MDM profile.


Recovery Steps (Non‑ADE Devices)

Use these steps if the target Mac is not in ABM or not assigned to Swif.

  1. Remove conflicting MDM profiles in System Settings (if any).

  2. Enroll again using one of the available methods:

    • Swif macOS Installer (Application or Silent installer)

    • Enrollment SSO (Account-Driven Device Enrollment) if enabled by your admin

  3. Complete any on-device prompts to approve the MDM profile (macOS requires admin approval for non-ADE profile installation).

  4. Verify the device appears as enrolled in the Swif console and that commands succeed.

Note: The Swif Installer is intended for new enrollments or migrating from a different MDM. If a Swif profile already exists, installer workflows may skip re-enrollment by design. Remove stale/conflicting profiles first.


Best Practices When Using Migration Assistant with Managed Macs

  • Prefer migrating user data to hardware that is already ADE-assigned to Swif. Complete Setup Assistant first to ensure the supervised MDM profile installs, then run Migration Assistant.

  • Avoid migrating from a Mac that was enrolled in a different MDM vendor directly into a brand-new ADE Mac before the ADE flow completes.

  • After migration:

    • Confirm the Swif MDM profile is present

    • Run a simple MDM command from the console and confirm success

    • Check sensitive statuses (e.g., FileVault) in the Swif console after the first full check-in


Troubleshooting Checklist

  • [ ] Confirm whether the destination Mac is ADE-assigned to Swif in ABM

  • [ ] Remove any non-Swif or conflicting MDM profile from System Settings

  • [ ] Attempt sudo profiles renew -type enrollment and review output

  • [ ] If renewal fails on an ADE device, consider erase-and-enroll via Setup Assistant to trigger ADE

  • [ ] For non-ADE devices, run the Swif Installer or use Enrollment SSO to re-enroll

  • [ ] Validate MDM command delivery and key device states after enrollment


Example Error and Resolution

Symptom: Running sudo profiles renew -type enrollment returns:
Enrolling with management server failed. Update to MDM profile contains different serverURL

Resolution: Remove conflicting profiles, then re-run the renewal command on ADE devices. If it still fails, erase and complete Setup Assistant to trigger ADE. On non-ADE devices, enroll with the Swif Installer or Enrollment SSO.


FAQs

Does Migration Assistant move my MDM enrollment?

No. Migration Assistant does not migrate MDM enrollment or server trust. You must rely on ADE assignment or perform a fresh enrollment on the destination Mac.

Why do I still see a management warning after reinstalling via the Swif Installer?

If the device is ADE-assigned, an installer-based (non-ADE) profile may not clear certain system warnings or supervision expectations. Remove the non-ADE profile and renew ADE enrollment, or erase and complete Setup Assistant so ADE applies the supervised Swif profile.

My device shows incorrect disk encryption status after migration. What should I do?

Complete the proper enrollment flow first (ADE renewal or fresh installer/SSO enrollment), then allow the device to check in. Swif will refresh encryption status during subsequent inventory cycles.


When to Contact Support

Contact Support if:

  • You removed conflicting profiles and renewal still fails on an ADE device

  • MDM commands do not reach the device after successful re-enrollment

  • Device states (e.g., FileVault) do not update after multiple check-ins


Summary

Migration Assistant is great for user data, not for MDM enrollment. For the smoothest outcome, let ADE re-apply the Swif profile during Setup Assistant on ADE hardware, or re-enroll non-ADE devices using the Swif Installer or Enrollment SSO. If you encounter renewal errors that mention a different server URL or missing profiles, remove conflicts and re-trigger the correct enrollment path. In stubborn ADE cases, a clean erase-and-enroll ensures a properly supervised and fully managed state.


Did this answer your question?