How can you speed up your Win11 migration and get to Cloud Native?

By now, you’ve probably heard many people (mostly me) tell you that the impending Windows 11 upgrade is the perfect time to switch to a modern, managed, cloud-native solution (Entra joined devices). In an ideal world, you’d have a team working on this with consultants, project managers, and everyone in your team so you can follow best practices throughout. In most cases, this isn’t an ideal world. Budgets are tight, staffing is tight, and you’re lucky if you get a lunch break. Never mind the time it takes to plan and implement a complicated project such as this.

Fortunately, there are tools available to help you along the way and ease you into the new world.

Before starting any migration, you need to know what needs to be migrated. While a lift-and-shift is technically possible, bringing years, possibly decades, of technical debt into a brand-new environment makes me sad, so we should try and avoid that.

So, what do we need to review? Hopefully, if you’re reading this, you have some infrastructure already and don’t just have a random selection of computers bought from the nearest electrical shop full of whatever users have decided to download and install.

Assuming that’s not the case, we primarily need to look at hardware compatibility (the expensive one), user personas, applications (critical), group policies and the usual suspects: printers, mapped drives and wi-fi. There’s also the small issue of rebuilding your devices, but there are unofficial options here.

Hardware compatibility

We can now see what tools and utilities are available to help with each step, starting with hardware compatibility.

If your devices are already enrolled into Intune, navigate to Reports > Endpoint analytics > Work from anywhere, and select the Windows tab. This will indicate which devices are Windows 11 compatible, and if not, why not.

In Config Manager, there’s a similar readiness dashboard available.

For those who have neither, here are the official requirements.

As a general rule, anything more recent than around 2018 (and a half-decent spec at the time) should be okay, but I’d always double-check those just in case.

That’s the hardware sorted, and hopefully, your finance department isn’t either crying or laughing at you right now, so we can move on to user personas.

Personas

These are hugely unloved and, if done properly, can make a difference both for you during the migration and for your end users. A well-created set of personas means a seamless transition, and the users receive all of their apps, group memberships, Teams channels, etc., from initial login rather than having to create requests to the IT team (you).

Remember, Entra ID does not have organisational units in the same sense as on-prem AD. You can set up Administrative Units for permission delegation, but you need to look at groups for everything else.

Fortunately, it supports dynamic groups, so you can, for example, create groups based on user attributes, office, or department. That way, all new users will automatically be added to these groups. This reduces the risk of users being in the wrong group and removes one extra step from your onboarding process.

Applications

But what about applications? We all know some departments have key applications. Still, they’ll also use other lesser-known apps, especially those manually installed years ago, which don’t generate any support queries. Whilst the end-users expect you to be an expert in what they have installed and the inner workings of every application ever created, we all know this just doesn’t happen in the real world.

This is where you can use tools to help detect applications, who uses them, how often they’re used and lots of other exciting information. One such tool is ManagementStudio. It’s like having a project manager and team to help you through the whole process.

Starting with assessing your environment, it will use whatever tools you have available: AD, Config Manager, Snow, Systrack, and the list goes on. Using the data retrieved from these systems, a dashboard will be created that lists all the applications discovered.

Your first step is to quickly review these and see which can immediately be discounted, especially as many modern apps are now SaaS, but how many of you uninstall the old client? The software will rationalise down to the latest or most-used version, so you don’t have to wade through 400 versions of Chrome.

After selecting the apps to take with you into the new world, the software works its magic and believe me, it’s really clever.

It arranges the applications and advises the order to migrate them over so you can attack the most used applications first and get the bulk of your workforce over before moving on to the more tricky users and apps. As an application is migrated, it will tell you which group of users can now be migrated so you can be sure that their applications will be immediately available.

The reporting functionality will show which applications to concentrate on each week, taking one task away from you with your project management hat on. What if you’re not sure about an application? Easy, use the What-If tool to see what impact that will have on the whole migration.

Packaging

We now have a list of applications to be migrated and an order to migrate them, but how do we actually migrate the installers themselves? Well, you could grab the source files, check if they need updating, test them and package them into the intunewin format, but:

1. that’s an incredibly resource-intensive and lengthy process
2. it’s a hit-once approach. What happens when these apps are updated?

To mitigate this, we can call in another tool critical to managing an Intune tenant, Robopack.

Robopack is a SaaS application management tool that takes all of the work out of most of your applications. With a database of over 40,000 applications available for instant deployment, you can quickly clear the deployment for a large percentage of your estate.

Not only will it deploy the applications, but it’ll also sort the install/uninstall and detection strings. With wave deployments, you can initially deploy to a small group of users to test that everything is working well and then automatically deploy it to the rest of the estate.

If that’s not enough, it’ll also handle all your updates using the same wave deployments. For most of your apps, deploying and managing applications is a click-and-forget task.

For those of you migrating from config manager, there’s also a tool available to grab your SCCM applications, package them and add them into Robopack as a custom application, keeping all of the configurations already present.

Custom apps are also available as a straight upload into the portal so whilst it won’t keep those applications updated, at least your deployments can all be standardised within one location.

There’ll always be those hideous applications written years ago, and the vendor refuses to make a friendly installer for them, or that need so many custom settings that you end up with a PowerShell script longer than the Lord of the Rings. All is not lost. Algiz will re-package these for you into a friendly MSI (and intunewin if required) to deploy via Intune.

Thanks to the magic of Robopack, our apps are now migrated, tested and working, but do the users know? I’m sure you’ve better things to do than email them all (not to mention the “Actually, while I have your attention, can you fix my printer” messages).

Communication

Again, ManagementStudio comes to the rescue. Before migration, the software sends out user surveys so your end users can update their information and confirm all is correct. It then uses this information to create notification emails along the way and a satisfaction survey at the end to confirm all has gone as smoothly as expected.

With the magic of these applications, we’ve handled user personas and applications with much less work. Those of us who completed the XP-Win7 migration know how painful it can be.

GPOs

When looking at group policies, the temptation will often be to use the Group Policy Analyzer within Intune and, for ease and speed, dump the whole lot in. Please try and avoid doing this. Imagine Intune as a fresh start; it’s your chance to ditch those group policies telling MSN Messenger not to autostart. Lose the login scripts and never think of an autoexec.bat again.

I’d always advise starting with a secure Intune baseline following guidance from NCSC and CIS (but not too strictly, or your users will have a pretty terrible experience). Community-built baselines are available in the shape of OpenIntuneBaselines and Intune Deploy in my EUC Toolbox tool.

Once you have your baseline in place, review what you’ve configured within AD currently. Check which are already handled by the baseline and which are no longer relevant, whether that’s due to the cloud-native management or just the fact they’re from the early 1990s. This should, hopefully, give you a more manageable selection of policies.
Fortunately, Intune policy management has really improved with the migration to the universal Settings Catalog, so creating these additional policies takes a lot less guesswork; you could even use the group policy analyser here and import those which you definitely need.

This is a subject of debate, but I also prefer to have more smaller policies than filling all settings within the same policy. I find it easier to manage, and there’s less risk when making any small changes – in the early days of Intune, large policies also had a habit of crashing the browser window.

The other thing to consider is those settings where different people may have different requirements. Keep those out of your baseline and add them to their own policies so you can have one setting it Off and one On. On that note, setting a policy status to Not Configured will not always revert the setting, which is something called tattooing, so it’s safer to have one policy and revert it to the opposite setting. Remember, most of these are just setting registry keys on the devices.

Also, don’t forget your Conditional Access policies. Think of CA as the front door to your tenant; securing your devices isn’t much good if they can steal your identities and data!

If you have mobile devices, make sure you look at the MDM and MAM offerings here as well. You’re paying for them in your M365 license, so get as much as you can out of it (it’s not Windows migration-related, so I won’t cover it here).

Printers

But what about those three horrible things that always cause the most hassle? Let’s start with printers. Yes, the best thing for them is to go “Office Space”.

It’s 2025, and we really shouldn’t need them. Sadly, users will be users, and they definitely need to print that PDF, make notes on it and then scan it back in again.

Unless you have a very basic setup, I’d always recommend some form of follow-me printing. Plenty of suppliers are available, and any one of them should be fine. You can also look at Universal Print from Microsoft. For most licenses, you get 100 prints per month per user, but these are pooled, so if you have 100 users, you get 10,000 prints per month, which for many will be more than enough.

If you really must have a print server, remember two important things:

1. Kerberos SSO – You don’t want your users to need to authenticate to print
2. Print nightmare – This can be fixed with scripts I have here

Now onto the marginally better, file management.

Files

Ideally, migrate everything to OneDrive/Sharepoint/Teams, make the most of files on demand and all of the other valuable features, deleted file recovery, offline files, access from multiple devices, it’s all there, and so much more. Don’t forget your backups, though. Being in the cloud doesn’t mean nothing will happen to it. I personally prefer a backup provider who doesn’t use Azure so my eggs aren’t all in one basket, but anything is better than nothing.

If SharePoint isn’t an option yet (or ever for compliance purposes), you can either stick with existing file shares and a VPN or Entra Private access, or move to Azure Files which is basically the same thing, but in Azure.

If you plan on using either of these, you first need Kerberos SSO, as mentioned above, for seamless mapping (with Windows Hello for Business).
Intune doesn’t have an alternative to GPP, so you have to be creative with drive mappings and use either PowerShell scripts or third-party ADMX templates. I prefer the latter because it makes management a bit easier, and this one from Rudy does the job nicely.

WiFi

The final part of the dreaded three is wireless connection. If you’re using device-based authentication, that definitely needs changing because the devices will no longer have an AD object (without some horrible bodging), so the first step is to switch to user-based authentication.

Once that’s in place, you need to look at deploying the certificates to your devices, and I suggest using a cloud-based option, such as Cloud PKI from Microsoft (part of the Intune suite) or combining SCEPman and RADIUSaaS.

Alternatively, if you’re fully embracing the cloud so users don’t need to access anything on-premises, why not just imagine they’re working from a coffee shop somewhere, protect the device, protect the data, and don’t worry about the network? Throw them on a different network with basic security and let them get on with it.

The rebuild

There’s one step left to complete your cloud journey, and it’s the most painful – although your finance department may differ depending on your hardware replacements.
Officially, the only way to migrate from on-prem to cloud-native is a complete device wipe and rebuild. Even with a bank of replacement machines, it’s lengthy and risky, and you’ll get complaints.

There’s a community migration script available from Steve Weiner, which isn’t officially supported, but if something doesn’t work when using it, the fix is to rebuild, which is the only supported option anyway, so is there anything to lose by trying it? I’ve heard it works really well and Steve is always happy to help in the Discord server if you hit an issue.

So there we have it. By the time you’ve finished reading this, you’ll probably have completed your migration and re-installed Steam onto your new Windows 11 device…

No printers were hurt in the writing of this article.