The old adage “nobody ever got fired for recommending Microsoft” doesn’t have the same fearsome grip on admins as it used to. Today, people are recommending products based more on functionality than on the size or general popularity of the corporation developing the product. An office today is just as likely to be multi-operating-system as it is to be uniformly Windows. You might be responsible for supporting M365 or Google Workspace as your productivity suite. Your tools might be local or they may be cloud-based.
Moving between platforms isn’t the rote upheaval that it used to be. Developers have given us tools to make migrations easier. Third parties have stepped up to provide services that remove the burden of monotonous transitions from your IT staff, leaving them to manage the project and train the users — a better use of their time from both an expertise perspective and from a customer service perspective.
Moving to a new platform requires synchronizing a number of moving parts so that the organization can continue to work with as little impact on productivity as possible. While it’s impossible for a transition to be completely seamless, today we’ll discuss how reducing the potential for snafus can make a transition to a new platform relatively painless.
In the case of changing productivity suites, many companies start with one company (say, Google Workspace or M365) and then find that the product is either overly complicated or missing particular features. Or maybe they need to make a switch to better work with their clients and partners. It happens. One size fits many, but does not fit all.
For a change in a directory system, companies may want to move away from on-prem directory systems such as Active Directory because they don’t want to be locked in to Microsoft or because they prefer a pay-as-you-go model. Some organizations adopt the use of multiple cloud services for their distinct features or because they were used in a past position, but eventually find managing them all to be unwieldy. They may desire the efficiency and security that comes with integrating them all into a single, manageable IDP point.
Changing platforms impacts everyone. When planning for a major change in technology, IT admins need to keep in mind the impact on fellow IT administrators, network managers, key stakeholders, and users.
The effect on each of these users’ workflow is different, depending on job function and depending on what is being changed. We’ll give you a couple of examples to help you get started.
When changing the office productivity suite, keep in mind that there are functions within each type of document that may or may not transfer over to a new system. For instance, some sheets-to-excel translations, and vice-versa. An experienced spreadsheet master would know which formulas, scripts, or automations translate and which would need to be rebuilt. The same applies to migrating docs and presentations – you will find that certain transitions, animations, and design options will need to be rebuilt if compatibility is lacking. But, typically, the stress load for this transition is small as most productivity documents will translate between platforms properly and, frankly, email is email – you can swap services without changing the app with which you access that email.
Migrating from AD to another directory service such as JumpCloud is more complicated than an email service switchover. There is a lot of backend work, and there are decisions to be made before initiating this migration. It is important that the IT Admin prepare both the data and the users for this type of transition. As if deciding to change platforms isn’t enough, you’ll have some other things to decide on/plan for:
While some believe that asking forgiveness is better than asking permission, we disagree. We believe that an informed user (and certainly an informed key stakeholder) is a better ally than an upset user or stakeholder. Therefore, we recommend that admins advise everyone who might feel the impact of a transition early and often.
Write your emails up front and have them scheduled ahead of time. They should be informative, open, and honest. Further, they should contain a Call To Action from each recipient along with a link for them to do an accountability check in the form of, possibly, an e-signature or an e-course. We recommend a notification schedule along the lines of six months out, three months out, one month out, two weeks out, one week out, and one day out.
Rather than initiating a sweeping change to your entire organization at once, consider migrating in smaller groups. You can amass those groups in a number of ways. Early adopters should include a smattering of users at all levels of technology experience. This will help uncover any hitches in your migration plan. Once those users have made the transition, they can be mentors for the rest of your company.
Rather than cross-functional teams, consider migrating by department or job function. In this plan, your first-up group should be the one that would suffer the least impact if something went cattywampus; this allows you to get a practice transition in, with the best potential results and learning.
It is critically important to create a transition guide for users. The guide should contain an abundance of screenshots, LOTS of videos, and an absurd number of examples. Leave no stone unturned, no question unanswered. Make your transition guide available digitally, with tests that confirm your viewers have seen everything. Education eliminates surprises. An educated user base makes you shine like the star you are.
Have you migrated your company’s services? Are you considering a switch to a new service provider or platform? Are you nearly ready to pull that plug? Come over to the JumpCloud Lounge and let’s discuss it in the #Admin-Life channel.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
New to the site? Take a look at these additional resources:
Ready to join us? You can register here.