As a newbie at Citrix, I was excited about trying out the various applications and tools that my team had developed.

As a CLM team member, I had the opportunity to try out the XenApp 6.5 to XenApp 7.6 upgrade procedure. The Engineering team came forward to help me understand the processes that made up the upgrade. Additionally, I also had the user manual which was written recently.

So, here we go! My first experience upgrading from XenApp 6.5 to XenApp 7.6.

The URL to upgrade: https://workspace.cloud.com/ .  Now, to manage the Lifecycle Management, I clicked the Manage button at the bottom of the page. Or, you could click the horizontal bars on the top left and then click LifeCycle Management. A display on mouse-hover to view the list would have been a better experience, to my mind.

There are similar instances in the procedure where mouse hovers would considerably reduce the number of clicks.

1

I could see the new page loading for about 10+ seconds. The Lifecyle Management page appeared. I clicked the Upgrade tab and then the Add Upgrade Project link. The Add project page appeared.

2

It would have been better if the cursor was at the Name field by default. I learned from the user doc that  Name and Upgrade Type were mandatory, but  Description was optional. Either we could have the “optional” text next to description or an asterisk for Name and Upgrade type. After choosing XenApp 6.5 to XenApp 7.6, I clicked Add.

I landed at the “Choose an option for how you would like to upgrade” page. I saw two options. Fully automated (chosen by default) and Partially Automated. If you wish, you may read the three stage lesson about fully automatic upgrade. Then, I clicked the Next button.

3

Here I am at the XenApp 7.6 deployment details page.

I chose the Connect an existing deployment created outside of Lifecycle Management option. There are two selections to be made here. For the first one, All existing machines is selected by default. And I now clicked Select XenApp Controller. The XenApp controller details page appeared. I deliberately scrolled down the drop-down list to reach Cannot see Controller Server?.  The download happened perfectly and I placed it in the controller server and refreshed the list. My 7.6 controller was now listed. I provided the username and password and clicked Save. In a few seconds, the system fetched the delivery groups from the XenApp 7.6 machine.

4

Then I moved to XenApp 6.5 Farm details. Just like XenApp 7.6, All existing machines was selected for XenApp 6.5 environment also, and I went ahead and selected the XenApp Controller. After I selected the controller and saved, it instantaneously returned to the third step (Analyzing).

5

When I was wondering what this Analysis was all about, my friend in the development team explained to me that when I started to Analyze XenApp Farm, a blueprint ran on the XenApp 6.5 machine and collected the information about all the applications and policies available in the 6.5 machine. It then created an XML file and stored all the information in it.  This XML was stored in the S3 storage. Then, the number of applications and policies that have been analyzed are listed.

6

I clicked Next to select from the analyzed applications and policies. Then I clicked Proceed to Migration.

7

In the Proceed to Migrate page, I saw a default batch name already provided by the system. You can change it if you want to. And you can either use the existing delivery groups or create a new one. I left the default name as it is. Then, I clicked the Migrate button.

8

The migration happened and my upgrade from XenApp 6.5 to XenApp 7.6 is now complete. I learned that this is a seamless upgrade process from IMA architecture (6.5) to FMA architecture (7.6). The Upgrade feature intelligently exports my existing farm policies and settings and seamlessly imports them into my new XenApp and XenDesktop 7.6 site.

During the migration process, Lifecycle Management creates a Delivery Group in the XenApp 7.6 Site and imports the selected application and policy settings from XenApp 6.x.

To verify the migration, I launched the Citrix Studio and connected to the Site. In the left pane, I clicked Delivery Groups. In the top middle pane, the Delivery Groups tab displayed the new Delivery Group. In the lower middle pane, the Applications tab displayed the migrated applications in the new Delivery Group.

Additionally, to view the migrated applications and policies, I went to the Store Web Receiver URL and opened it in a browser. And here we go…

The applications and policies that I migrated are now available in Citrix Receiver ! !

9

Total number of clicks for the entire upgrade: Approximately 21.

Time taken for the automatic upgrade using existing deployment created outside Lifecycle Management (one application and one policy): Approximately 8 minutes.

The whole experience of migrating was very easy and quick. A few user experience enhancements would elevate the migrating experience to a higher level.