What happens when a major U.S. university – an R1 institution, no less – decides to migrate tens of thousands of devices from one mobile device management (MDM) solution to another? In this session from JNUC 2022, Stanford University admins reflect upon their massive migration project over to Jamf Pro and the various tools and workflows that helped it to succeed.
Understanding the landscape of Stanford is crucial for grasping why the migration project unfolded the way it did. The university is comprised of seven schools and two hospitals, all with their own technology needs. Of their roughly 1,500 IT staff, about 40% are centralized and 60% are distributed, with admins working on local systems. Requiring a balance between centralized and distributed management, Stanford relies heavily on Jamf sites, which allow admins to determine which objects Jamf Pro users can see and manage. With almost 60,000 devices in use just among the seven schools, it is critical that any solution they employ be able to scale without compromising the user experience.
Custom tools to streamline high-volume device management
The sheer number of devices to migrate and manage has inspired admins at Stanford to develop workflows, integrations and custom apps, such as:
- DataGator: A service for monitoring and remediating changes to devices
- Cardinal Connector: A Jamf automation and webhook assistant to provide a unified view of all device types
- Site Mapper: A tool that uses organizational attributes to determine which Jamf site a device should belong to
Developers also created custom migration apps for both computers and mobile devices to guide users through user-initiated enrollment. These improved success rates for migrating devices – especially important because many users would lose access to mail, contacts and calendars if the migration proceeded incorrectly – and provided some information for the sake of transparency about how Jamf Pro would handle their information.
Migration phases
At the end of 2021, the IT team decided to migrate 26,000 iOS devices to Jamf Pro over the course of six to eight months. They split the process into four phases, as follows:
- Pilot: Admins tested the custom migration app and solicited feedback, taking care to catch bugs before the migration kicked off.
- Migration: They reached out to users about the upcoming push of the migration app and gave instructions for installing it, as well as for using the web-based migration service if they wanted to.
- Enforcement: Admins targeted people who had not performed the migration and reached out to them, eventually letting their devices become unmanaged and fall out of compliance so they would receive additional notifications (and potentially lose access to needed resources). The bulk of migrations occurred during this phase.
- Clean-up: Several thousand devices that hadn’t checked in but had the prior MDM solution installed were purged from the system during this final phase, and some stragglers from the previous phase continued to migrate their devices.
They sum up the lessons learned as:
- Automate: The custom migration app streamlined the process for users and was thus worth the effort.
- Communicate: An online migration guided users with information such as an FAQ and updates.
- Measure: Admins used a real-time dashboard to track which devices were being managed by which MDM solution.
- Reflect: While devising this plan, admins built in several weeks to pause, review the metrics and make any necessary adjustments to their migration process in between phases.
The value of Site Mapper
The Site Mapper tool mentioned earlier in this post is a Python script that automatically assigns devices to the appropriate Jamf site. Putting it together required the services of one junior developer and a couple of Jamf admins; it took two weeks to develop, following the Software Development Life Cycle (SDLC) framework. Its success is a testament to the results that you can get by experimenting with the Jamf Pro API and Jamf webhooks.
Some of the numbers associated with the Site Mapper project break down as follows:
- 21,248 devices automatically mapped to a site with Site Mapper
- 100+ hours of technician time saved
- 17 local IT groups using Site Mapper
- $117.87 yearly operational cost
CI/CD pipelines
The final section of the presentation deals with continuous integration and continuous deployment (CI/CD) development principles, and the pipelines put in place to facilitate them. Watch the full session to learn all about how the admins used a CI/CD workflow to automate configuration updates for the Nudge tool, which prompts users to update their operating system. Using the Git version control system, they were able to set up an automation that has now updated the Nudge configuration profile 72 times since the CI/CD pipeline was implemented in May.
This blog recap could really only cover the highlights of the session, so don’t neglect to watch this fascinating session that is packed with useful insights for IT admins in higher education and elsewhere!
by Category:
Have market trends, Apple updates and Jamf news delivered directly to your inbox.
To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.