We’ve discussed already the dream of modern management, a dream I shared for a time in the hopes that we would move away from the legacy world of slow/clunky tools, complicated policies, and massive hierarchies that were designed in the 90’s but are still running today.
Now, we’ve come to accept that there is a transitional journey that enterprises will embark on to move from a legacy, on-premise-centric system to a future system where our end-user devices will become modern managed devices. The problem we are stuck with is this: How do we transition to the modern management story and decrease the amount of time highly skilled professionals spend doing mundane and repeatable tasks? To answer that, we need to confront the two main dilemmas with modern management:

  1. How do we move away from traditional deployment without either losing the information/telemetry we have or being forced to use legacy tools?
  2. How do we move to a modern way of working without forcing users to self-manage in ways that are inconvenient and time wasting or adding more administrative overhead for processes that were previously automatic?

A modern management story isn’t complete until we think about a transition

Before Autopilot, we solved the issue of remote rebuilds of client devices, BIOS configurations, and migrations with only the tools available.
Some of that challenge has gone away as Autopilot begins to reach maturity, but many still struggle to understand how they’re supposed to arrive at that dream destination. Ideally, all applications would be mapped to users and when a user logs on to their device, they would automatically have all content available and work just as they might have with a white glove service at a local site. Autopilot helps with remote building of devices and integration with Intune, but many don’t know how to move from a traditional, device-based deployment strategy to a user-based deployment strategy. A company either suffers a loss of a great deal of information and forced rebuilds or is stuck with a legacy technology stack that still works but won’t hold up in the modern world.
The problem is that it’s all dependent on incredibly accurate mapping of each device to its user. It needs to be as close to 100% as possible and not based solely on information about the last logged on user (which will typically get an organization to around 85%). Being wrong 15% of the time may be acceptable in an organization of 100 or 200 devices, because it would leave only 15 to 30 machines that need to be remediated. For a company with 100,000 devices, that is 15,000 more tickets to the service desk and, potentially, 15,000 new machine builds.

Considerations to successfully manage your Modern Management migration

Even if not investing in the 1E tool set that can help with this kind of issue, you need to ensure that the CMDB for client devices is up-to-date and has accurate information. Without it, the migration to modern management is going to be a rocky affair because of that 15% issue.
The work to build these new machines is also problematic. Autopilot and the modern management story now include ConfigMgr, so legacy infrastructure is taking the ride to the modern world and gets better with each release. The good news is that the massive investment organizations have made in this product will not go away. It also means that all those pieces of software built for that platform are reusable assets with no migration needed. The bad news is there is no way to map machines to users or build a task sequence dynamically that can be called by Autopilot to deploy the software a user needs to work.
The dilemma here is that while organizations have embraced a modern way of working that allows for faster remote builds, the overall time a user spends getting ready to work is hampered by the lack of applications being readily available. Either choose to lower users’ total time to have a machine (but take into account the added administrative overhead) or have a user receive a machine faster) but with the added complexity of managing their own software).
If each piece of software needs to be requested manually via ConfigMgr, it can be an extra day (or two) before an end user is ready to work post-migration. Even with a well-thought-out Task Sequence that delivers a base set of applications, a user is bound to require some specialty software and are delayed until they receive their software.
These are the kinds of issues 1E loves to solve with our customers. If you think you will have them with your migration to modern management, please reach out to a 1E expert  and we’d love to help you.