Transition to Android Enterprise management before Android Q

Premigration considerations

Identity

Before IT can perform a migration, it must choose an identity model for its mobile devices. For organizations that require devices to maintain Google's G Suite identity model, which involves end users logging into work-related services via G Suite, managed Google accounts are a good option.

For any other scenario, including G Suite customers that don't want to mandate G Suite identity, managed Google Play accounts would be the simpler model to follow.

In reality, an organization will most likely require a mix of provisioning methods, unless all of its devices run the Android 8.0 Oreo OS or newer.

Minimum OS

Like other management options from vendors such as Sony and LG, Android Enterprise management offers features that are OS version-dependent. Google has backported certain features, meaning they made features from the latest OS available to prior versions, but many of these features still require a minimum version to function.

Running a work profile, for example, is an Android feature that may require a minimum level of the OS. If IT wants to require a passcode on the work profile, its devices must run at least Android 7.0. If IT pros want to require the password to be different from the device passcode, they must run Android 9.0 or later.

UEM and EMM feature support

Not all EMM and UEM tools are created equally, and a feature in one of these tools may not exist in another. Therefore, it's important that IT pros confirm that the features they need are present in their UEM or EMM tool for Android Enterprise, just as they do for features dependent on the OS version.

Grouping

Very few organizations want to migrate everything at once. Most organizations prefer to migrate piecemeal by creating groups, either within an EMM or UEM tool, through Microsoft Active Directory or via another identity provider. Mobile device admins should take this opportunity to ensure existing legacy policies won't cause problems for the devices once they migrate. These policies are unlikely to cause issues, but when the old policies fail, the EMM or UEM logs will fill with errors. This clutter makes it more difficult to troubleshoot genuine issues.

Deployment scenarios

Deployment scenarios for mobile devices break down into four categories: corporate-owned single-use (COSU), which serves as a single-use kiosk, corporate-owned personally-enabled (COPE), BYOD or corporate-owned business-only (COBO). The deployment scenario of a device dictates whether or not IT professionals must fully reset their devices during the migration from Device Admin to Android Enterprise. With COBO, COPE or COSU devices, IT needs to perform a factory reset and then provision them from scratch during a migration to Android Enterprise management.

BYOD deployments, which include a work profile, are different. IT can easily migrate BYOD devices from legacy management to a work profile through the EMM or UEM tool. After this type of migration, legacy policies will stop applying and the new Android Enterprise policies will take over. Unfortunately, not all UEM and EMM tools support this method. MobileIron's UEM tool includes this capability, for example, while VMware Workspace One does not.

Provisioning

To provision these Android devices, devices with COPE and COBO deployment scenarios can make use of near-field communications (NFC) provisioning, QR codes, device policy controller (DPC) identifiers and zero-touch provisioning. Ideally, an organization should fully support zero-touch provisioning because this method is the simplest.

In reality, an organization will most likely require a mix of provisioning methods, unless all of its devices run the Android 8.0 Oreo OS or newer. It is simple to perform QR provisioning for Android devices running 7.0 or later if on a UEM platform. For devices running any OS older than Android 7.0, IT must use a DPC identifier and NFC.

Not ready to migrate?

Google has been banging the Device Admin deprecation drum for a year and a half now, but some organizations simply aren't able to make the move currently. IT professionals who can't migrate their devices yet should consider the following options.

Hold off on refreshing devices

Any new devices purchased within the next few months are likely to run Android Pie. OEMs continue to make OS upgrades available soon after their initial release, however, so Android Q may turn up sooner than expected. If an organization needs to purchase new devices, it should consider sourcing devices that don't run Android Q or that would have Android Pie as the final OS update to keep up with security updates to ensure that the devices remain secure.

Take control of updates

Organizations that have Samsung mobile devices should consider Enterprise Firmware Over-The-Air. This technology allows IT to delay OS updates even after Android Q comes out. Non-Samsung device deployments don't have this luxury, though other inventive methods could achieve the same thing. When an organization delays upgrades, devices may also lose access security updates, which creates a security risk.

Speak to vendors

Android Q doesn't automatically prevent Device Admin APIs from functioning; instead, it requires UEM and EMM tools update their DPC applications to target the Android Q API. IT should reach out to these endpoint management vendors to understand when this may happen.

Whatever option an organization finds to extend legacy management is ultimately temporary. Android Enterprise is the future of Android management, and organizations should adopt it as soon as possible. The benefits of Android Enterprise management will far outweigh the effort required to migrate.