Evaluating Jamf Pro Against Kandji on a Real Mac Pilot

#Current method

The short answer: run both products against the same small group of real Macs, one after the other, score them against criteria agreed before you start, and keep a tested route back to your current MDM. A Mac can be managed by only one MDM at a time, so the two platforms are compared in sequence, or on separate but equivalent device groups, never together on one device. Do not decide on feature lists or demonstrations alone.

Many teams currently compare vendors through sales demos and feature matrices. That method hides the friction that matters: how your enrolment flow behaves, how patching deadlines reach devices, and whether your scoping model survives contact with your real organisation. Apple documents deployment and management capabilities for Apple devices in Apple Platform Deployment; both products build on those capabilities, so the useful differences are in operation, not in what the platform allows.

Assumptions made here: you have an isolated or non-production validation environment, administrative rights in both consoles, and a pilot group whose owners have agreed to take part. Version-specific behaviour of either product is not asserted in this article, so record the versions you test.

#Improved workflow

Treat the evaluation as a controlled experiment with four stages. Each exists for a reason.

1. Define criteria first. Writing them before the pilot prevents the result being bent to fit a preference.
2. Select a representative pilot. Include different hardware, 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 versions, a remote user and a user with a complex application set.
3. Run identical scenarios. The same tasks on each platform make scores comparable.
4. Score and decide. Weighted scores, with evidence attached, make the decision defensible.

For a worked scoring approach, see pilot both MDMs on real Macs and score them.

#Implementation

Work through the steps below. Each lists its reason, the evidence to capture and when to stop.

1. Write the criteria. Cover enrolment, patching, scoping, reporting, role-based access, and support experience. Weight them by your operational pain. Evidence: a signed-off scoring sheet. Stop if stakeholders cannot agree weights.
2. Choose the pilot group. Ten to twenty Macs is a common starting point, but the size is your judgement, not a documented requirement. Record model, macOS version, and ownership for each.
3. Create a least-privilege pilot admin role in each console, limited to pilot scope. Evidence: a role that cannot see or act on production devices. Stop if scoping cannot be restricted.
4. Test enrolment. Record the number of user interactions, time to a usable desktop, and any manual steps. Use your normal Apple device assignment route where possible, since that reflects production.
5. Test patching. Set an update deadline and observe how and when the pilot Macs are notified and updated. Record failures and the information the console gives you about them.
6. Test scoping. Reproduce two or three real targeting rules, such as a department-specific application and a restricted configuration, and confirm they reach only the intended Macs.
7. Test reporting. Ask the questions your team asks weekly, such as which Macs are out of date or missing disk encryption escrow, and note how much effort each answer takes.
8. Restore the baseline between platforms so each starts from the same state, following the recovery section.

Related reading on choosing between platforms: choosing an Apple MDM with a safe pilot and choosing Miradore, Jamf Pro or Kandji for mixed fleets.

#Guardrails

• Never pilot on executive, shared or business-critical Macs without an agreed fallback.
• Keep credentials, API tokens and private production data out of scoring documents and screenshots.
• Limit each pilot administrator to pilot scope, and revoke access at the end.
• Do not import production device groups wholesale into either console.
• Do not assume behaviour from a version you have not tested; record versions and dates.
• Moving a Mac between MDMs can change which settings and applications it keeps, so test removal on a spare device first.

Deadlines may affect your plan; check the platform notices such as the Developer ID Sub-CA expiry, which can affect installers you deploy during the pilot.

#Validation

A pilot is valid only if the results are repeatable and attributable. Confirm that every scenario was run on both platforms, that each score has attached evidence, and that no pilot setting reached a non-pilot Mac. Review any Mac whose last check-in is stale before counting it as a failure of the platform; see diagnosing stale Jamf Pro check-ins for the diagnosis route. Success is observable: all pilot Macs reach a defined compliant state, and the scoring sheet is complete.

#Common mistakes

• Comparing a tuned platform with an untuned one; give both equal configuration effort.
• Scoring on features you will never use.
• Ignoring the cost of migration, retraining and rewriting automation.
• Letting a vendor-run pilot hide your real enrolment path.
• Treating one failed Mac as proof; look for patterns across several devices.

#Recovery

Before enrolling any pilot Mac, record how you will return it to its previous management state: the original MDM enrolment, its profiles, and any escrowed recovery keys. Confirm recovery keys are held in a location you control before changing management. If a Mac loses its management state mid-pilot, stop, return it to the original MDM using your documented process, and verify it checks in and receives its baseline profiles. Escalate to a human owner if a recovery key cannot be confirmed, and do not proceed with further Macs until it is resolved.

#Measurable outcome

Measure against your own baseline rather than any published figure. Useful measures are the share of pilot Macs reaching compliance, time to compliance after enrolment, manual interventions per device, and time taken to answer your standard reporting questions. Review at the end of the pilot and again after thirty days of the chosen platform in production. No improvement figures are claimed here.

#Checklist

1. Criteria and weights agreed in writing.
2. Pilot Macs selected, owners informed, fallback agreed.
3. Pilot-scoped admin roles created in both consoles.
4. Recovery keys and original enrolment documented.
5. Enrolment, patching, scoping and reporting scenarios run on both platforms.
6. Scores recorded with evidence and versions noted.
7. Pilot access revoked and pilot Macs returned to a known state.
8. Decision recorded, with a review date set.

#Prerequisites and permissions before the pilot starts

#

Accounts and access to confirm in advance

Confirm each item below and file the proof with the pilot record, rather than relying on memory at the point of failure.

• An administrator in your Apple device management portal who can reassign pilot serial numbers between MDM servers, plus a named deputy for the same task.
• Local administrator credentials for every pilot Mac, held in your password manager and tested by signing in on at least one device.
• A written statement from the security team on whether the pilot may read inventory data such as installed applications and user names.
• A named approver who can authorise rollback outside office hours.

#

Baseline capture on each Mac

Before any change, run these read-only commands on each pilot Mac and save the output against its serial number:

1sw_vers
2profiles list -all
3profiles status -type enrollment
4fdesetup status
5systemsetup -getnetworktimeserver
6df -h /

The profiles status -type enrollment output shows whether the Mac is enrolled and whether enrolment was automated. Keep a copy, since it is your evidence of the starting state when you later compare the two platforms.

#Implementation detail for a repeatable run

#

Fix the clock and the script

Use one timed run sheet per Mac, with columns for start time, each user interaction, each manual step and the time the desktop becomes usable. Record times with the same clock, for example a shared stopwatch or the Mac’s own menu bar clock, so comparisons are not distorted by different observers.

#

Verify state on the device, not only in the console

A console can report a command as sent without the Mac having acted on it. After every scenario, confirm on the device:

1profiles list -all
2sudo profiles -P
3softwareupdate --history
4sudo fdesetup status

Compare the device output with what the console claims, and log any disagreement as a finding. Disagreements are often more informative than outright failures.

#

Apply the same patching test twice

Use the same target macOS version and the same deadline window on both platforms. Note whether a Mac was asleep, offline or on battery at the deadline, because these conditions change the outcome and must be controlled before you attribute a miss to the product.

#Expected evidence at each stage

#Monitoring during the pilot

Check the pilot daily for the first week, then twice weekly. Each check should answer four questions: has every pilot Mac checked in within your agreed window, has any Mac reported a failed command, has any non-pilot Mac received pilot content, and has any pilot user raised a support request. Record the answers even when nothing is wrong, so a quiet period is documented as quiet and not simply unrecorded.

On a Mac that appears silent, inspect the unified log for management activity before declaring a fault:

1log show --last 1h --predicate 'process == "mdmclient"' --info

Treat the output as supporting evidence only; do not quote log text in scoring sheets without checking it contains no personal data.

#Realistic failure symptoms

• Setup Assistant appears to hang after network selection. Check connectivity to Apple services and any proxy or filtering that sits between the Mac and the internet before blaming either MDM.
• A profile is listed in the console but absent on the Mac. Confirm the Mac is awake and online, then check that the profile payload is not blocked by a conflicting profile from the previous MDM.
• Escrowed recovery key cannot be retrieved. Stop the pilot for that Mac. Do not turn FileVaultThe KBY LexiconFileVaultFileVault is Apple's built-in full-disk encryption for macOS, protecting data at rest via user credentials and escrowed recovery keys. Read Full Context off and on again as a workaround without approval from the change owner.
• Applications reinstall unexpectedly after switching platforms. Check whether leftover management artefacts or a user-level installer from the first platform remain.
• Scores diverge sharply between two similar Macs. Compare hardware, macOS build and network location before treating this as a product difference.

#Change-control records

Raise one change record per platform switch, not one for the whole pilot. Each record should hold the serial numbers affected, the planned window, the approver, the baseline files, the tested rollback steps, the versions of both consoles in use and the observed outcome. Close the record only after the Mac has checked in to its intended MDM and the device output matches the expectation. Keep a separate log of any deviation from the run sheet, with the time and the person who authorised it.

#Escalation thresholds

Agree these figures before the pilot, and treat the numbers below as starting points for your own judgement and not as vendor guidance.

• Pause the pilot if any non-pilot Mac receives a pilot configuration.
• Escalate to the change owner if more than one pilot Mac cannot be returned to its baseline on the first attempt.
• Escalate to the security lead immediately if a recovery key cannot be confirmed or a credential appears in a screenshot or document.
• Escalate to the vendor only after you hold device output, console output and times for the same event, so the support request can be reproduced.

#Safe rollback actions

1. Stop further changes to the affected Mac and note the time.
2. Confirm the recovery key is available from a location you control.
3. Reassign the serial number to the original MDM server in your Apple device management portal.
4. Remove the pilot platform’s enrolment using the documented process you tested on a spare device, not by deleting files by hand.
5. Re-enrol to the original MDM and run profiles list -all to confirm baseline profiles return.
6. Compare the result with the baseline file captured earlier and record any difference.
7. Revoke the pilot administrator role and rotate any token created for the pilot.

If step four does not leave the Mac in a clean state, keep the device offline from user work, hand it to the change owner and do not repeat the removal on other Macs until the cause is understood.

The next safe decision: if the scores are close, extend the pilot with a second group rather than switching the fleet. Also check platform requirement changes, such as Intune’s move to macOS 15 and later, if Intune is part of your wider estate.