ASBMUtil v2026.09.02.0848

Headless MDM migration, in the CLI and the app

Apple's 2026-08-12 API release (Apple School Manager API 1.6 / Apple Business API 2.3) finally exposes the one thing the web UI had been keeping to itself: scheduling a no-erase device management service migration with a deadline. This release wires all of it into asbmutil, on macOS and Linux, and into the ASBMUtil app.

Point a fleet at a new MDM, give it a deadline, and let the device do the rest. The user is prompted, can defer until the deadline, and then migrates without an erase. No more clicking through the web UI one batch at a time.

asbmutil assign --csv-file devices.csv --mdm "Intune" --migration-deadline 2026-10-01T17:00:00Z --confirm

New CLI commands

• assign --migration-deadline <ISO 8601> schedules a migration by submitting ASSIGN_DEVICES_WITH_MDM_MIGRATION_DEADLINE. Deadlines are validated before anything is sent (future, at most 90 days out), and --confirm re-reads every device afterwards to prove a migration is pending with that deadline.
• update-migration-deadline moves an in-progress deadline. Add --allow-past to force the migration right now.
• cancel-migration stops an in-progress migration.
• migration-status reads each device's isMdmMigrationCapable, mdmMigrationStatus (REQUESTED, STARTED, SUCCESS, FAILED) and mdmMigrationDeadlineDateTime. Feed it a CSV and find your stragglers.
• release-devices submits RELEASE_DEVICES from Apple Business API 2.4. It is irreversible, so it requires --yes, and it refuses to run against a School Manager credential.

The app

• Assignments and the multi-select inspector now offer Migrate, Update Deadline and Cancel Migration next to Assign and Unassign. The date picker shows the exact UTC timestamp being sent and refuses past or over-90-day deadlines; Update Deadline can opt into a past deadline to force the migration now.
• Release shows up as an operation only on a Business Manager profile, behind an explicit acknowledgement.
• Confirm-after-submit reconciles every mode's end state: the target server, a pending migration with your deadline, no pending migration, or released.
• A device's detail view gets a Migration section and offers Migrate by Deadline when Apple reports the device eligible, or Update Deadline and Cancel Migration when a migration is already pending.
• The Devices table gains a sortable Migration column and a Migration filter (status, or Eligible / Not eligible). Filter on FAILED and you have your follow-up list.

Everywhere else

The three migration fields, plus releasedFromOrgDateTime, now come back on every device from list-devices and get-devices-info, and land in CSV, TSV and plist exports.

Verified live

Tested against a live Apple School Manager tenant: the migration fields are served on every device and the migration activity types are accepted and complete, even though parts of Apple's School documentation still carry the 1.5 banner. RELEASE_DEVICES is genuinely Business-only; the School host rejects it with 409 ENTITY_ERROR.ATTRIBUTE.TYPE, and the tool now says exactly that. If your tenant has not received the migration release yet, you get the same kind of explanation instead of a bare HTTP error.

Downloads

• macOS: ASBMUtil-<version>.pkg (app + CLI), ASBMUtil-<version>.dmg, or asbmutil-<version>-macos-arm64.zip (CLI only)
• Linux: asbmutil-<version>-linux-amd64.tar.gz

A Note on Signing

These artifacts are unsigned and not notarized (no paid Developer ID). On first launch Gatekeeper will complain — clear the quarantine attribute:

xattr -dr com.apple.quarantine /Applications/ASBMUtil.app
xattr -dr com.apple.quarantine /usr/local/bin/asbmutil

Or build and sign it yourself from source with make build (drop your own Developer ID into .env).

Requirements: macOS 14+ for the app, any recent Linux for the CLI container, and an AxM API account with a client ID, key ID, and PEM. If you already have the CLI configured, the app reads the same keychain profiles — nothing to migrate.

---

Full Changelog: v2026.06.07.2329...v2026.09.02.0848