Just in time to create a stir during VMworld, Citrix has announced XenApp/XenDesktop 7.6, which had been called Project Arthur internally. Although version 7.6 will not be available until next month, it has taken Citrix more than a year to achieve feature parity for it with XenApp 6.5. In addition to finally making the expected features available, Citrix has also integrated a few new HDX features into the new release.
XenApp 6.5 included such features as application pre-launch, session linger, and anonymous logon, which were not available in 7.x prior to 7.5. As a result, over the past few months, many new Citrix application virtualization deployments have been based on version 7.5, whereas companies with existing deployments had previously chosen to delay upgrading due to the loss of functionality it would entail.
Although feature parity has now been achieved, significant business reasons must exist for administrators to adopt version 7.6. A great many organizations are still running XenApp 4.5/5.0 for Windows Server 2003, and it is likely that these out-of-support environments will be the ones stepping up to XenApp 7.6 in short order. With both that operating system and that XenApp version approaching full end-of-life, adopting a newer version is finally necessary. Unfortunately for those organizations, there is no upgrade/migration process whatsoever; their administrators will be creating new XenApp 7.x sites from scratch.
Now that version 7.6 is coming to fruition, how will administrators of XenApp 6.5 implementations choose to move forward? In a production environment, migration is not an easy process, requiring extensive resources and planning, which translates into hard dollars. In particular, migrations from one XenApp version to another have been quite painful, because there has been no such thing as a simple upgrade. Up until now, administrators were told that they had to migrate: i.e., create a new farm (now site) and start fresh, which is certainly not what administrators relish doing. While there was a supported pseudo-upgrade process for XenApp 6.0 to 6.5, which essentially required uninstalling XenApp 6.0 and installing XenApp 6.5, “upgrade” should mean installing a new version on top of an existing version, not cleaning out an old version and reinstalling.
Citrix has stated that it will release migration tools to transition existing XenApp 6.5 workloads to version 7.6. The steps make it appear that it truly will be more like an upgrade: the administrator will export IMA settings/import into 7.x and then run an installer on the XenApp 6.5 server to install the virtual desktop agent (VDA). The key here is that this process must be easy in order to facilitate administrator acceptance of XenApp 7.6.
On the other hand, VMware has provided a mechanism for absorbing existing XenApp 6.5 infrastructure into Horizon View 6.0. In addition to making this transition more of an upgrade than a migration, VMware has been actively courting Citrix XenApp customers with attractive pricing.
Unless they have compelling business or technical reasons, such as the addition of XenDesktop functionality within their organizations, many XenApp 6.5 administrators will likely keep their farms on the current version. The old adage, “If it ain’t broke, don’t fix it,” will likely prevail, seeing as XenApp 6.5 has been rock-solid. These installations are likely the least vulnerable from Citrix’s standpoint.
However, the Citrix installations that depend on XenApp 4.5/5 are quite vulnerable. Because their administrators must fully re-architect their environments within the next year at most, these installations’ IT teams are the ones that may rethink whether to migrate to XenApp 7.6, VMware Horizon View 6, or another virtualization solution. Although it may seem like a step back in time, there is significant market share at stake for virtualization vendors that devise a way to transition these older deployments to a newer platform.