Profile2Blueprint 1.4.0

• Nothing is sent to your tenant at launch. The window opens without a page
  selected; the app signs in and reads profiles only once you open Profiles.
• Hand-picked scope mappings count for the automatic classic cleanup. A
  classic group mapped by hand on the Scope tab (where no single group has the
  same name) is covered when the picked platform group is one of the
  Blueprint’s groups, the same rule as for exact-name matches.
• A Blueprint changed after verification isn’t deployed. Right before
  deploying, the app reads the Blueprint again. If its steps or scope changed
  since it was verified, nothing is sent and the app asks you to verify again.
• Waits before a retry are shown. When Jamf asks the app to wait before
  trying again (at most 60 seconds), the Migrate tab and batch migration show
  the wait, with Stop to end it.
• A locked Keychain is named as such. When the Keychain refuses to read a
  client secret, the app says so instead of reporting that no secret is stored.
• Test Connection checks every permission the app reads with: device groups,
  Blueprints and classic profiles. An integration missing one now fails the
  test, with the missing permission named, instead of failing later.
• The Activity Log keeps the last 10,000 entries (was 1,000). It is kept
  while the app runs and starts empty at each launch.
• Settings no longer has a General tab. The app follows the Mac’s Light or
  Dark appearance.
• The deploy confirmation lists the Blueprint as verified. Its groups,
  device count and confirmation sentence come from the verified Blueprint. A
  group that isn’t in the group list is named, and Deploy waits until you
  click Verify Again. When reading the groups again fails, the app keeps the
  last list and shows the error.
• Unmapped classic groups keep their warning. A profile stays “Needs
  attention” until every classic group is mapped to a platform group, so a
  Blueprint that reaches fewer devices always needs your acknowledgement, also
  in batch migration.
• Stop says what happened. Stopping a wait reads “You stopped waiting for
  Jamf; nothing was sent again”, and every failed or stopped deploy leaves a
  History line saying whether it may have started. Stopping during a classic
  scope change or a Restore says the change may already have been made, asks
  you to check the classic profile, and keeps Restore available.
• After a deploy that may have started, Verify Again checks the Blueprint:
  a deployment still pending or deploying is followed as after Deploy, and a
  failed one is reported before Deploy is offered again.
• Reload Profiles waits while a batch migration runs or a migration step
  is busy.
• Menu commands. Profile › Reload Profiles (⌘R), Reload Profile (⇧⌘R),
  Migrate Selected… (⇧⌘M), Open Profile in Jamf Pro (⌥⌘J) and Open Blueprint
  in Jamf Pro (⇧⌥⌘J); File › Export History (⇧⌘E).
• Run Dry Run is one button. The separate Dry run switch is gone; Create
  Blueprint (Not Deployed) is the only button that writes.
• Batch migration shows its deploy confirmation in the same window, has
  Stop during a run, and offers Dry Run and Create as separate buttons.
• History shows the selected action’s details beside the list.
• A hand-picked group counts for the automatic cleanup only while it still
  exists. The Scope tab waits while a saved migration is being read.
• Easier to read. Warnings, statuses and results keep their colored symbol
  with the text in the normal text color, orange is used only for warnings, the
  cleanup warnings are no longer small print, the Blueprint JSON uses
  higher-contrast colors, and the status filter above the profile list is a
  menu that names each status with its count. VoiceOver reads which migration
  step you are on. The window keeps a size its content fits.

Profile2Blueprint 1.3.0

Classic profile cleanup is safer

• Restore Scope stays restored. After a restore, the automatic cleanup is turned off for that migration for good. Before, Refresh Status or a relaunch could unscope the profile again without asking. The automatic cleanup now runs at most once per profile.
• Automatic cleanup only where the Blueprint reaches every device. It runs only when every target of the classic scope is a group that the Blueprint also targets. A profile scoped to all computers, to individual devices, buildings or departments, or to a group the Blueprint doesn’t target is held back with the reason shown, and you can still unscope it by hand. In that case the deploy confirmation no longer promises the cleanup, and the Unscope confirmation names the devices that would lose the profile.
• A scope change that failed never reads as done. Each scope backup now records whether its change reached Jamf Pro. A refused change (a missing permission, say) no longer shows as "unscoped" later. When the outcome isn’t known, the app reads the profile to find out. If it still can’t tell, it says so and offers Restore. Backups from earlier versions are checked this way once.
• Restore is offered right away when the scope change went through but reading the profile back failed.
• Turning off "Allow classic scope changes" stops pending cleanups. The switch is read at the moment of every scope change, so a migration still watching its device report can’t change the scope once the switch is off. Switching tenants, editing a tenant or switching Demo Mode stops the old workspace’s watches.
• A cleanup that comes due while you’re doing something else runs right after it instead of being dropped. When the device report stops refreshing (after 30 minutes, or on an error), the status says so.
• The opt-in can be turned off at any time, also after deploying. It can be turned on only before deploying.

Saved data

• History, scope backups and sessions follow the same rule as the tenants file: a file that can’t be read is copied next to itself (<file>.unreadable-<date and time>) and is never written over. The app says so, and no scope change runs without a working backup file.
• One copy of each file is open at a time, so two workspaces can no longer overwrite each other’s scope backups or sessions.
• When the history or a migration can’t be saved, the app now tells you.
• A Blueprint’s description is saved with the migration and comes back after a relaunch.

Migration steps

• Run Dry Run is turned off once the Blueprint exists. Before, it started the migration over and left Deploy and Verify Again stuck.
• Verify Again no longer makes a Blueprint deployable again while its deployment may still be running (after the polling timed out).
• Reload passes the fetched profile to open migrations, so Create always migrates what the Source tab shows.
• When the mobile device profile list can’t be read (or the macOS one), the other platform’s profiles still show, with the error above the list.
• A device group without a member count shows "unknown", never "0 devices". The deploy confirmation then says "at least" for the total.
• Refresh Status no longer adds the same deployment result to History again.
• Create, Dry Run, Verify and Deploy wait until a migration from an earlier launch is re-attached.
• A dropped connection during the scope change is retried, as sending the same scope twice changes nothing.
• Copy JSON on a profile with credentials copies them concealed and for this Mac only, and clears the clipboard after a minute (JTKit’s secret clipboard).

Text

• History shows Success, Warning and Failed everywhere.
• The status filter uses the same symbols as the badges.
• Unnamed tenants are called "Unnamed Connection", and the picker’s last item is "Edit Connections…", as in Settings › Connections.
• American spelling, curly apostrophes and "Blueprint" throughout.

Fixes the release check found

• Sandbox runs keep scope backups and sessions out of the real files. A -JTKitSandbox run (UI tests) opened the real scope-backups.json and sessions.json for a real tenant’s workspace. Nothing wrote them, because the sandbox network reaches nothing, but now all four files stay in its temporary folder.
• A refused deploy no longer leaves a "confirmed" line in History. The line is written only once the deploy is accepted.
• The migration steps run in order. Once a Blueprint is created, checking eligibility or building the request again is refused instead of moving the migration back a step (which could create a second Blueprint).
• Restore Scope is offered only for a backup it will accept. Looking up a backup and Restore now use the same check.

Install

Download Profile2Blueprint-1.3.0.zip, unzip, and move Profile2Blueprint.app to /Applications. Signed with a Developer ID certificate and notarized. Requires macOS 14 or later.

Profile2Blueprint 1.2.0

Added

• Mobile device profiles. iOS and iPadOS configuration profiles migrate the same way macOS profiles do, verified end to end on hardware: the deployed blueprint takes over the installed profile in place, and removing the classic profile's scope afterwards leaves the device untouched. The profile list covers both platforms with a filter, each profile is matched only against device groups of its own platform, and the description template gains a {platform} token.
• Classic cleanup works on mobile profiles too, behind the same three guards.

Changed

• A payload whose PayloadUUID differs from its PayloadIdentifier is now blocked before anything is created: the Blueprints API rewrites the UUID to match the identifier, so the transform would fail on devices. Typical of uploaded profiles; a clone made in Jamf Pro gets matching identifiers.
• A payload with no settings warns — the Jamf Pro UI refuses to deploy a blueprint containing one.
• The cleanup step explains the failed “Remove Configuration Profile” command Jamf Pro logs after a transform; it is expected.

Fixed

• A blueprint with no name on the server no longer breaks the duplicate-name check.

Install

Download Profile2Blueprint-1.2.0.zip, unzip, and move Profile2Blueprint.app to /Applications. Signed with a Developer ID certificate and notarized. Requires macOS 14 or later.

Profile2Blueprint 1.1.0

Added

• Open in Jamf Pro. Open the configuration profile or its blueprint in the Jamf Pro console. Set the optional Jamf Pro URL on the tenant to enable it.
• Checkboxes in the profile list, as an alternative to ⌘-click when selecting profiles for batch migration.
• Update check, daily and on demand from the app menu or About, with release notes and an in-app download. It can be turned off in About.

Changed

• The tenant badge has been removed from the toolbar. A host override is now shown in the sidebar.

Install

Download Profile2Blueprint-1.1.0.zip, unzip, and move Profile2Blueprint.app to /Applications. Signed with a Developer ID certificate and notarized. Requires macOS 14 or later.

Profile2Blueprint 1.0.1

Accuracy and correctness release, following a cross-reference against Jamf's own jamf-cli and a full pre-publication review.

Install

Download Profile2Blueprint-1.0.1.zip, unzip, and move Profile2Blueprint.app to /Applications. Signed with a Developer ID certificate and notarized. Requires macOS 14 or later.

Eligibility is now accurate about what the API accepts

• 22 payload types are refused by the Blueprints API and are now flagged as blocked before anything is sent, up from 2. Certificates and SCEP, VPN and per-app VPN, Extensible SSO, directory binding, legacy MCX FileVault, global HTTP proxy, web content filter and DNS settings were all graded Ready and then failed at create with Payload disabled. Certificate payloads in particular were reported as merely informational.
• A payload type outside the component's known registry now warns instead of failing with the API's opaque Failed to validate configuration. This is a warning rather than a blocker on purpose: an allow-list goes stale in the dangerous direction, so a type Jamf enables later must not make the app refuse a migration that now works.
• Payload types Jamf Pro spells differently from Apple are blocked (currently com.apple.preferences.users). Rewriting the type would break the rule that every payload type matches the installed profile, so this cannot be fixed automatically.
• Empty values are caught generally, not just the one Wi-Fi key found live. Any empty string or array in a payload is rejected by the API.
• Payloads that will be read-only in the Jamf Pro blueprint UI are now called out before you migrate.

The payload-type tables are instance- and version-specific; the API remains the authority, and the probe date is stated in the warning text.

Verification no longer refuses faithful blueprints

Four documented Jamf Pro string rewrites were being reported as mismatches, which refuses deployment of blueprints that in fact match their source: CR/LF folding, leading and trailing whitespace trimming, extra & and < escaping (Jamf PI-827), and replacement of characters outside the Basic Multilingual Plane. These now appear as explained informational rows, with the remedy where one exists. Values the server omits because they were empty are treated the same way. Genuine corruption is still a mismatch.

Configurable blueprint naming

The blueprint name prefix and suffix, and the description template, are now per-tenant settings on the Connect screen, with a worked example shown as you type. All three are optional, and the defaults render the previous wording exactly. The description template takes {name} and {id} tokens.

Other fixes

• The duplicate-name check ran twice per create, and a blueprint created between the two checks bypassed the rename / skip / open-existing prompt.
• The batch deploy confirmation did not disclose pending classic cleanup the way single deploy does, and both could promise cleanup that would not run.
• Two confirmation and tooltip strings rendered grammar markup literally.
• History showed unredacted messages until relaunch.
• The step indicator disagreed with the section titles, and its final step could never complete.

Validate each migration on a test device before fleet-wide use.

Profile2Blueprint 1.0

First release. A native macOS app that migrates Jamf Pro classic macOS configuration profiles into Jamf Platform Blueprints using Apple's in-place Classic → DDM transform.

Verified end to end against a live Jamf tenant: create, server-side verify, deploy, the in-place transform on a device, and classic scope cleanup with restore.

Install

Download Profile2Blueprint-1.0.zip, unzip, and move Profile2Blueprint.app to /Applications. The app is signed with a Developer ID certificate and notarized by Apple, so it opens without a Gatekeeper warning.

What it does

• Staged migration — fetch → validate → distill (plist → JSON) → map scope → build → create → verify → deploy, with an explicit confirmation gate before anything irreversible.
• Eligibility checks — every classic profile is graded Ready / Needs attention / Blocked, with the reason for each.
• Fidelity verification — identifiers, payload order and count, setting values and scope are compared against the server's read-back before deployment is offered.
• Write allow-list — the HTTP layer refuses any request that isn't a GET, a blueprint create, a blueprint deploy, or (only when explicitly enabled) a scope-only classic profile update.
• Classic cleanup (opt-in) — after a fully clean deployment, the classic profile's scope targets can be removed. The original scope is backed up locally and can be restored.
• Batch migration, persistent sessions, History and Activity logs, and an offline demo mode that needs no tenant.

Requirements

• macOS 14 or later.
• A Jamf Account API integration scoped to the platform environment with device-groups:read, configuration-profiles:read, blueprints:create, blueprints:read, blueprints:deploy — plus configuration-profiles:update only if you enable classic scope changes.

Client secrets are stored in the Keychain and never written to any log.

Validate each migration on a test device before fleet-wide use.