XenApp 6.5 migration is harder and more costly than you think.
If you've done any research on how to migrate XenApp 6.5, you're probably aware that it's a ton of work. Basically, you need to rip and replace the entire Independent Management Architecture (IMA) and start from square one with Flexible Management Architecture (FMA). However, that isn't the only problem. Here is a list of the top five pitfalls for XenApp 6.5 migration.
(1) You have to rip-and-replace IMA architecture with FMA architecture.
Ok, you know this is mandatory, but why is it necessary? Essentially, it's because the IMA architecture is more than 15 years old.
Back in 2011 when I was at Citrix, my team introduced the FMA architecture for XenDesktop. One of the biggest reasons we introduced a new architecture was because even a small change required massive amount of IMA database work--it was slowing down innovation. When we started the FMA project in 2009, we used the best mature technologies available at that time, like relational databases, browser-based management, etc. In other words, we shifted the responsibility to solve some of IMA, like synchronizing configuration information across zones, farms, and sites, to the database vendors.
The result of this change was massive. The FMA architecture's basic underlying operations is totally different from IMA. So XenApp 6.5 customers looking for a path forward with FMA have to rip and replace and start over from square one.
(2) You have to re-train your Citrix administrators on FMA architecture.
When it was designed, XenApp 6.5 was part science and part art. The art part was designing how zones, sites, and farms would be created. IT expended effort figuring out how data collectors would be set up.
Everything is different with FMA. Now you have to worry about SQL Server replication. That means you have to re-tool your IT team. The skills your IT team learned to configure XenApp have to be replaced with skills for folks who know how to replicate SQL Servers.
IT had methods and workflows in how they manage the IMA infrastructure. But those no longer apply because there are completely new management consoles -- Studio and Director. Existing, well understood tools -- like Resource Manager or MMC plugins -- are tossed out. To this mix, you add a migration from Web Interface to StoreFront and the infamous DDC in HA mode. With everything new, you're team will be spending a lot of time in Citrix training classes learning FMA from scratch.
(3) You better have a bunch of money in your budget for extras.
You don't only have to consider the cost of the upgrade. Since this is a brand new architecture, you are going to have to go back to the drawing board to figure out how to migrate from IMA to FMA. You may have to hire consultants who understand the migration process. And, unlike IMA, there aren't a ton of FMA-trained consultants.
Then there are additonal licenses and components. You have increased CapEx with more Windows Server and SQL Server licenses. If you want to reduce risk, you'll have to splurge for Windows Server and SQL Server Enterprise edition to get better HA support. Of course, all of this -- the higher edition of Windows Server infrastructure and consultants -- come with a hefty price tag.
(4) It'll take you between 6-9 months to deploy FMA architecture.
Starting from square one is tough for a new customer that doesn't have Citrix. But you have already run Citrix XenApp for years. Now, you'll be facing another 6-9 month period of running a PoC, sizing, testing, and then finally deploying to initial users. That seems staggeringly hard.
(5) When it's all in place, you'll experience slower login in times and less reliability.
For many customers, IMA login time = go get a cup of coffee. FMA login time might = go get lunch. FMA connections require approximately 14 separate connections and communications between different FMA components to set up a connection. If any of those components hang or fail (not calling you out Storefront services!), the end user experiences a connection that keeps retrying until it times out. You might want to beef up the help desk staff.
Keep pouring money into that old Pontiac or trade up to a Tesla?
XenApp 6.5's underlying architecture stems from 1997. It was built in an era where most infrastructures ran on-premises and most applications were Windows client-server. The world has changed a lot since then. The newest and sleekest solutions leverage the cloud. New solutions solve for all applications, including custom web apps, packaged web apps, SaaS apps, HTML5 apps, and CIFS. If you have to migrate to a new solution, why not get a solution that was built in this decade?