With no migration path from XenDesktop 4 to 5, what can you do now to prepare?

A few weeks ago Citrix announced their plans for XenDesktop 5, their latest desktop virutalization product.

A few weeks ago Citrix announced their plans for XenDesktop 5, their latest desktop virutalization product. We published a detailed analysis of what's new and what you need to know, although at that time we hadn't actually put our hands on the product. Fast forward to today... we still haven't actually used XenDesktop 5 yet, but there's one thing that a lot of people are talking about that's worth mentioning: It looks like there will be no simple migration path from XenDesktop 4 to 5. So what's that mean for folks who are just in the planning, proofing, or piloting phase for XenDesktop 4. Do you pause your project for six months? Do you move ahead now, knowing you'll have a painful migration soon in the future?

Why is there no migration path?

Remember that one of the big new features of XenDesktop 5 is that Citrix is finally moving away from the "IMA" architecture that's powered their products since the days of MetaFrame XP back in 2001. (IMA is the whole back-end management subsystem that includes the configuration databases, the communication and control services, the administrative interfaces, and the server-to-server communication protocols.) IMA was designed when a "big" farm had a few hundred MetaFrame servers. But in today's XenDesktop world, each desktop is like its own single-user MetaFrame server (at least as far as IMA is concerned), so a 10,000 seat XenDesktop environment is probably 50x bigger than Citrix ever imagined was possible when they were designing IMA.

Make no mistake: Moving XenDesktop off of IMA is a very, very good thing. And we've known this was coming for a long time. Citrix recently said they've been working on the new architecture for "years," and Citrix's chief software architect Brad Pedersen mentioned it when I interviewed him back in 2006.

Unfortunately this completely new back-end architecture (which was codenamed "storm" internally) means that there's no easy way to migrate from XenDesktop 4 to 5. All of your farm configuration, your desktop configuration, your groups, your admins, your security, your policieis, your servers--everything--will need to be rebuilt from scratch.

This isn't something that's new to Citrix customers. The move from XenApp 5 to XenApp 6 was similarly harrowing as XenApp 6 requires Windows Server 2008 R2 which is x64-only. (Ironically XenApp 6 is still based on IMA. If Citrix bases XenApp 7 on storm, then will customers have no migration path again?)

What's the impact of no migration path?

The real question is whether a lack of technical migration path will really impact customers? A lot of folks like to keep their environments "clean" and don't really trust upgrades, so there's a good chance that most people would have built a parallel environment anyway.

It's also worth considering that not everything will be different in XenDesktop 5. For example, anything having to do with the actual desktop VMs themselves--the images, the applications, the user environment, the provisioning, etc.--can be easily moved from the old environment to the new.

The big question, again, is what this means for customers who have not yet fully deployed XenDesktop 4. Do they wait? Do they continue with the intention of redoing the back-end in a few months? Do they continue with XenDesktop 4 and plan to skip XenDesktop 5? (And if so, do they feel stupid for having Subscription Advantage?)

What does this mean for you? Does a lack of migration path change your immediate plans, or is it business as usual?


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Migration ? Only 5 millions  licences sold in 2 years (1.5 in 2009 and more than 3.5 this year)... Didn't make it a challenge... Especially if you had the fact you can continue to hide this from user with the Web Interface front end...


Taking a step back a high level look at the XenDesktop VDI Hosted Desktop environment you'll see that it may not be quite the doomsday scenario.

- A single Citrix Web Interface can aggrogate both the old and new environment meaning you will most likely not need to touch an end point device.

- New desktop broker servers can be set up along side existing DDCs.

- The same Provisioning Services Servers can be leaveraged

- A copy of the current master VHD file can be made and updated with the updated VDA. There is no need to "rebuild" or clone hundreds of thousands of new desktops to update.

- Provisioning Services will maintain the association with AD computer accounts, they will just boot pointing at a new broker rather than the original DDC.

- By changing AD groups a user belongs to you can complete their update without any major modiciations to their primary work environment, the VDI desktop image and profile.

Now this is an over simplified explination for an enterprise environment but I just wanted to point out that the XenDesktop architecture with Provisioning Services will allow most of the migration activity to continue along as any other desktop upgrade woudl to the master image.


Migration is always a kicker in any type of system upgrade. But since there isn’t an upgrade option, that just makes our decision easier. :) Plus, I believe that most people who built their XenDesktop environments probably learned quite a lot that they wish they had time to change.  Well, if you are going to rebuild, might as well incorporate your desired changes.  

Truth be told, you don’t want to upgrade anyways.  Because XenDesktop 5 is so different from an architectural perspective, you need to re-look at your architecture. Is it still correct? Does it align with what you are trying to do?  Did the old version meet your needs or are there some things you wish you could have changed?  Did you stream or install all of your applications and are now re-thinking that approach?  How many different desktop groups/catalogs do you need? Who is assigned to each one? What policies do you need applied?  

I prefer the safer approach for most new versions, especially when the changes are so drastic. But like others said, you might be able to keep your PVS architecture as-is.  Your VMs, you just have to update the virtual desktop agent.  Even your hypervisor pools are probably fine.  You just need to rebuild the XenDesktop sites, build your catalogs, assign users, and apply policies.  I know I make it sound too easy. There will be work involved. But if you know that beforehand, you will be better off.


I am hoping that Citrix would consolidate the Provisioning Server farm Database and the XenDesktop Farm Database into One Farm Database.

This would truly be "Synergy."

XenDesktop and Provisioning work together and they need to be consolidated into one Farm and one Management Console.


While it's true that XA6 hasn't departed from IMA it's still just about the same type of migration strategy as XD5 is.  You must build a separate parallel farm and aggregate via Web Interface.  The only thing that XA6 provides is an XML export/import tool to ease the movement of apps.  However, I don't know that ths is really needed for XD5 migrations.  You see you could pretty much export the entire XD4 machine list/user assignment and then import it into XD5 (I'm assuming they provide this, but can't confirm because I still don't have access to the bits).  So you build new DDCs in parallel, aggregate the farms via Web Interface, export/import all your desktop/user assignments then uninstall/re-install your VDA to move machines from one farm to the other.  Will it fault free?  No.  But then again upgrading the VDAs on 3.x/4.x wasn't without issues as well so I don't see this as a huge problem.



So what does this mean for VM Hosted Apps. Is this getting a makeover to follow XD5?



Business as usual for us. Have a number of deployments in design phase right now. Since the particulars are still fuzzy from Citrix, can't ask clients to wait. Just have to take what we do know (and you've done a good job of laying that out for us in your blogs), and applying those as appropriate to our projects. No migration path not a big deal, as Shawn point's out - we would usually just build a parallel environmnet anyway and then just consolidate with WI as the front-end. Just update the VHD and away we go.

My concern was actually around the changes to the datastore. Old design didn't require much in the way of a SQL box, or HA (LHC took care of HA needs). New design sounds like it will be a more critical piece to consider during design, with regards to both perf and HA.


I’m quite of the same opinion that @Daniel stated, aka. (trash), refresh and build anew.

As already expressed the actual VMs along with the user settings can be kept and moved to the new platform rather effortlessly.

Here, like in most other “upgrades” my position is of that of building afresh and transferring over the bits that one likes to keep.


@ Stephen Rae, there are two options in XD5.  Images can be provisioned from Machine Creation Services (I think) in smaller environments which is somehow integration with the broker, or for larger deployments (250 plus) I beleive PVS is still recommended.