Iru Release Notes

For the first time, IT has declarative MDM control over what transfers when a user migrates from an old Mac to a new one.

Everyone who’s gotten a new personal iPhone knows that screen: 'Transfer from iPhone.' You tap it, wait, and Apple transfers everything. It's straightforward and powerful. Hardware refreshes are a natural part of the device lifecycle for employees, but transferring data and preserving settings has historically been a challenge.

Organizations have long wished for Migration Assistant in macOS to work just as seamlessly for their users as it does for consumers, while ensuring the controls they need to ensure organizational security and compliance remain in place. In macOS 26.4, Apple delivered on that wish.

What Apple's Managed Migration Assistant enables

Managed Migration Assistant is an Apple MDM capability that gives IT administrators declarative control over Mac-to-Mac migrations during Setup Assistant. It runs as part of the Automated Device Enrollment flow, scoped via your MDM configuration.

Migration was entirely user-controlled with no enforcement mechanism. IT can now specify which data transfers, which accounts are included, and which security settings apply.

What IT can control

The Managed Migration Assistant declaration exposes four configuration options:

• Required File and Folder Paths
  Define which paths must migrate to the new device. Paths are relative to the user's Home folder, and folder paths require a trailing slash (e.g., Documents/Work/). At the time of this writing, sub-paths are supported, so you can require an entire parent directory while still excluding specific contents within it.

• Excluded Paths
  Specify paths that must not migrate, even if they exist within a required parent directory. In the Migration Assistant UI, users see parent directories only; subfolders are not shown. The declaration still applies correctly at migration time.

• Excluded User Accounts
  Prevent specific user accounts from transferring to the new Mac. Local admin accounts exist to support IT operations, not end users. Migrating one means it arrives on the new device untracked, carrying stale credentials and privileges that were never explicitly granted. If the account is still needed, MDM provisions it fresh.

One thing you cannot control: the user's ~/Library folder always migrates regardless of your configuration. It is not subject to required or excluded path rules.

Managed Migration Assistant in Iru

To configure Managed Migration Assistant in Iru:

1. The admin creates a Migration Assistant library item in Iru and assigns it to the appropriate Blueprint.
2. The device enrolls via ADE. Scope it by assigning the library item to whichever Blueprint covers the devices you want it to apply to: all devices, or a specific subset.
3. During Setup Assistant, the Restore/Migration screen appears (be sure not to skip this screen; see below)
4. Iru applies the declaration from the library item, enforcing the configuration.
5. The user selects their old Mac as the migration source.
6. The migration runs within the parameters defined in the library item.

All four configuration controls are available in the library item: security and privacy settings, required paths, excluded paths, and excluded user accounts.

Iru surfaces the completion data on each device record. The device details tab shows what migrated, what was skipped, and when. The same data is available via the enterprise API device details endpoint.

One gotcha to know before you configure this

If your ADE library item is configured to skip all Setup Assistant screens, Migration Assistant will not run. The Restore screen must be explicitly un-skipped for Managed Migration Assistant to have anything to attach to.

If you're adding this to an existing ADE flow that suppresses all panes by default, audit your current ADE configuration first. If the Restore screen is being skipped, un-skip it before deploying a Migration Assistant configuration. Otherwise, your configuration will be applied to a screen that never appears.

What you get after migration completes

Declarative Device Management provides a completion report after migration runs: what migrated, what was skipped, how much data transferred, and a timestamp. For IT teams that previously had zero visibility into a Migration Assistant run, this is a meaningful operational change. Iru surfaces that data on each device record.

Post-migration, managed app deployment should still run through your MDM, not rely on whatever apps came over from the old Mac. Apps that migrated via Migration Assistant are carry-over copies, not managed deployments. Let your MDM redeploy managed apps as it normally would, so they're in a known-good state rather than a migration artifact.

Start migrating with Iru

Migration has long been one of enterprise IT's least controllable processes. Managed Migration Assistant changes that. Iru delivers it. IT now defines what transfers, what stays behind, and what security posture the new Mac starts with.

See it in action.

Want to bring IT control to your Mac migrations? Book a demo and we'll walk you through Managed Migration Assistant in Iru.

A guide to how Automated Device Enrollment works, where it stops, and how to close the window between enrolled and ready.

Automated Device Enrollment (ADE) was designed to solve the first-touch problem: IT should never have to physically handle a device to put it under management. A device powers on, contacts Apple's servers, and arrives in your mobile device management (MDM) system without imaging, manual configuration, or a staging room. For fleet management at scale, ADE changed what was operationally possible.
But ADE solves the enrollment problem, not the configuration problem. Those are different things, and the gap between them is where most IT teams spend time they didn't plan to spend.

What ADE actually does

When a device goes through ADE, it contacts Apple's servers during Setup Assistant and gets directed to your MDM. At that point, the device is enrolled — it's in your console, it has a management profile, and your MDM can communicate with it.

What it doesn't have yet: your apps, your Wi-Fi credentials, your certificates, your compliance policies, your security restrictions. Those push from your MDM after enrollment, on whatever schedule the next check-in happens to land. Enrollment is the handshake. Configuration is everything that follows.

Under standard MDM, the handshake and the configuration are asynchronous. The device is enrolled and the user gets it. Configurations catch up, usually quickly, sometimes not. The window between enrolled and configured with critical Library Items installed is IT's to manage.

Why the window matters

For most devices in most environments, the window is short enough that it doesn't cause problems. MDM check-ins are frequent, configurations push fast, and by the time the user has navigated through Setup Assistant, enough has arrived to make the device functional.

The window becomes a problem at the edges. A device that reaches a user before its certificate chain has pushed can't authenticate to your network. A device missing its security restrictions is briefly out of compliance. A device that gets through Setup Assistant without FileVault enabled started unencrypted. These aren't common failures, but when they happen, they're invisible unless you're watching for them.

The deeper issue is that MDM cannot tell you with certainty whether a configuration arrived before the user touched the device. Enrolled is a binary state. Configured is not.

What Customize Setup Assistant with ADE changes

The ADE Library Item now holds the device in Setup Assistant until critical configuration is complete. Instead of pushing configurations and waiting for asynchronous check-ins, Iru runs selected Library Items in sequence with a confirmation between each step. The device releases only when every item on the list is done.

To configure this, open the ADE Library Item in Iru, enable "Install Library Items during Setup Assistant," and select which Library Items run during enrollment. Iru holds the device at the Configuring screen until every item on your list confirms installed, then releases it. The user's first interaction with the device happens after your configurations are in place.

The default hold window is 30 minutes, configurable from 1 to 120. The feature works across every ADE-enrolled Apple platform: Mac, iPhone, iPad, Apple Vision Pro, and Apple TV.

Agent-backed execution

The hold window is only as reliable as what can run inside it. Standard MDM sends a configuration payload and waits for a response. That approach works for profiles and restrictions, but reaches its limit for anything requiring active execution: a package with a pre-install dependency, a printer, a custom script.

During Setup Assistant, Iru installs the Iru Agent. Pre-install and post-install scripts execute. Library Item installations proceed with the same robustness as any standard Iru deployment, including items that require scripts.

At launch, this option supports a subset of Library Items. The device exits Setup Assistant with the exact configurations you need in place.

What belongs in the Setup Assistant window

The hold window is for configurations that have to be in place before the device is useful. Start with Wi-Fi credentials, since nothing else works without them. Add certificates that anchor device trust, then security restrictions and compliance-required policies.

Keep the list short. The hold window is a staging environment, not a full deployment pipeline. Loading every Library Item in your Blueprint inflates hold time and raises the risk that a stalled item drags the window to timeout. Five to ten critical items are the right scope.

Everything else belongs in Liftoff, where users can see what's still installing and IT gets confirmation without manual follow-up. Items that ran during Setup Assistant complete before Liftoff runs and never appear in its queue.

Why some configurations are always on

Some configurations like Restrictions, Passcode, Migration Assistant, and FileVault run during every Setup Assistant regardless of what you've selected. They cannot be deselected.

The reason is historical. This mechanism was originally built for education, where students found ways to bypass device restrictions during Setup Assistant before security configurations had a chance to apply. Making these items mandatory closed that window permanently. The same logic applies in any fleet: a device that passes through Setup Assistant without an active Passcode policy missed it. A disk that gets through without FileVault started unencrypted. These items are non-negotiable because the alternative is a guaranteed gap.

Passcode carries an additional implication for macOS. Any local user accounts created during Setup Assistant inherit the device's passcode policy. Without an active policy, accounts created before the device reaches your management layer are exempt from it entirely.

The broader direction

Closing the gap between enrolled and configured is part of a longer arc in Apple device management. As Platform SSO in macOS Tahoe extends enrollment further, the identity layer can complete during setup rather than arriving as a post-login prompt. A held Configuring screen, confirmed Library Item completion, and agent-backed execution are the foundation that makes a fully configured, identity-bound device from first login achievable.

Get started

Customize Setup Assistant with ADE is available now in Iru Endpoint Management. Open the ADE Library Item, enable "Install Library Items during Setup Assistant," and select the Library Items to run during enrollment.

For more information, see our product documentation.

See it in action. Want to see how Iru closes the gap between enrolled and configured? Book a demo and we'll walk you through Customize Setup Assistant with ADE in your environment.