At this point you have assessed and found cloud desktops will be the way to go forward. The next big question you have is how to migrate users to the new platform. When evaluating the DaaS provider you would have been easily caught up with all the hype around the technology offering like file services, utility servers etc. and thought you could use them as well. While that sounds great and it makes sense to move the core service’s that support the desktops to sit beside the cloud desktops thus improving the overall user experience and it’s a best practice to do so, you started with an idea of moving some desktops to cloud, but you just turning a DaaS project into a migration of other core infrastructure components that needs to support the DaaS services. Whilst file services make it simple to migrate to DaaS, as that’s were all the user data will reside and that’s the first thing users would like to see on their new desktops. It’s important to evaluate and clearly define a scope around the migration, else you are just increasing risks and chances are you may fail !
This document gives ideas around the migration approaches and its impacts around the infrastructure, user data and applications migrations. Migration can be achieved in various ways and solution can vary case-by-case, hence it is important to assess the current desktop environment and work on a migration approach that is optimal and efficient.
Before getting started here is quick sample pre-migration checklist. Success of the project will be driven by users, hence it’s important to focus and educate the “User” throughout the migration process.
- ·Workloads that will be migrated and their requirements.
- Is your network ready to support DaaS?
- Which are the core services that needs to be migrated along with the desktops?
- Who are the key-stake holders supporting the migration?
- Do you have a plan B in case the migration fails?
- Set the timelines and downtime window for the services to be migrated with negligible impact.
- User communication during the migration and on-boarding.
- Will the users be able to switch back and forth between the traditional and DaaS environments?
- Do users know whom to contact when they need help?
Now let’s look at what do you do during the actual migration. The DaaS migration are lot like traditional desktops migrations when it comes to user data, however for application, core services migration will be a gray area that one should invest time in. Also if migrating from VDI to DaaS model, Non-persistent desktop is complex as the user-data and application’s mappings don’t easily translate.
One of the key consideration to start with is weather the domain controllers will be moved to cloud or will you provision an additional domain controller / read-only domain controller in the cloud. Most of the customer choose the latter option as they feel that still gives them some security / controls in hand, plus if there are any other resources that require domain controller services and which are not being migrated to cloud will makes sense to take the latter approach. In most of the cases it’s always been an additional domain controller / read-only domain controller in the cloud.
On the other hand, Network implications of running DaaS need to be considered. There needs to be a significant assessment done on the network side to make realistic assumptions as the users connections flows between your LAN and DaaS provider if the desktops are accessed within your office. This will be worst nightmare one can imagine If not done right as the whole end user experience will be impacted. So, it’s important to analyze the wire between your LAN and the DaaS provider, Follow the Network best practices recommended by the vendors. While DaaS provides you with features like high availability and disaster recovery desktops, imagine if you don’t have a redundant connection between your LAN and the DaaS provider and the only available wire fails!
If the user is remote, who really cares or whom to be blamed? Whilst the bandwidth claims by the mobile/broadband operators are for ideal conditions, in reality a good bandwidth doesn’t mean it’s free from latency or jitters. These networks aren’t dedicated and are shared with people, so sometimes it can get shaky and its important the users understand such impacts. How many times has your call dropped? how many times have you complained about fluctuations / slowdown in your broadband network? If core services offered by the vendors are impacted, so will be DaaS experience.
I just can’t stress enough how important it is to have a stable and reliable network for delivery of desktop-as-a-service. This should be the number 1 on the list while considering DaaS.
Imagine you get a fresh new desktop without the customization that you had done for ages! having to start it all over again is quite annoying for both the users and the support desk people. The problem with migrating user profile is carrying the good old problems that you would have had persisted in legacy desktops environments and if your migrating to a newer OS’s it can just be a lot of cumbersome task or you may end up putting junk to the new OS. The problem with default Microsoft profile is that, each user’s, application and OS settings are all coupled into a single file. You just can’t migrate by de-coupling the settings. Migration of windows profile will be the same way as you would migrate between desktops. You can use Microsoft’s – User Migration / Assistant Tools.
If your using User Environment Manager (UEM) products that great! your migration is on the fast lane. UEM products offer low level customization, these abstract user settings from the OS thus making it possible to manage each setting at a granular level. If you planning to deliver multiple OS’s or just the application’s which may be delivered from multiple locations, UEM products compliments well in such scenario’s. UEM products can manage VDI, RDSH, DaaS and traditional desktops from multiple locations without much administrative intervention. UEM offer self-service tools to end user that help them fix the problem without help desk support. Remember profile corruption support calls, UEM may just solve that problem for you within few clicks! So, you should consider introducing UEM products if you haven’t already as part of your DaaS journey.
This is where the game gets dirty a bit! Most of the DaaS vendors offer their own application virtualization stack that sticks well within their desktop virtualization management suite. The underneath technology varies vendor-to-vendor, so making it impossible to migrate between them. Also, there are plenty of application virtualization products out there in market, while these offer some cool benefits, its upto you to decide based on the use cases. It’s not mandatory to use the application virtualization stack provided by the vendor, you may opt to go with other vendors on your own to use them in your DaaS environment. If you are using SCCM, Thinapp’s, App-V you may decide to move it DaaS. All your configurations, settings and management should work the same way, apart from the changes to the core server’s components that have been moved to DaaS. Based on the use cases you may want to stick with the existing solution or go out and explore the new ones, this might be an appropriate time to refresh. However, note applications virtualization may get tricky as you end up doing it from scratch.
I hope this high-level approach note gives you an idea on the overall migration consideration to cloud desktops and how critical this phase is , Its important to set realistic timelines and detailed planning to succeed.