Seamless MDM Migration: Effortless Transition for Enhanced Device Management

September 9, 2015

“Just install the product for the new MDM and have it delete the old one… how hard can it be?”

Don’t you just love it when your management decries that something should be technically easy while they are unaware of the constraints that surround the technology, infrastructure, and software? During my career, I have experienced my fair share of hasty decisions leading to problems I’ve then been asked to solve. This is often exacerbated by a software sales guy who over-promises “it should just work out of the box”… Where is that guy at 2 am when you find a bug in their software and have to go through the painful process of backing out your deployment?

Over the last few years, we have helped an increasing number of customers with MDM migrations for their enterprise rugged devices. Most typically going from one of the legacy MDMs (like MSP or Athena) to a newer MDM such as AirWatch. These migrations have ranged from a few hundred devices up to 40,000 devices. As AirWatch has become more popular in the marketplace, it seems that most folks are moving in that direction.

Whether a company is migrating to consolidate their MDM solutions or due to end of life product support, the goals of the migration effort we hear are typically the same:

“We would like to migrate as quickly as possible with no outages and limited changes to our infrastructure.” – Mobile devices (even legacy devices) have become key to the operations of most businesses. Companies can’t afford to have a large portion of their mobile fleet out of service for an upgrade. Additionally, they don’t want to have to change their network or server infrastructure.
“We want a no-touch solution where users or technicians don’t have to manipulate individual devices to migrate them.” For smaller migrations, you can get away with having end-users scan bar codes or sending a technician out to migrate devices, but when you get to 10,000+ devices and hundreds of sites… this gets really expensive really fast.
“We need our repair/depot process to be seamless as we migrate to the new MDM.” – You have to support the devices replacing ones broken in the field. Ideally, you don’t want users to have to wait an hour for a new replacement device to pull down and install its software.

There are dozens of other needs we could list, but these are the fundamental requirements that consistently resonate with our clients.

To be successful in migrating your MDM, there are a few key steps you need to perform: Migration Analysis, Migration Package Creation, Testing and Deployment Support. Whether you do these internally, hire someone, or have the MDM vendor complete them, it’s important that these steps are executed.

Step 1. MDM Migration Analysis and Plan

If you don’t know where you are, it’s gonna be hard to get to your destination. It’s important to understand everything about your current mobile device landscape.
Areas where we start our analysis typically include:

Device Usage Profile – Who uses the devices? When and where do they use them? What are the off-cycle times when you can push a migration package?
Infrastructure Limitations – Do you have any limitations on connectivity, such as bandwidth peak usage times or devices needing specific authentication to get on the network?
Existing Packages – Do you understand your current application deployment packages?
Software Dependencies – What are the priorities or dependencies of the install sequence for your current applications?
Owners – Who owns individual applications? Who is responsible for regression testing changes before they go to the entity responsible for supporting the network? How do you engage the help desk team?
Deployment Freezes – Know when you are and are not able to make deployment to production systems. For example, retailers typically have freezes around the holidays.
Current Device Problem Baseline – You need to understand operationally how the devices are performing to know if you introduce any new issues into production.

Following the completion of your MDM Migration Analysis, you should have the following deliverables:

Migration Plan – Your master migration plan should show all of the teams, expected timelines and dependencies.
Stakeholder Map – Defines who is responsible for what areas of the Migration. E.g. packaging, testing, support.
Package Mapping – Documentation on all of the packages that will be deployed, specifying devices and locations (including dependencies and sequencing).
Support Plan – Defines how you will handle migration issues. Typically you will have some amount of device migration failures and your help desk team must be ready to re-mediate those devices (or have a depot process to swap them).

A migration analysis and the development of a migration plan should take between 1-4 weeks, depending on the size of your device fleet and the variations of devices and software packages.

Step 2. Migration Process and Tooling

We have observed some teams attempt to lay down AirWatch using their Legacy MDM and then expect the new MDM agent to take over as the primary agent on the device. This approach has major consistency issues. There are too many timing hiccups and potential resource conflicts for this to be a repeatable working process.

For the device software migration process, we recommend a clean cut-over process. A hands-free migration approach needs to leverage the static application memory on the device and a device wipe. I see a lot of MDMs recommend that you use barcodes for this, but that requires a physical human to touch every device. We typically recommend avoiding barcode scanning except for devices that need to be remediated.

To develop an automated migration process, you need to perform the following tasks:

Determine what you need to backup before you clean wipe devices – Typically before we wipe a device, will we back up calibration settings, timezone information, network information, and device site information.
Determine how to handle bootstrapping devices when they come back up in a clean wiped state – When your device starts up after a clean boot, you need to start the bootstrapping scripts or tools. On Zebra and Honeywell devices there are different ways to handle this, Zebra has StartupCtl and Honeywell/Intermec has an auto cab. I suggest your tech teams familiarize themselves with how these tools work.
Determine how to get devices back on the network – When your devices startup, you need to understand how to restore network connectivity. There are different ways to do this on different devices types. Generally, on legacy CE devices, you can import specific registry keys to set the device’s network connectivity.
Determine installation and enrollment process for AirWatch (or your new MDM) – After your device has network connectivity, you need to install AirWatch and its associated credentials bin file(s) and trigger AirWatch to enroll the device.
Determine how to set organizational groups and smart groups for your devices – Once your device has enrolled in AirWatch, you need to set the organization group. You can do this by using varied enrollment credentials or by creating a custom Organizational Group Bootstrapper (OGB) that leverages AirWatch APIs. Supposedly, future versions of AirWatch will include some OGB functionality out of the box, but for now, you have to do this custom if you need to set OGs based on custom site criteria.

Generally, you can expect to spend 3-7 weeks developing and testing your migration packages and sorting out variances between device types and configurations.

Step 3. Pilot and Deployment Support

The last hurdle for your successful migration will be your pilot process and the development of migration support procedures. Unfortunately, migration is not as easy as flipping a switch and deploying to all devices. You need to validate your process, identify the failure rates and staff your support team at appropriate levels to deal with any migration issues. The following are the key areas of deployment support to consider:

Migration Rollback – If a device gets stuck in the migration process, you need to be able to send barcodes to the site to roll back (or roll forward) the device to the correct state.
Run Pilots and Update Process – Start your pilot process with a minimal set of devices at a single site. If that is successful, then expend your migration process to all devices at that site. As part of your pilot process, you also need to test rolling back all devices using your failed migration process. Update your process for any issues you encounter and scale to two sites, and then to five and 10 sites.
Reporting Tooling – You must be able to accurately report on your pre-migration and post-migration devices in each system. This includes a report to show that all of the software has successfully been reinstalled on your devices. In addition, include reporting on the performance of your servers and your site network consumption.
Help Desk/Support Team Coordination – During your rollout, you will need your help desk and support teams to help with devices that get stuck in migration or do not migrate properly. A general rule of thumb is that at least 5% of your devices will not migrate without user intervention.
Deployment Scale-up Testing – After you nail your pilot site deployment, you need to scale up your deployments. I recommend doubling your site counts every night until you get within 80% of the available resources for your server (both legacy and new). In general, I have seen peak deployment happen at around 2000-3000 devices per night, but your mileage may vary depending on the complexity of your packages/product structure.

Ideally, you want your migration deployment to happen as quickly as possible, but you have to balance the speed of your deployment with your ability to support migration issues.

At the end of the day, the number of devices and the complexity of your software packages will drive how long it takes to get everything migrated over cleanly. If you have a complex mobile landscape and someone tells you that they can get it migrated over in a week, I recommend that you run quickly in the other direction (they are most likely a sales guy). A well planned and executed migration with minimal downtime can take anywhere from 8 to 20 weeks.

In summary, in order to improve the likelihood of a successful migration: