Let’s imagine for a second that you are a large, global organization and you are managing the fleet of PCs.
In a traditional setup you probably have a Configuration Manager server and probably a bunch of distribution points.
On top of this, you each month must distribute security updates to all your global device estate. And make sure your golden image is patched. Not only this, you also need to maintain your infrastructure, keeping Configuration Manager up to date, the server it runs on and also all those distribution points. Not to forget troubleshooting when a distribution point stops and a region +8 hours from your time zone can’t PXE-boot computers.
You have all heard the marketing pitch because cloud native is the future. But if we instead take an approach to discuss this from a business and operations perspective, we can find some other interesting angles.
Background
What I do in my professional life is mostly to advise and help customer moving to a cloud native platform for device management. I’ve been working with Microsoft Intune since 2013, so I’ve seen all the itterations of the platform. I’ve also seen what works and what didn’t work.
Back in 2013, going cloud native was not a thing, even though Windows 8 acutally supported MDM enrollment. Back then we were more talking full management or light management. Intune was the light managed way doing things since there were simply not yet feature parity.
Windows 10 brought a whole lot of new benefits to cloud. You could now argue that you could make the shift to Intune only and onboard using the new cool Windows Autopilot.
Fast forward to 2025 and Windows 11. We now have feature parity in MDM polices vs GPOs (even if it’s not a 1:1 translation), and moving to the cloud is something everyone is talking about. Not everyone has moved, but from what you hear peers, customers and people within the community everyone is looking at “how should we do the transition”.
Moving to cloud native is not only a “keeping up with the IT landscape”. It can also be a huge cost save for a lot of organizations. No more servers, no more imageing, no more maintaining images. It’s simply just more streamlined.
Common pitfalls
There are A LOT of pitfalls out there when it comes to moving to Intune. I thought I would cover a few which I tend to see more often. Not all of these are technical. Because to be 100% honest, the technology isn’t the biggest issue here.
Doing things like we have always done
Moving to cloud native means doing things in a new way. I’ve seen way to many attempts at moving to cloud native which fails because you don’t embrace change. An Entra ID/Intune managed device is not exactly the same as a Active Directory/ConfigMgr managed device. Gone are the days of imaging and GPupdate, we now have Windows Autopilot and syncing with Intune.
Cloud native will mean that we will have to do things different, and it’s not bad. Just different. Many things we have done for the last 30 years with managing devices (yes, the first version of ConfigMgr called SMS 1.0 was release over 30 years ago in 1994).
We need to embrace change and adopt the new ways of working. If we don’t do that, we will never reach all the way. This is where many project fails.
Doing everything at once
The cloud journey looks very different for all companies, even though we want to accomplish the same things. But doing big shift actually impacts user productivity and we need to be smart of what changes we introduce.
Looking at Sweden, a lot of companies are combining their Windows 11 migrations project with a Cloud Native project. This is a great idea since we are doing a big shift in the client anyway. However, time is running out for Windows 10, so today we need to prioritize whats actually important.
But splitting the cloud journey into smaller pieaces could be easier for many, but we can run a lot of these projects in parallel.
Migrating everything
Think about all your GPOs. You have built that over a larger number of years, probably mostly adding to it and never really done a cleanup. A lot of these policies might been configured for Windows 7, and operating system which was released in 2009. You probably don’t need to migrate those settings to your brand new Windows 11 platform since a lot does not apply in the cloud and many are even depricated.
There is really no point in walking through each and everyone of your old setting, trying to find the Intune equalent for it. A much better idea is to look at what you had, implement either the Microsoft Security Baseline or the Open Intune Baseline. Then go look at your old environment or your security requirements and look for what is missing and what makes sense. There is a GPO analytics tool in Intune, but for experience I would say that starting over is a much better idea since you will leave all your Windows 7 and Windows XP settings behind!
Setting the bar way to high
One of the most common things I see when working with customers who are moving from ConfigMgr is like I mentioned, we don’t embrace change. But one more things is thinking that we need to make it perfect in our first Proof of Concept or Pilot, which isn’t really a realistic approach. You need to start somewhere, so find your minimum viable product (MVP). What do we need to have inplace to do a successfull pilot. What I’ve seen with the more successfull projects I’ve been involed in, this has been the MVP:
- Windows Autopilot for onboarding
- Security baseline
- Wi-Fi
- VPN
- Base applications (the crucial ones for your pilot group)
- Compliance policies
One more thing to keep in mind when moving towards a cloud native client is that your pilot and initial rollout might not need to suite 100% of your users. You will have some more cumbersome scenarios like dependency on on-premises or problematic applications. Don’t let this stop you, instead have them in a later phase of your project. Put them on hold, just like you would do with Windows feature updates. Once you have completed your first scenario, move on to the next!
Moving all extisting devices
This is a controversial one. Eventhough it’s nice to have all your devices as cloud native, but the only way to migrate devices from hybrid to cloud native in a supported way is by resetting the device. And this might not be the most productive way of making this shift, since it means actuall downtime for the end-user.
Microsoft recommends to keep hybrid devices in hybrid until they needs to be reinstalled or replaced. Since we can still move to a 100% Intune managed environment with hybrid devices, this could for larger organizations be a more cost efficient way of making the shift to Intune. Re-installting thousands of devices is time consuming.
I’m not saying that you shouldn’t make the hard cut and re-install all your devices, but be aware of that there are alternatives eventhough it’s not a pure cloude native solution for all your exisiting devices going down this route.
What’s your first action?
But where should you get started? Well, making sure you have co-management/cloud attach enabled in Configuration Manager is a great first step, to enable the shift of workloads to the cloud.
I would also recommend to start looking at setting up a small proof of concept or pilot in Intune, onboarding a few devices with the base applications and a first version of security baseline (use the Microsoft one or Open Intune Baseline mentioned earlier in the post). Register a few devices for Windows Autopilot manually and enroll them.
Don’t make it to hard on your self, start small with the “simple” scenarios and let them test it. But set a strategy for this and make sure to track your progress and create a project of this. It’s a hard project to pull of as a line activity since there are a lot of moving parts, redesigning and new ways of working while you need to keep the light on for your production environment.