Kandji vs Jamf Pro: Pilot Both MDMs on Real Macs and Score Them

#Current method: why feature lists mislead

To compare 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 and 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 fairly, enrol the same small group of representative Macs in each platform, one platform at a time. Score enrollment, app deployment, compliance and reporting against written criteria agreed before the trial starts. Keep the pilot in an isolated or non-production environment, and confirm product versions and your own permissions before you change anything.

Most MDM comparisons start from vendor feature lists, demos and opinions. That method answers what a product can do, not what your fleet, your identity provider, your network and your team will experience when it does it. Apple documents deployment and management capabilities for Apple devices in Apple Platform Deployment. Both products build on those capabilities, so the useful differences sit in workflow, visibility and operating effort rather than in the existence of a feature.

The baseline friction is usually the same. Teams change criteria after seeing results, test on a single convenient laptop, or judge a platform on an unrepresentative day. The result is a decision that is hard to defend later. For wider context, see Kandji vs Jamf Pro: choosing an Apple MDM with a safe pilot and choosing Miradore, Jamf Pro or Kandji for mixed fleets. This playbook concentrates on the scoring mechanics.

#Improved workflow: criteria first, evidence second

The improved method separates three things: what you decide to measure, what you observe, and how you interpret it. Facts are what the console and the Mac report. Observations are what your testers record. Scores are your judgement, and they should be traceable to the first two.

1. Fix the criteria before enrolling anything. This stops results from steering the rubric. Stop if any stakeholder wants to add a criterion after the trial begins; record it as a follow-up instead.
2. Choose a representative test set. Include at least one Mac for each hardware generation, 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 version and user type you support. A homogeneous set hides the cases that cause support tickets.
3. Run the platforms sequentially on the same Macs, or on matched sets. Sequential runs on one device remove hardware as a variable. Matched sets save time but require equivalent devices.
4. Have an owner record evidence per criterion. Use screenshots, console states, timestamps and the on-device output of read-only commands.
5. Score independently, then reconcile. Two reviewers score separately, then discuss differences. Disagreement shows where the criteria were ambiguous.

Assign roles up front. One administrator holds the minimum console permissions needed to configure each platform. One tester behaves as an ordinary user and does not touch settings. One reviewer owns the rubric and the evidence log. Separating these roles supports least privilege and keeps the tester's experience honest.

#Implementation: running the pilot

These steps are the design of the trial. They are not vendor-specific configuration instructions, because the exact console steps depend on your product versions and licences.

#

Step 1: Write the rubric

For each of the four areas, define a pass condition in plain language and a weighting. For example, an app deployment pass might be that every test app is installed and launches on every test Mac without user action within an agreed window. Choose the window before testing. Record it. Expected evidence is a signed-off rubric document. Stop condition: do not enrol devices until the rubric is agreed.

#

Step 2: Prepare the test Macs and a rollback path

Use devices you can safely re-provision, with no personal or production data and no credentials stored on them. Record each Mac's model, macOS version and current management state before you begin. Capture the starting point with read-only commands such as sw_vers and profiles status -type enrollment. The second reports whether the Mac is enrolled in an MDM and whether enrollment was user-approved or through automated device enrollment.

Confirm that you can return each Mac to an unmanaged state through the supported removal process of whichever platform you are testing, and that you have tested that route on one device first. If a device has Activation Lock or a firmware or recovery constraint, treat it as out of scope unless a human owner has accepted the recovery risk.

#

Step 3: Enrol, observe, record

Enrol the first platform and time the user experience from the first prompt to a usable desktop. Record every manual step, every unexpected prompt and every failure. Re-run the read-only checks on the Mac and compare them with what the console reports. A mismatch between the console and the device is itself a finding about reporting reliability.

#

Step 4: Deploy the same app and configuration set

Use an identical small set on both platforms: one app delivered as a package, one from the App Store, and one configuration profile covering a setting you care about. Equivalent content makes the comparison meaningful. Expected evidence is that each item reports as installed or applied in the console and is confirmed present on the Mac. If an installation reports success but the app is missing, record that as an evidence gap rather than a pass. Our note on diagnosing a Jamf Pro stale last check-in shows how to separate a reporting delay from a real communication fault.

#

Step 5: Test compliance drift deliberately

On an isolated test Mac, change one managed setting by hand and observe how long each platform takes to notice, whether it reports the drift, and whether it corrects it. Do this only on a device you can reset. Record the elapsed time and what an administrator would see. Do not extrapolate a single measurement into a general claim.

#

Step 6: Ask real reporting questions

Pose three questions an operations team asks, such as which Macs are below your minimum macOS version or which have not checked in recently. Measure whether each platform answers directly, and how many steps it takes. Platforms that report well on a small pilot may behave differently at scale, so state that limit in your findings.

#

Step 7: Reset and repeat for the second platform

Return the devices to the starting state, confirm it with the same read-only checks, and run the identical script with the second platform. Do not carry over state that could advantage either product.

#Guardrails

• Isolation. Keep pilot tenants, groups and devices separate from production. Never scope a pilot configuration to a production device group.
• Least privilege. Use named, time-limited administrator accounts with only the roles each task needs. Remove them when the pilot ends.
• No private data. Do not store credentials, recovery keys from real users or production inventory in pilot evidence.
• Version awareness. Record the console release and macOS builds used. Findings are valid for those versions only. Check the Apple deployment documentation and the vendor's current release notes for anything that changes minimum OS support, certificates or installer signing. Related deadlines include the Apple Developer ID Sub-CA expiry, which affects signed installer packages.
• Commercial independence. Trial agreements and vendor support during the pilot should not influence scoring. Record any assistance a vendor gave, because it will not be there for every future problem.

#Validation

A pilot is valid when its results are reproducible and its evidence supports each score. Success is observable: every criterion has a recorded result for both platforms, the console and the device agree or the difference is documented, and two reviewers can reach the same score from the evidence.

1. Re-run the read-only checks on each Mac after enrollment and confirm the management state matches the console.
2. Confirm that each deployed item exists on the device, not only in the console.
3. Confirm that the second platform started from the same recorded baseline.
4. Check that scores trace to evidence entries, and that no criterion was added or reweighted after testing began.

Useful device-side checks are read-only: profiles status -type enrollment and profiles list. The latter lists installed configuration profiles and may need administrator privileges on some macOS versions. Expect the output to show the profiles you deployed. If it does not, investigate before scoring.

#Common mistakes

• Changing the rubric midway. This turns the pilot into a justification for a preferred answer.
• Testing only the newest hardware. Older models and older macOS versions expose most of the real differences.
• Trusting console status alone. A reported success is a claim; the device is the evidence.
• Comparing different content. If one platform gets a larger app set, the comparison is invalid.
• Scoring on administrator impressions. Time the task and record the steps instead.
• Ignoring the cost of leaving. Record how hard it was to remove each platform. Migration cost is part of the decision.

#Recovery

Plan recovery before the first enrollment. Failure containment means a faulty pilot configuration affects only the test Macs and never production.

1. If a device behaves unexpectedly, stop deploying to it and capture the console state and read-only command output as evidence.
2. Remove the device from pilot groups in the console so no further configuration reaches it.
3. Use the platform's supported unenrolment or removal process to return the Mac to an unmanaged state. Run this on a single device first.
4. Confirm recovery by running profiles status -type enrollment and checking that the Mac no longer reports the pilot MDM.
5. If a Mac cannot be returned to a clean state, escalate to the device owner and the platform vendor's support rather than improvising with undocumented steps.

Do not perform erase or reinstall operations as part of routine rollback unless a human owner has accepted the data impact. Pilot devices should hold no data worth protecting, which is why the guardrails matter.

#Measurable outcome

The outcome of this playbook is a defensible decision record, not a predicted saving. Measure the following for each platform and record them with the dates and versions tested: the number of manual steps at enrollment, the time to a usable desktop, the share of deployed items confirmed on-device, the time to detect and correct a deliberate configuration drift, and the time to answer each reporting question.

No figure here is a vendor benchmark; each is your own measurement on your own fleet, and small samples carry uncertainty that you should state. Review the decision on a fixed cadence, for example when your minimum macOS version changes, when a platform ships a major release, or at contract renewal. Adoption is successful when the evidence log lets a colleague who was not in the pilot reach the same conclusion.

#Pilot checklist for a Kandji and Jamf Pro evaluation

1. Rubric written, weighted and signed off before any enrollment.
2. Representative Macs selected and baseline state recorded.
3. Separate roles assigned, with least-privilege administrator accounts.
4. Removal path tested on one device before the full pilot.
5. Identical app and profile set prepared for both platforms.
6. Console state compared with device state for every item.
7. Drift test and reporting questions completed on both platforms.
8. Independent scoring reconciled and linked to evidence.
9. Pilot administrator accounts removed and devices returned to a clean state.
10. Next safe decision recorded: extend the pilot with a larger group, select a platform, or stop and revisit the criteria.