If you use App-V 4.5 or 4.6, you might want to start thinking about your migration plans.
Microsoft App-V 4.5 users are currently in the Extended Support phase of the product lifecycle, which ends on Jan. 8, 2019. App-V 4.6 users have a few months to go before entering Extended Support, which happens on July 14, 2015. Extended Support for 4.6 ends on July 14, 2020 if you're keeping score at home.
It's clear that you're safe for now; the end date isn't looming ever-closer on your calendar like it was with Windows XP (yet). But this is a good time to start planning your migration. What should you migrate to? Microsoft App-V 5 seems like the easy answer, but while you're going through the exercise -- and since you have time -- take a step back and look at why you're doing application virtualization in the first place. It's possible that your reasons today are very different than they were when you started.
Why you adopted app virtualization
Back in the early days of application virtualization, the primary use was isolation. We had a so-called "DLL Hell" where different versions of the same applications needed to coexist on a single instance of Windows.
Additionally, there was a streaming component to application virtualization that appealed to many companies. With app streaming, only the bits that the application needs are sent to the user's desktop. The application still executes locally, but its footprint is reduced. If a remote user needs Word, you can deliver it to them on-demand, and the less-essential bits transfer at a lower priority than the ones the user needs right away.
Since those days, application virtualization has been gradually changing use cases, moving away from isolation and app streaming, and becoming more about pure application management.
Why you probably use it today
The foundation of application virtualization is based on creating application packages. These packages can contain single applications or groups of applications that depend on one another, like Outlook with certain plug-ins. Even if you forget about isolation and app streaming, these packages are extremely useful for minimizing the number of base images you have for your desktops, both physical and virtual.
The problem is that with traditional application virtualization -- by which I pretty much mean Microsoft App-V and maybe VMware ThinApp -- you can't package everything. For one reason or another, some applications just won't work, so they need to be put in the base image. The reason for this is different for each application, but it is usually because of a feature in a legacy application that companies might not even care about. If you're only trying to use application virtualization as an application management platform, this can be frustrating.
With that in mind, if you're thinking about migrating from App-V 4.6 to 5, look at the way you use application virtualization today. Do you need the isolation, security and app streaming capabilities? If so, keep doing what you were doing.
If it's just a glorified application management platform, look at the alternatives. There are plenty of modern application management platforms that take unique approaches: FsLogix uses policies to hide applications from Windows even though they're all installed in the base image. Cloudhouse uses application packages that default to an integrated state rather than an isolated one. Spoon runs applications in a micro-VM that is deployed as part of the package from a Web front end. Even VMware, which owns ThinApp, has a different product for managing applications today; App Volumes bolts on virtual disks that are modern application packages.
There are many choices out there, and which platform you go with depends on how you intend to use it. Nobody wants to switch platforms, but if you're going to have to do it anyway, there's no time like the present to take a look around.
App virt breakdown: App-V vs ThinApp vs XenApp
Citrix ditches Application Streaming, guides users to App-V
How to use App-V Sequencer