Core Architecture

Your First 30 Days as a Jamf Pro Administrator, Part 4: Start Improving the Environment

Published August 12, 2026 • 12 min read

By week four you have a complete picture of what exists, you understand how it behaves, and you have made at least one successful production change through a documented process. Now the work of actually improving the environment begins.

Most inherited Jamf Pro environments have technical debt. Stale policies. Orphaned packages. Logic that made sense three administrators ago and makes no sense now. Documentation that was never written, or was written once and never updated. Week four is about identifying what needs to improve, deciding what to address first, and building the backlog that will guide your next 60 to 90 days. You are not going to fix everything in week four. You are going to stop guessing about what needs fixing and start working from a plan.

The Technical Debt Assessment

Technical debt in a Jamf Pro environment accumulates the same way it does in any operational system: incrementally, through reasonable decisions made under time pressure that nobody ever came back to revisit. The goal of the technical debt assessment is not to judge what came before you — it is to understand what exists so you can decide what to do with it.

Work through each object category systematically. Take notes. Assign a rough severity to each item you flag: High (affects security or operational reliability), Medium (creates unnecessary complexity or confusion), or Low (cosmetic or organizational). These severities will drive prioritization.

Policies

The signs of policy technical debt are consistent across environments:

  • Policies set to Ongoing with no active operational purpose. A software installation that ran successfully once and should have been set to Once per Computer is the most common example. Left on Ongoing, it reinstalls the application on every check-in — usually harmlessly, occasionally not.
  • Policies with no scope. A policy that targets nothing runs on nothing, but it still appears in search results, creates confusion, and represents work someone did that was never connected to an outcome.
  • Disabled policies with no explanation. Disabled is not the same as intentional. Some disabled policies are deliberately preserved as templates or historical references. Others were disabled when something broke and never re-examined. Without documentation, there is no way to tell the difference.
  • Policies with custom event triggers that no script or other policy appears to call. These may be orphaned from a workflow that no longer exists.
  • Policies with identical or near-identical names. Version drift — “Install Chrome”, “Install Chrome v2”, “Install Chrome - UPDATED” — indicates a pattern of creating new policies rather than maintaining existing ones.

Configuration Profiles

  • Profiles with no scope. Like scopeless policies, these run on nothing and serve no purpose in their current state.
  • Monolithic profiles containing multiple unrelated payloads. As discussed in Part 1, these increase the blast radius of any profile change. Rebuilding them into single-purpose profiles is a legitimate improvement, but it should be done carefully because settings may be redistributed to affected devices during the transition.
  • Profiles that appear to duplicate each other partially or entirely. Version drift in profiles looks the same as it does in policies.

Scripts

  • Scripts that no policy calls. Navigate to a script record and check whether any policies reference it. Scripts that are not referenced by any policy are candidates for archiving or deletion, with appropriate caution about whether they may be called via custom event from another script.
  • Scripts with no comments or description. You should be able to read a script and understand its intent within a few minutes. If you cannot, the script either needs documentation or closer scrutiny before it runs in your environment again.
  • Duplicate scripts — scripts that accomplish the same task with slight variations, usually created because the original could not be found at the time the second version was written.

Packages

  • Packages that no policy references and that are not referenced by Patch Management. Old versions of applications are the most common source of package accumulation. These occupy storage space on your distribution point and create confusion when selecting packages for new policies.
  • Packages with ambiguous names — no version number, no application name, no indication of what they contain. These require investigation before you can safely remove them.

Smart Groups

  • Smart Groups with zero members and no policy or profile scope. These are the most clearly orphaned objects in any environment. A Smart Group that targets nothing and is referenced by nothing has no current operational value.
  • Smart Groups used as advanced search substitutes — groups created only to answer a one-time question that were never cleaned up. As noted in Part 1, if you only need a list, use Advanced Search. If you need persistent scope, use a Smart Group.

Categories

Categories organize objects across the console and appear in Self Service. An inherited environment often has inconsistent, overlapping, or meaningless categories accumulated over time. A category cleanup is low-risk and high-visibility — it makes the environment noticeably easier to navigate.

Official documentation: Categories

The Handoff Test

Before building your backlog, apply one more assessment: the handoff test.

If you had to hand this environment off to a successor tomorrow — with no transition time, no knowledge transfer call, no informal context — could they understand it from the documentation and the objects in the console alone and safely operate it?

If the answer is no, that gap is technical debt of a specific kind: institutional knowledge that lives in your head rather than in the environment. It may be the most important category to address. An environment that requires a specific person’s knowledge to operate safely is fragile in a way that orphaned packages are not.

The handoff test is not about whether your documentation is polished. It is about whether the minimum viable information exists. Can someone else:

  • Understand why critical Smart Groups are scoped the way they are?
  • Find the naming convention you have been following?
  • Identify which policies run during enrollment and in what order?
  • Locate the APNs Apple ID and know the renewal process?
  • Find the known exceptions — the one machine that can never receive a certain profile, the user who requires a specific configuration — without asking you?

Wherever the answer is no, add it to the backlog.

Building the Improvement Backlog

The backlog is a prioritized list of identified improvements with enough context to act on them without relying on memory. It does not need to be a project management system. It needs to be somewhere findable, updatable, and honest.

A workable entry includes:

  • What — a specific, unambiguous description of the item
  • Why — the operational or organizational reason it matters
  • Severity — High, Medium, or Low
  • Estimated effort — not hours necessarily, but relative scale: a 15-minute cleanup, a half-day rebuild, a multi-day documentation effort
  • Dependencies — anything that needs to happen before this item can be addressed

Prioritize by the intersection of severity and effort. A High severity item that takes 15 minutes belongs at the top of the list. A Low severity item that takes two days belongs near the bottom. Items that block other items need to be sequenced before the things they block.

Prioritization — What to Address First

Not every item in the backlog is equally urgent. A useful framework:

Address immediately — in week four if possible:

Anything that affects security. Over-privileged accounts identified during the privilege audit in Part 3. Stale accounts with Administrator access that have not been used in months. API credentials using human accounts that should be migrated to API Roles and Clients. APNs certificate ownership that cannot be verified. These are risk surface items, not cosmetic issues, and they compound over time.

Anything that affects operational reliability. A policy set to Ongoing with a destructive or disruptive payload. A package referenced by an active policy that is also the version being deleted. A Smart Group with criteria that excludes devices it should include, causing them to miss a critical profile.

Address in the 30-day window:

Naming convention application — start applying the convention established in Part 3 to all new objects going forward. Do not retroactively rename everything yet, but new objects should conform immediately.

Documentation gaps for critical workflows. Enrollment sequence, APNs Apple ID and renewal process, known exceptions, and the reasoning behind non-obvious Smart Group criteria.

Monolithic profile decomposition for profiles that are actively changed. Profiles that have not been touched in years can wait. Profiles that require regular updates should be decomposed first because they are the ones generating blast radius on every change.

Address in the 60 to 90-day window:

The broader cleanup — orphaned packages, unused scripts, scopeless policies, duplicate objects. This work is important but not urgent. It benefits from understanding the environment well enough to be confident that an object is truly unused before removing it. Three months in, you have that understanding. In week four, you may not yet.

A Word on Deletion

When the time comes to delete objects from an inherited environment, work carefully and without urgency.

Disable before you delete. Disabling a policy, scoping a profile to nothing, or moving an object to an archive category costs you nothing and gives you a recovery path. Leave disabled objects in place for an observation period appropriate to your organization’s deployment cadence. If no one calls, no workflow breaks, and nothing in the logs references them, remove them with confidence.

Never delete the last copy of something you cannot recreate. A script with no comments, no external source, and no version history that is referenced by nothing in the console may still encode important knowledge about how a one-time enrollment configuration was handled. When in doubt, export it first — the Download button on a script’s record saves the raw script before you delete it. A folder of exported scripts costs nothing to keep.

Packages are different from policies and scripts. A package on the distribution point represents real storage. Orphaned packages accumulate meaningfully on cloud distribution points. But before removing a package, verify against the policy list and the patch management configuration that nothing references it. The search functionality in the Packages section will show you which policies currently reference a given package.

Patch Management — Understanding What Your Environment Uses

Patch management in Jamf Pro has evolved significantly. Understanding which approach your inherited environment uses — and what the current options are — is part of your week four assessment.

Jamf App Catalog is the current and recommended path for automated third-party application patching in modern Jamf Pro environments. It provides a curated library of common applications managed directly by Jamf, with automated update delivery that does not require manual package uploads. If your environment is on a current Jamf Pro version and has not yet adopted App Catalog for eligible applications, this is worth noting as a medium-term improvement.

Jamf Pro Patch Management (accessible via Computers → Patch Management) allows administrators to define software titles, upload packages, and create patch policies that update applications to specific versions. This approach requires more manual maintenance — identifying new versions, downloading and uploading packages, updating the patch policy — but offers more control over exactly which version is deployed and when.

Policy-based software deployment — installing and updating applications through standard Jamf Pro policies with package payloads — remains common and is appropriate for applications not covered by App Catalog or patch management, for applications with complex deployment requirements, or for environments that require strict version pinning.

In an inherited environment, you will likely find a mix of all three approaches, possibly applied inconsistently across different applications. Understanding what is in place is the assessment goal. Standardizing the approach is the improvement goal.

Official documentation: Patch Management

Documentation — What to Write and Where to Keep It

The documentation that matters most in a Jamf environment is not a comprehensive reference manual. It is the minimum set of information that allows someone else to operate the environment safely and make informed decisions about it. Start there.

The enrollment sequence. Which PreStage runs for which devices. What it deploys. What the management account is named. What happens if enrollment fails. This is the most operationally critical documentation in most environments and the most often missing.

The critical Smart Group inventory. The Smart Groups that scope your most important policies and profiles. What their criteria are and why. Any groups that exist because of a specific exception or workaround.

The APNs record. The Apple ID used to create the push certificate. Where that account’s credentials are stored. The renewal date. Who is responsible for the renewal. This should be in a secrets management system or a secure location, not in a plain text document — but it needs to exist somewhere findable.

Known exceptions and workarounds. The one device that must never receive a specific profile because it runs legacy software. The enrollment configuration that differs from the standard because of an edge case. The script that runs last because something else must complete first. These are the things that are invisible until they break.

The improvement backlog itself. A living document is more valuable than a comprehensive document written once. Keep the backlog updated as items are completed and new items are identified. The backlog from week four becomes the operational roadmap for months two and three.

Where to keep it: wherever your organization already keeps documentation. The tool matters less than the discipline. A well-maintained OneNote section, a Confluence page, a shared document in your knowledge base — any of these is better than documentation that exists only in someone’s head.

The 30/60/90 Conversation

By the end of week four, you have enough information to have a meaningful conversation with your manager or stakeholders about where the environment stands and where it is going. Frame this not as a list of problems but as a plan.

What exists, what its current state is, and what the known risks are — that is the assessment. What you intend to address and in what sequence — that is the plan. What you need to execute it — whether that is time, tooling, additional access, or stakeholder buy-in for specific changes — is the ask.

A new administrator who arrives with a clear-eyed assessment and a sequenced improvement plan is a significantly different proposition than one who is still reactive after 30 days. The first 30 days were about earning the right to improve things. Days 31 through 90 are about doing it.

What to Produce by the End of Week Four

Week four ends with a documented plan, not a completed environment.

  • A technical debt inventory with severity ratings covering policies, profiles, scripts, packages, and Smart Groups
  • A handoff test assessment — what exists in documentation and what lives only in institutional memory
  • A prioritized improvement backlog with sequenced items and estimated effort
  • Documentation for the enrollment sequence, critical Smart Group inventory, APNs record, and known exceptions — even if that documentation is rough and incomplete
  • An understanding of what patch management approach the environment currently uses and whether it aligns with current Jamf Pro capabilities
  • A 30/60/90-day improvement plan you can discuss with your manager or stakeholders

The environment is not fixed. It is mapped, understood, and on a trajectory toward better. That is exactly right for day 30.

Download: Week 4 Technical Debt & Improvement Backlog workbook (.xlsx) — a fillable workbook to turn observations into a plan: a technical-debt inventory (by object type, with severity and effort), a handoff test for documented-vs-institutional knowledge, a prioritized improvement backlog, and a 30/60/90 plan you can walk a manager through.

SHA256: AF8BE375C5CE0A4E6B02DE1C9A05D01C2B9E0C7D2AD057850E94F7DB8A8E216F

A Note on What Comes Next

This series covered the first 30 days. The work that follows — patch management in depth, the Jamf Pro API, Declarative Device Management, Self Service configuration, advanced scoping patterns, macOS upgrades at scale — is the substance of months two through twelve and beyond.

The habits established in these four weeks do not stop being relevant. The four questions from Part 1 apply every time you create a policy. The three-stage testing pattern from Part 3 applies every time you make a production change. The handoff test applies every time you make a decision that only you understand.

Jamf Pro is a powerful platform. What keeps it under control is the practice of working in it deliberately, documenting what you do, and asking what happens if this does something unexpected before you deploy it.

As you work through your backlog over the coming months, look for evidence that the environment is becoming easier to operate. Fewer emergency changes, fewer duplicate objects, clearer documentation, and simpler workflows are all indicators that technical debt is being reduced.

Additional Resources

  • Jamf Pro Documentation — Authoritative reference. The starting point for any feature you encounter that was not covered in this series.
  • Jamf Training Catalog — The Jamf 300 course covers the API, advanced scripting, and topics that extend naturally from where this series ends.
  • Jamf Nation Community — The institutional memory of the Jamf administrator community. If you have inherited a pattern you do not understand, someone in Jamf Nation has encountered it and written about it.
  • MacAdmins Slack — The #jamf channel for operational questions. The #jamf-api channel when you are ready to start automating against the API. The #macos-updates channel when macOS upgrade season arrives.
  • Jamf Security Recommendations — Worth reading in full once the environment is stable. It covers hardening recommendations that go beyond what a new administrator should tackle in the first 30 days.