What an RDS-to-Intune Migration Really Taught Me
Migrating users from a Remote Desktop Services (RDS) environment to individually managed Windows devices sounds simple enough. Copy the profiles, deploy the new laptops, hand them over, and move on.
Reality is rarely that clean.
One of the largest migrations I worked on involved moving users from an RDS platform to new Microsoft Intune-managed devices. To support the rollout, I built a PowerShell tool of more than 700 lines, with extensive logging and a dedicated debug mode to make troubleshooting easier during deployment.
Looking back, the script wasn't the interesting part. The migration itself taught me far more than the code ever did.
Users don't care about your migration
IT teams often judge a migration by technical metrics: how many devices were deployed, how many profiles were transferred, or whether the cutover finished on schedule.
Users have a much simpler metric : Can they keep working?
A successful migration isn't about copying files from one machine to another. It's about recreating an environment that feels familiar. Desktop shortcuts, browser favorites, Outlook signatures, application settings, and dozens of small personal preferences all contribute to that feeling.
Most users will never know how their profile was migrated, and that's exactly how it should be.
Don't migrate technical debt
Automation makes large migrations possible, but it shouldn't decide what gets carried over.
Every migration is an opportunity to ask a simple question: does this still need to exist?
Legacy environments accumulate years of old application settings, forgotten workarounds, obsolete software, and configuration choices that nobody remembers making. Copying everything into a modern environment only guarantees that the same problems will exist on a newer platform.
Moving from RDS to Intune is also a change in operating model. Many settings that once lived inside user profiles are now better handled through configuration policies, security baselines, or application deployment.
A migration shouldn't just modernize devices. It should simplify how those devices are managed afterwards.
That's one of the reasons I eventually became frustrated in a previous role. The priority was often to complete the migration as quickly as possible because that's what had been sold to the customer. I saw it differently. A migration is one of the few moments where you have a legitimate opportunity to rethink the environment instead of reproducing it.
The technology wasn't the difficult part
PowerShell wasn't the biggest challenge : People were.
Large migration projects constantly generate situations that no documentation can predict.
Should a specific application setting be restored?
Is this issue caused by the profile, the application, or the user's habits?
Should the documented process be followed, or is this one of the cases where adapting it makes more sense?
Sometimes the most practical question of the day isn't technical at all.
It's deciding where to store hundreds of empty laptop boxes without blocking the office.
Projects like these are built around hundreds of small operational decisions. Most aren't individually difficult, but they need quick answers. That's where an experienced technical lead makes the biggest difference—not because they're writing complex code, but because they're reducing uncertainty for everyone else.
Modern endpoints change the conversation
Remote Desktop Services still has its place. Some applications and highly centralized environments continue to justify it.
But many RDS deployments simply exist because they've always existed.
Hardware has improved. Cloud identity has matured. Endpoint management through Intune has become far more capable than it was a few years ago. For many organizations, individually managed Windows devices now offer a simpler operating model, better performance, stronger security, and a much better user experience.
The decision shouldn't be driven by habit.
It should be driven by what makes the environment easier to operate over the next five years.
Success is measured afterwards
The project team remembers the deployment weekend, the migration scripts, and the inevitable technical issues.
Users remember one thing....Did everything work when they signed in?
If they can find their files, launch their applications, and get back to work without thinking about the migration, then the project achieved its objective.
That's probably the biggest lesson I took away from this project. Good migration tooling matters. Good automation matters.
But users never notice either of them. And that's usually the best possible outcome !
0 Comments