Do's and Don'ts When Switching to Workspace ONE UEM

So, you're new to VMware Workspace ONE® and have several devices currently managed by another MDM provider. First off, thank you for trusting us, and welcome to the start of your journey with Workspace ONE! As anyone managing devices for a while will attest, switching MDM providers isn't a task one should begin without proper planning. Fortunately, Workspace ONE UEM can manage multiple device platforms, so you gain flexibility around what platforms should be first on your list to migrate.

Let's look at effectively preparing and organizing yourself to migrate from another MDM to Workspace ONE UEM.

✔ Do Handle NEW Device Onboarding Before Migration

Step 1 to any migration? Stop adding new devices to the old MDM. I know reading this seems like an obvious start. However, administrators often feel pressured (from their management or impending renewals for the old MDM) to speed migration and start "consuming" all the new licenses they purchased with pre-existing devices. You'll save some headaches if you take the time to work out your desired onboarding and functionality for new devices before working out how to migrate the old ones. Apple devices? Lean on Apple Business Manager or Apple School Manager (later referred to as AXM). Windows 10? Look into Drop-Ship Provisioning. Where possible, go the extra step to make a newly enrolled device do things you may not currently allow on your current devices. What about enabling single sign-on, the unified app catalog, and other Hub Services? Focus on employee experience.

Yes, I've grossly simplified the work behind this step (especially if your organization is multi-platform and building out the Anywhere Workspace). This step is a BIG one. You'll need to stage all the apps you'll provide your organization. You'll need to manage the user's identity. You'll need to decide if you're offering ONLY corporate-owned devices or allowing personally-owned devices to enroll, aligning with the corporate policy. What capabilities will personally-owned devices have? What are the implications of managing personal devices? Have you taken GDPR and other privacy laws into consideration?

My point is that new device onboarding is a critical step; when you get it right, it creates a delightful employee experience that ends up encouraging device migration (or ambitiously thinking – self-migration).

❌ Don't Migrate Old Policies and Apps Without Review

As you look to build out your new enrollment flows, resist the urge to recreate your entire policy set one-to-one. MDM/UEM provider switch is the optimal time to rationalize the current policy and application set for applicability. Look at the settings and apps you currently have in place – are they all required? Are they relevant? Maybe you no longer need those 300 Legacy GPOs as you look to manage Windows 10 with Workspace ONE UEM? Perhaps some of the functionality of those GPOs are better handled in Workspace ONE UEM's Baselines functionality? Are you distributing scripts to apply settings that are now managed directly in the platform's respective MDM specifications?

Say it with me – "I will not migrate everything without review."

✔ Do Understand Current Device Migration Restrictions

The capabilities of each endpoint differ from release to release and vendor to vendor. Additionally, you need to understand what portion of your devices are corporate-owned or personally owned. OS version, Vendor (Google, Apple, and Microsoft), and Ownership play a considerable role in determining how heavy-handed you can be in a migration scenario. Talking ownership, let's go back to the employee experience I mentioned in step 1. In a corporate-owned ownership model, perhaps replacing older devices with new devices may be better tolerated than the end-user self-enrolling. Replacement migrations also help users with older devices to provide feedback on the unique experience you are delivering. But what if those corporate devices have personal data? How locked-down or managed were those devices? Do you need to adhere to any industry standards for the operating system? You know your organization and end-users best. Lean on your own experience (and don't be afraid to ask the security and legal teams as they can help drive success).

From an endpoint vendor perspective, let’s look at a few examples of how this becomes critical. First, regarding Apple devices, supervision and automated enrollment (with AXM) factor heavily into how you design your migration flow. If devices enrolled automatically with AXM, your old MDM might have restricted the user from unenrolling the device (i.e., non-removable MDM). Such a configuration means you may be required to have a middle step (app-based or API-based) that initiates the unenrollment from the previous MDM since the end-user can't do it. Additionally, supervision on iOS can survive wipes, while macOS supervision depends on the enrollment type after each wipe. Second, regarding Android, are the devices Android enterprise managed, or is there an extra OEM management layer (such as Samsung Knox, Zebra, and so on).

Depending on the restrictions currently on the devices, you may want to engage the help of VMware Professional Services or a 3^rd-party specializing in device migrations (such as Exodus or EBF Onboarder).

❌ Don't Leave Variability Out of Your Migration Process Testing

Congratulations, you have new devices onboarding into Workspace ONE and you understand the current state of your device fleet. You're ready to start testing your migration flows. Testing is critical. Find ways to break your migration process and see what happens. Thinking from an Apple perspective, some ways to test the resiliency of your migration process might include:

• Is the device logged into iCloud?
• Is the device low on power?
• Is the device on Cellular or Wi-Fi?
• What if the user gets a call during the migration process?
• What if the user is in a different region (or country)?
• Does the migration process use any type of 3^rd-party migration app, and does it follow accessibility requirements? (Read more on inclusive design at Apple.)
• How do you restart a migration that gets interrupted?

Each platform may have some unique characteristics or behaviors that may alter how a migration process would proceed in an unexpected condition. Find these ahead of time before it's happening to your employees on migration day.

✔ Do Start Small with Your Migration

This one may also seem obvious, but it deserves some discussion. Testing your migration with small groups initially helps you identify missing scenarios before scaling up to larger groups. Hopefully, you'll spend less time fighting fires and instead build excellent working relationships with key internal and external stakeholders. Honestly, end-users want the same thing you do – a process that works as advertised so they can seamlessly continue their day.

You may consider starting a migration process as follows:

1. Small IT Trial #1: A small group of IT participants which, ideally, provide detailed feedback.
2. Expanded IT Trial #2: An expanded group of IT participants, including individual contributors and IT management.  This trial is also a great point at which to onboard and train IT Support and Helpdesk staff.
3. Small Line-of-Business (LOB) Trial #1: Small group of end-users in your business groups representing each group's day-to-day. (Also include any lagging IT users).
4. (Optional) Expanded LOB Trial #2: An expanded group of end-users from business groups (if required).
5. Production Rollout: Go group-by-group in the method that makes sense for your business (particularly if your company has seasonal or time-based critical periods).

By starting small and scaling out, you'll build confidence in your process (both within IT and your organization as a whole). Your help desk will tell tales of your greatness (figuratively), and your sanity will thank you.

❌ Don't Forget Communication (or Communicate Too Late)

Although ironic that I saved this for last in the "Do" list, adequate communication is the often-overlooked component (i.e. afterthought) in a migration plan. I caution you from notifying your end-users with short lead times. Be open with your end-users about the coming change. Start early with the communication and keep them involved (but be careful not to spam them). Ask them for help identifying (or volunteering) your Line of Business Trial groups and include graphics to illustrate their new employee experience (as mentioned previously). Also, follow-up with them after the fact. What worked? What didn't?

Luckily, you don't have to come up with a communication plan by yourself. VMware can get you started – check out our Tools. We’ve created an Adoption Program Guide that includes step-by-step instructions on how to create and run an adoption campaign, communication kits with pre-written templates, and even a customization tool!

Do Let Me Wrap This Up

Moving to Workspace ONE from another MDM provider may seem like a huge lift, but you're not alone on this journey. Lean on members of your account team for guidance, or perhaps engage the help of VMware Professional Services and the VMware Community. Don't forget the Workspace ONE Activity Path here on Tech Zone and even some tools on the Flings site or GitHub that might help you.