Kandji to Iru Deadline: Upgrade in Place or Migrate Macs to Jamf Pro

KandjiThe KBY LexiconKandjiKandji, renamed Iru in October 2025, is a device management platform that grew up managing macOS, iOS, iPadOS and tvOS through profiles, Blueprints and compliance checks, and added Windows and Android management at the rebrand. Read Full Context is deprecated, and Kandji tenants have until 1 December 2026 to upgrade to Iru. That upgrade keeps your managed devices, configurations and data, and moves the tenant to the Iru domain and sign-in service. Moving to Jamf ProThe KBY LexiconJamf ProJamf Pro is an MDM platform for configuring, securing and inventorying Apple devices, using scoped policies and profiles delivered via Apple's push infrastructure. Read Full Context instead means rebuilding your Blueprints, Assignment Maps and Library Items as Jamf Pro groups, scopes, configuration profiles and policies, then moving each Mac across in Apple Business. Apple’s no-wipe migration only works on Macs running macOSThe KBY LexiconmacOSmacOS is Apple's Unix-based operating system for Mac hardware, forming the platform layer beneath endpoint management, security enforcement and application lifecycle tooling. Read Full Context 26 or later.

The safe order for most teams: complete the Iru upgrade before the deadline, because it takes minutes and keeps access. Then plan any move to Jamf Pro on a schedule you control, using Apple’s migration deadline (more than a day and less than 90 days) and a small pilot first. Do not race a fleet-wide move against the upgrade deadline.

#Current Method: How Kandji (Now Iru) Assigns Configuration

In Kandji, a Blueprint groups similar devices. An Assignment Map inside the Blueprint decides which Library Items each device gets. In the simple view, every Library Item on the map goes to every device in the Blueprint. In the advanced view, conditional blocks hold if/else conditions built from Assignment Rules. When a device checks in, the conditions in each block are evaluated in order. The first true condition wins, and no other condition in that block is checked. Inputs include enrollment type, chip type, FileVault state, Mac family, tags, serial number, OS version and user attributes such as group and department, combined with AND/OR. Parameters apply to every Mac in the Blueprint they are enabled on.

Two habits from this model cause trouble in a migration. First, condition order carries meaning: a device that matches two conditions only gets the first, so copying each rule in isolation breaks the logic. Second, Kandji documents that Classic Blueprints with Assignment Rules are not converted automatically, so older tenants may still carry rule logic that nobody has reviewed since it was written.

The Iru upgrade does not change this model. Iru’s documentation says it builds on Kandji with a new interface, adds Windows and Android management, and puts the web app at {subdomain}.iru.com with the Enrollment Portal at {subdomain}.iru.com/enroll. The old {subdomain}.kandji.io address redirects there.

#Improved Workflow: Upgrade First, Then Choose Your MDM Calmly

The decision is not “Kandji or Jamf Pro by 1 December”. It is “upgrade to Iru by 1 December, then decide whether Jamf Pro fits better”. Iru says managed devices, configurations and data stay with you through the upgrade, which moves the tenant to the Iru domain and authentication service. Its Iru Brand Update page covers the branding changes users see on managed devices. A move to Jamf Pro changes the management service on every Mac, which needs a pilot and a rollback window.

If you are still choosing between the platforms, score them on real Macs first. Our side-by-side Kandji and Jamf Pro pilot scoring method covers that evaluation. This playbook starts once you have decided to move.

The biggest design change is that Jamf Pro splits “which Macs” from “what they get”. Instead of a decision tree per Blueprint, you build smart groups once and scope many profiles and policies to them. Jamf recommends smart groups for scoping and deployment, and advanced searches for reporting. It also warns that heavy nesting of smart groups and circular references between groups are a common cause of server slowdowns.

#Implementation: Build Jamf Pro, Then Migrate a Pilot

#

Phase 1: Prepare both sides

1. Finish the Iru upgrade. Before you start, enable Standard Authentication, sign in with a username and password, and set up MFA. During the upgrade, set up replacement SAML, Google or Microsoft connections. Iru says you cannot reuse your Kandji SSO settings: use a new app in your identity provider or update every ACS URL, Redirect URL, SSO URL and Entity ID. Expected evidence: you sign in at your Iru domain with the passkey created during the upgrade. Stop condition: if Standard Authentication is not listed as Active in the migration mapping, go back and finish the preparation steps before continuing. If you use AD CS, replace the legacy connector afterwards as Iru describes.
2. Export the assignment logic. For each Blueprint, record every conditional block, its conditions in order, the Library Items in each assignment node and every enabled Parameter. Expected evidence: a written map you can review offline.
3. Connect Jamf Pro to Apple Business. Upload the service token to create an Automated Device Enrollment instance. Jamf Pro syncs with Apple every two minutes, so allow for that delay before trusting what the console shows.
4. Move volume-purchased apps deliberately. Apple says to remove the content token from the current service and upload a new one to the destination before migrating. That changes app assignment for every Mac using the token, not only the pilot, so schedule it for when the Macs that depend on those apps move, and reassign any unassigned apps in Jamf Pro straight afterwards, as Apple’s guide instructs. With volume-purchased apps involved, do not set a migration deadline longer than 30 days.

#

Phase 2: Rebuild configuration in Jamf Pro

1. Turn each condition into a smart group. An OS version, Mac family or department rule becomes smart group criteria. Where the Kandji logic relied on first-match order, add explicit exclusions in Jamf Pro scope so a Mac that would have matched two conditions still gets only one result.
2. Rebuild Library Items as profiles and policies. Settings become configuration profiles. Choose computer-level or user-level for each one, and remember that user-level profiles may not apply until the user logs out and back in, or the Mac restarts. Scripts and installs become policies. Pick each policy’s execution frequency on purpose. An Ongoing policy with a recurring check-in trigger runs at every check-in, which Jamf warns can hurt server and client performance.
3. Create a computer PreStage enrollment. Choose the new Automated Device Enrollment instance. Leave Automatically assign new devices off until the pilot passes, and scope only pilot serial numbers. Macs need internet access during Setup Assistant. Review Make MDM Profile Mandatory, Prevent user from enabling Activation Lock and Set Recovery Lock Password (Apple silicon, macOS 11.5 or later).
4. Match configurations before any Mac moves. Apple says the new service must apply configurations that match the old one, and use the await_device_configured key for managed apps, FileVault and Activation Lock configurations, so users keep access during the switch.

#

Phase 3: Migrate a pilot in Apple Business

1. Check eligibility. Macs need macOS 26 or later and Automated Device Enrollment, or, if added with Apple Configurator, they must be past the 30-day provisional period. Macs that do not qualify do not show the deadline option, and bulk actions on them fail and appear in the activity log.
2. In Apple Business, sign in with a role that can assign devices to device management services and manage default platform assignment. Go to Devices > Inventory.
3. Select the pilot Macs. For a batch you can paste up to 1,024 serial numbers, separated by commas. Choose Jamf Pro as the device management service.
4. Select Add Deadline and set a date more than a day and less than 90 days away. Select Continue, read the dialog, then select Confirm. Apple creates an activity you can view or stop.
5. Tell users what to expect. Notifications appear daily, then hourly in the final 24 hours, then at 60, 30, 10 and 1 minutes before the deadline. At the deadline, a Mac shows a full-screen prompt that cannot be dismissed. All users on a Mac see the prompt. Depending on the new service, the user who completes the migration becomes the managed user, or the Mac has no managed user.

On a pilot Mac, this read-only check shows which Automated Device Enrollment configuration the Mac is assigned to, and should now show the Jamf Pro instance:

1sudo profiles show -type enrollment

#Guardrails

• Least privilege. Starting or changing a migration needs an Apple Business role with permission to assign devices to device management services. Give that role to the migration owner and one backup, not the whole team.
• Cancel before it starts. Apple lets you cancel a migration before it starts. The Mac reverts to the original service and its prompts stop. Treat that as your main rollback, and keep the pilot deadline far enough out to use it.
• Do not hide the prompt. Jamf warns that a restriction profile that restricts the Apple ID preference pane in System Settings stops users seeing the migration notification. Check both the old and new configurations for it.
• Keep apps in place. To preserve managed apps, make sure the outgoing service does not send remove-app commands during unenrolment. Declarative managed apps are always preserved. Confirm this setting with Iru before the first batch.
• Protect FileVault. The new service can install a FileVault escrow configuration that rotates the personal recovery key using the bootstrap token. Have that profile scoped before the pilot moves.

#Validation

For each pilot Mac, check that it appears in Jamf Pro inventory and in the smart groups you expect, and that the expected profiles are installed. Compare it with the Kandji map you exported. Confirm that policies at Once per computer frequency ran, and that FileVault escrow and the recovery key rotation are present. Ask the user to confirm VPN, Wi-Fi, sign-on and core apps work. If you scope a policy to the wrong group, removing it from scope does not undo what it already changed, so check scoping before you widen the rollout. For enrolment stragglers, our guide to diagnosing Macs with a stale last check-in in Jamf Pro covers the follow-up.

#Common Mistakes

• Skipping the Iru upgrade because you plan to leave, and risking console access mid-migration.
• Copying conditional rules one by one and losing first-match order, so a Mac ends up in two Jamf Pro scopes that conflict.
• Turning on Automatically assign new devices in the PreStage before the pilot passes.
• Setting a deadline longer than 30 days while volume-purchased apps are still assigned through the old content token.
• Assuming Macs below macOS 26 will move. They are not eligible for Apple’s migration, so plan them as a separate re-enrolment project, or update them first.

#Recovery

Before a Mac starts migrating, open it in Apple Business, choose Change Deadline, and change or remove the deadline. For batches, select the devices and choose Assign or Reassign, or change or remove the deadline. Apple documents that cancelling before the migration starts reverts the Mac to its original service and stops the prompts, so confirm in Apple Business that the Mac shows Iru as its service again. Once a Mac has migrated, recovery means fixing Jamf Pro rather than going back. Correct the smart group or scope. A computer that already has a Jamf Pro record is handled by the re-enrollment settings: if you clear policy logs, scoped policies run again at their next trigger. By default, re-enrollment clears pending and failed commands.

Two failure states need escalation rather than retries. Apple documents that if a migration fails, any previous Activation Lock is removed and its bypass codes are invalidated, then Activation Lock is turned on and only an Organization Administrator in Apple Business can remove it. And if a Mac has no internet after unenrolment, it shows the Wi-Fi picker, so the user must join a network to finish.

#Measurable Outcome

Measure progress with counts from the consoles: the share of eligible Macs on macOS 26 or later, pilot Macs enrolled in Jamf Pro by the deadline, Apple Business activity-log failures, and Macs showing every expected profile. Review these after each batch, and widen the rollout only when the previous batch shows no unresolved failures. Teams still deciding can use a safe pilot for choosing between Kandji and Jamf Pro to set the bar before the first migration.

#Kandji to Jamf Pro Migration Checklist

1. Iru upgrade complete before 1 December 2026, with passkey sign-in and every SSO connection tested.
2. Every Blueprint, conditional block, assignment node and Parameter recorded in order.
3. Jamf Pro Automated Device Enrollment instance created and the volume-purchasing content token moved.
4. Smart groups, exclusions, profiles and policies built, with execution frequencies chosen on purpose.
5. PreStage scoped to pilot serial numbers only, with automatic assignment off.
6. Configurations matched, including FileVault escrow and the await_device_configured key.
7. Pilot deadline set, users told about the prompts, and the cancel path tested on one Mac.
8. Next safe decision recorded: widen to the next batch only after a clean validation pass, and keep Macs below macOS 26 in a separate plan.