How to build an enterprise MDM from scratch: Part 4

Profiles, Teams, Migration & Software - The Operational Reality

Once the infrastructure, GitOps, identity, and policies are set up, now comes the operational work, which deals with pushing configurations to devices, organizing your fleet, migrating from your old MDM, and deploying software at scale. This is where MDM stops being a project and becomes a system you operate.

Configuration Profiles

Policies tell you if something is wrong. Configuration profiles make it right. A configuration profile is a payload pushed to devices that enforces settings. Screen lock timeout. Wi-Fi configuration. Certificate installation. Privacy preferences. The device receives the profile and applies the settings to the device so users can't override them.

Most profiles fall into a few categories:

• Security Profiles: Password requirements (length, complexity, expiration), Screen lock timeout, FileVault/BitLocker enforcement, Firewall configuration, etc. These enforce baseline security settings. Users can't weaken them.

• Network Profiles: Wi-Fi configuration (SSID, authentication, certificates), VPN configuration, Proxy settings. These connect devices to your infrastructure. Especially valuable for onboarding as new devices auto-connect to corporate Wi-Fi without manual setup.

• Privacy & Permissions: Camera/microphone access controls, Screen recording permissions, Full disk access for security tools, Accessibility permissions for automation tools. On macOS, these are TCC (Transparency, Consent, and Control) profiles. They pre-approve permissions that would otherwise require user interaction.

• Restrictions: Disable AirDrop, Disable iCloud document sync, Prevent app installation from unknown sources, Block specific system preferences. These limit what users can do. These restrictions should be used sparingly, as over-restriction creates friction and workarounds.

Profile Delivery

Profiles can be delivered in different ways:

• Pushed immediately: Profile is sent to devices as soon as it's configured. Devices receive it on the next check-in.

• Scoped to groups: Profile only applies to devices in specific groups. Engineering gets developer tools. Sales gets CRM integrations.

• Part of enrollment: Profile is applied during device setup. Essential for settings that must be configured before first use.

Common Profile Mistakes

1. Over-restriction: Every restriction has a cost. Block too much, and users find workarounds that are often less secure than what you blocked. Restrict what creates real risk and leave the rest alone.

2. Forgetting removal: What happens when a profile should no longer apply? Some settings persist after profile removal. Some revert. Know the behavior before deploying.

3. Not testing on real devices: Profiles can conflict with each other, with user settings, or with applications. Test on actual hardware before fleet-wide deployment.

4. Ignoring user experience: A profile that repeatedly prompts users or disrupts their workflow will generate complaints and erode trust. Communicate changes before deploying.

Team Strategy

Not all devices are the same. New devices need different handling than production devices. Executive laptops might need different policies than engineering workstations. Most MDM platforms support grouping devices into teams, groups, or organizational units (the terminology varies). Each team can have different configurations.

Common Team Patterns

By Department

├── Engineering
├── Sales
├── Finance
├── Executive
└── IT

Pros: Matches org structure. Easy to explain.

Cons: Doesn't account for device lifecycle.

By Device State

├── New Devices (Onboarding)
├── Production
└── Offboarding

New devices go through setup with aggressive automation. Production devices have stable, tested configurations. Offboarding devices get wiped.

Pros: Handles lifecycle cleanly. New device experience is optimized.

Cons: Requires moving devices between teams.

Hybrid

├── New Devices
├── Engineering - Production
├── Sales - Productio
├── High Security
└── Offboarding

Combine lifecycle and department. Most organizations end up here eventually.

Team Assignment

To make sure devices end up in the right team, the structure is key.

• Default team: New enrollments land in a default team. Good for onboarding flows.

• Manual assignment: Admins assign devices to teams. Works for small fleets, doesn't scale.

• Automatic rules: Devices are assigned based on attributes: serial number, user, and device type. Scales well but requires good data.

• Apple Business Manager/equivalent: Devices can be pre-assigned to teams based on purchase order or serial number. Ideal for automated device enrollment.

Understand what happens during team transitions before moving devices in bulk. A misconfigured team migration can push unwanted changes to production devices.

Migration from Legacy MDM

If you're building MDM from scratch, you might be migrating from something else. This is the hardest part of the entire project.

The Migration Problem

Devices can only have one MDM at a time. Moving from legacy to a new MDM requires:

Removing the old MDM → Enrolling in the new MDM → Without leaving devices unmanaged in between → Without disrupting users → Without breaking applications that depend on MDM configuration

Every step has failure modes.

Migration Strategies

The Big Bang: Remove old MDM, enroll new MDM, all devices at once.

• Pros: Fast. Done in a day (or a weekend).

• Cons: High risk. If something goes wrong, it affects everyone.

When it works: Small fleets (<50 devices). Strong confidence in the new MDM configuration. Tolerance for disruption.

Phased Rollout: Migrate groups of devices over time. IT first, then a pilot group, then department by department.

• Pros: Problems are contained. You learn and adjust.

• Cons: Slow. Running two MDMs in parallel for weeks or months.

When it works: Larger fleets. Risk-averse organizations. Limited IT capacity.

User Self-Service: Provide instructions and let users migrate themselves. IT handles exceptions.

• Pros: Scales well. Users choose convenient timing.

• Cons: Some users never migrate. IT spends time on support.

When it works: Tech-savvy user base. Non-critical devices.

The Enrollment Timing Problem: The trickiest part of migration is when to actually remove the old MDM. Remove too early → device is unmanaged, and it can't receive new MDM enrollment commands. Remove too late → now the old and new MDM conflict, which gives rise to unpredictable behavior.

A General Pattern That Works

1. Enroll the device in the new MDM (through user action or automated enrollment)

2. Verify that the new MDM enrollment succeeded (new MDM sees the device, policies apply)

3. Remove old MDM (via a command from old MDM, or script on device)

4. Verify the removal is completed (old MDM no longer sees the device)

The key is verification between steps. Don't remove the old MDM until the new one is confirmed to be working. An easy way to get this working end-to-end is to automate the migration with policies and scripts. This ensures you never remove the old MDM until the new one is working. Devices that fail enrollment stay on the old MDM until someone investigates

Common Migration Mistakes

• Removing old MDM before new enrollment: Device becomes unmanaged. If automated enrollment fails, you're chasing down devices manually.

• Not communicating with users: Migration affects people. Explain what's happening, when, and what they need to do (if anything). Surprise MDM changes generate tickets.

• Forgetting application dependencies: Some applications depend on MDM-deployed certificates, configurations, or permissions. If the old MDM provided these, the new one must too — before you remove the old one.

• Underestimating timeline: Migration always takes longer than planned. Build in a buffer. Expect edge cases.

• Not having a rollback plan: What if the new MDM has a critical bug? Can you re-enroll devices in the old MDM? Have a plan, even if you never use it.

Software Deployment

MDM isn't just configuration, it's software delivery. Applications, agents, and security tools are all pushed to devices without user intervention.

Software Deployment Options

• Platform App Stores (VPP/ABM): Apple's Volume Purchase Program and similar allow you to purchase (or get free) apps and deploy them through MDM.

  • Pros: Clean installation. Automatic updates. License management.

  • Cons: Limited to App Store apps. Some enterprise apps aren't available.

• Direct Packages: Upload installers (pkg, msi, dmg) to your MDM and push them to devices.

  • Pros: Any software. Custom packages. Internal tools.

  • Cons: You manage updates. You manage compatibility.

• MDM-Maintained Catalogs: Some MDM platforms maintain curated app catalogs with pre-packaged, auto-updating software.

  • Pros: Less maintenance. Updates handled for you.

  • Cons: Limited selection. Dependency on the MDM vendor.

• Script-Based Installation: Push scripts that download and install software.

  • Pros: Maximum flexibility. Can handle complex installation logic.

  • Cons: Brittle. Depends on external URLs. Harder to track success/failure.

Deployment Patterns

• Bootstrap on Enrollment: Install essential software during device setup. Users get a ready-to-use device. Don't wait for them to request software.

  • Security agents (EDR, antivirus)

  • VPN client

  • Core productivity apps

  • IT management tools

• Self-Service Catalog: Provide a catalog of approved software that users can install themselves. Reduces IT tickets. Maintains control over what's available.

  • Developer tools (for those who need them)

  • Optional productivity apps

  • Department-specific software

Common Software Mistakes

• Installing everything on every device: Not everyone needs developer tools. Not everyone needs design software. Scope software to groups that need it.

• Ignoring installation failures: Deployments fail. Network issues, disk space, conflicts. Monitor failure rates. Investigate patterns.

• No uninstall strategy: If you deploy software, have a plan for removing it. Employees leave. Tools get replaced. Licensing changes.

• Assuming success: "I pushed the package" doesn't mean it installed. Verify with policies or inventory queries. Trust but verify.

Bringing It Together

1. Profiles configure devices

2. Teams scope who gets what

3. Migration moves devices from old to new (once)

4. Software delivers applications

The sequence matters:

1. Define your team structure

2. Build profiles for each team

3. Configure software for each team

4. Migrate devices into the right teams

5. Monitor, adjust, iterate

Key Takeaways

• Profiles are powerful but have side effects. Test on real devices. Automate migration verification, do not blindly remove old MDM until the new MDM is confirmed to be working. Treat software deployment like infrastructure: versioned, tested, monitored.

• Team structure should match how you actually manage devices, not your org chart. Migration is the riskiest phase. Plan for it, communicate it, and build in buffer time. Self-service reduces ticket volume.

• Profiles enforce security settings that users can't override. Migration is a window of vulnerability. Minimize time between MDMs. Software deployment is an attack vector, so control what can be installed.

What's Next

Devices are configured, organized, migrated, and loaded with software. In Part 5, the final one, we'll cover the visibility side: logging, observability, what to monitor, and the lessons learned from operating MDM at scale.