Choosing Miradore, Jamf Pro or Kandji for Mixed Fleets

#Current method: how the choice is usually made

Many teams choose a device management platform from feature lists, demos and habit. That works poorly for a mixed fleet because the decisive differences sit in platform coverage, depth of Apple management, and the operational cost of running several consoles. Apple Platform Deployment documents deployment and management capabilities for Apple devices; it does not rank vendors, so the comparison below is an operational method rather than a verdict. Confirm each vendor’s current platform support, licensing and version requirements in its own documentation before relying on any claim here.

The baseline friction to measure first is how many consoles you run today, how long enrolment takes, and how often devices fall out of management. For a related comparison focused on Apple only, see Kandji vs Jamf Pro: Choosing an Apple MDM With a Safe Pilot.

#Improved workflow: requirements first, pilot second

Replace the feature-list comparison with a requirements matrix and a time-boxed pilot. The reasoning is simple: a pilot exposes enrolment, policy and reporting behaviour in your own environment, which brochures cannot.

1. List the platforms and counts you must manage: Mac, Windows, iPhone, Android.
2. Rank requirements as mandatory or desirable, for example Apple enrolment automation, Windows management, Android management, compliance reporting and role-based access.
3. Mark each vendor’s coverage as confirmed, unconfirmed or absent, using vendor documentation only.
4. Eliminate any product with an absent mandatory requirement, or run it alongside another tool by explicit decision.
5. Pilot the remaining candidates against the same test devices and checklist.

The cells are deliberately unfilled: coverage changes between releases, and this page does not assert it. Record the source and date for each cell you fill.

#Implementation: a scoped pilot

Use an isolated or non-production tenant and a small set of test devices per platform. Each step below has a reason, evidence and a stop condition.

1. Create pilot tenants or trials for each candidate. Reason: avoid touching production. Evidence: separate tenant identifiers. Stop if a tenant is linked to production identity or Apple accounts you cannot detach.
2. Assign least-privilege administrator roles. Reason: permission models differ and are part of correctness. Evidence: a role list per console. Stop if only full-administrator access is available and no alternative exists.
3. Enrol one device of each platform. Reason: confirms the enrolment path. Evidence: device appears with correct attributes. Stop if enrolment needs changes to production Apple or identity configuration.
4. Apply one baseline: a passcode or encryption requirement plus one app. Reason: tests policy delivery and reporting. Evidence: device reports compliant state.
5. Remove the device and confirm it returns to an unmanaged state. Reason: proves the exit path.

Check the push certificate lifecycle for Apple management early; see Automating MDM Push Certificate Renewal Before It Silently Expires for why it matters. Jamf Pro is the reference platform for the Apple workflows here, so apply the same checklist to the other two candidates.

#Guardrails

• Use test devices only; never enrol production devices in a pilot.
• Do not share credentials or private data in pilot tenants.
• Grant least privilege and record who holds administrator rights.
• Do not accept vendor claims you have not seen in documentation or reproduced in the pilot.
• Set an end date, after which pilot tenants are closed.

#Validation

Define pass or fail before starting, and score every candidate identically.

1. Enrolment succeeds on every in-scope platform without manual workarounds.
2. The baseline policy applies and is reported within an agreed interval.
3. Inventory attributes match the physical device.
4. Administrator roles restrict actions as intended.
5. Unenrolment leaves no residual management profile.

A candidate passes only if every mandatory item passes. Stale check-ins during the pilot should be investigated rather than ignored; see Jamf Pro Stale Last Check-in: Diagnose and Restore Macs.

#Common mistakes

• Comparing list prices without the same device counts and platforms.
• Piloting only Macs and assuming Windows and Android behave equally well.
• Treating a single console as mandatory without costing a two-tool alternative.
• Skipping the exit test, then discovering migration friction later.
• Using production administrator accounts in the trial.

#Recovery

The pilot is reversible by design. If a test device misbehaves, unenrol it from the pilot console and confirm the management profile is gone in device settings. If a tenant cannot be cleanly closed, stop and escalate to the vendor and the owner of the Apple and identity accounts. Verify recovery by confirming the device no longer reports to the pilot console and that production inventory counts are unchanged.

#Measurable outcome

Measure your own baseline and pilot results rather than quoting vendor figures: time to enrol a device, share of devices reporting within the agreed interval, number of consoles required, and hours of manual remediation per month. Review the decision after one quarter of production use and compare against the baseline. No improvement figures are claimed here because none were measured.

#Checklist: decision and next safe step

1. Requirements ranked and agreed.
2. Vendor coverage cells filled with sourced, dated evidence.
3. Pilot run on test devices with least-privilege roles.
4. Pass or fail recorded for each mandatory item.
5. Exit path tested and pilot tenants closed or retained deliberately.
6. Decision recorded with review date.

#Prerequisites and permissions before the pilot starts

Settle ownership of the accounts a pilot touches before any tenant is created. An MDM trial usually depends on three separate authorities: the person who administers the Apple organisation account, the person who administers the identity provider, and the person who can approve spend or trial terms. Name each one in writing and confirm they are reachable for the full pilot window.

#

Access to confirm in advance

• A named owner for the Apple organisation account who can approve or decline any link between a pilot tenant and Apple enrolment services.
• A named identity administrator who can create a dedicated test group and test accounts, so that no real staff accounts are used.
• A local administrator account on each test Mac, so that profile and enrolment state can be inspected during the exit test.
• A shared, access-controlled location for pilot evidence, with read access for the approvers and write access only for testers.

#

Test device preparation

Record the serial number, operating system version and ownership of every test device before enrolment. On a Mac, these commands give a repeatable baseline:

1sw_vers
2system_profiler SPHardwareDataType | grep -i serial
3profiles list
4profiles status -type enrollment

Save the output as the pre-enrolment record. Repeat it after enrolment and after removal, and compare the three files. Any profile present in the final file but absent in the first is a residual item to investigate.

#Implementation detail: collecting evidence consistently

Scoring only works if every candidate produces the same evidence in the same format. Create one evidence folder per candidate and one subfolder per platform. Use a fixed naming pattern such as candidate, platform, step number and date, so that reviewers can line up results side by side.

#

Evidence to capture at each step

• Enrolment: the time the enrolment began, the time the device first appeared in the console, and the inventory record showing serial number and operating system version.
• Policy delivery: the time the baseline was assigned, the time the console first reported it applied, and a local confirmation from the device itself.
• Role testing: a screenshot or exported list showing what a restricted administrator can and cannot do, plus one deliberate attempt at a forbidden action and its outcome.
• Removal: the output of profiles list after unenrolment, and the console record showing the device removed or marked unmanaged.

Where a console reports a state that differs from the device, treat the device as the source of truth and record the discrepancy as a finding rather than correcting it silently.

#Monitoring during the pilot

Check each pilot console at fixed times rather than when convenient. A daily review at the same hour is enough for a small test group. Record the last check-in time for every test device and note any device that has not reported since the previous review.

On a Mac, local logs help separate a console problem from a device problem. This command shows recent management-related log entries:

1log show --last 1h --predicate 'process CONTAINS "mdm"' --info

Treat the output as supporting evidence only; message wording differs between operating system releases, so quote entries exactly as seen and do not infer meaning beyond what the text states.

#

Signals worth tracking

• Devices that enrolled but never appear in inventory.
• Devices whose reported attributes differ from the physical device.
• Policies shown as pending beyond the agreed interval.
• Administrator actions that succeeded when the role should have blocked them.

#Realistic failure symptoms and first responses

Do not remove profiles by hand until you know which console installed them. Manual removal can hide a defect that the exit test exists to find.

#Change-control records

Even a pilot should leave an audit trail, because the eventual production decision will rely on it. Raise one change record covering the pilot as a whole, and attach individual entries for any step that touches shared systems.

#

Fields to record

• Purpose, start date, planned end date and the person accountable.
• Tenants created, with their identifiers and the person who created each.
• Test devices enrolled, by serial number, and their pre-pilot state.
• Administrator accounts and roles granted, with the date each was removed.
• Any link made to Apple or identity services, and the approver for it.
• Deviations from the plan, with the reason and who authorised them.

Close the record only when tenants are closed or deliberately retained, test accounts are disabled, and the final profile comparison is attached.

#Escalation thresholds

Agree thresholds before the pilot so that nobody has to decide under pressure. The values below are suggestions; adjust them to your own risk tolerance and record the figures you adopt.

• Escalate to the pilot lead: any test device that has not reported for two consecutive daily reviews, or any role test that fails once.
• Escalate to the Apple and identity account owners: any prompt, warning or request to link, transfer or modify a production Apple or identity configuration. Stop work on that step until they respond.
• Escalate to the vendor: a tenant that cannot be closed, or behaviour that contradicts the vendor’s own documentation after one clean retry.
• Escalate to the change approver: any need to extend the pilot beyond its end date or add devices beyond the agreed list.

#Safe rollback actions

Rollback in a pilot means returning each test device and each shared account to its recorded starting state. Work in this order so that dependencies are not broken.

1. Pause any policy assignments in the pilot console so that no further changes reach devices.
2. Unenrol each test device through the console, then run profiles list on the device and compare the result with the pre-enrolment file.
3. Remove any app installed for the baseline test, using the same console that installed it.
4. Remove administrator roles and disable test accounts, recording the date and the person who did so.
5. Close or retain each tenant according to the change record, and note the decision.
6. Confirm production inventory counts and administrator lists match the figures captured before the pilot began.

If a device will not return to its recorded state, isolate it from the network, record its serial number and escalate rather than erasing it, because an erase removes the evidence needed to understand the fault.

The next safe decision is a limited production rollout to one low-risk group with a documented rollback to the previous tool.