When migrating PC OS, every organization has to test and package all its applications before deploying them on the new platform. Having reviewed the application portfolio (and hopefully rationalized it), the applications they intend to redeploy will present three options:
- Re-packaging, for the ones that don’t present problems with the new OS
- Remediation, for the ones which present challenges that can be addressed (either through upgrades to the application or a work-around)
- Replacement for the ones which present insurmountable problems.
For those they intend to repackage, virtualization should be the preferred approach. A virtualized application runs in it’s own little “bubble”, isolating it from other applications around it and decoupling it from the configuration of OS. This significantly reduces integration overhead, making the application far more portable: it still runs locally, but is far easier to handle than one packaged for local installation. Operations that involve the application will be simplified, delivering ongoing cost savings. Virtualization also delivers immediate cost savings during the migration, since there is no need for any regression testing of an application that’s been virtualized.
However, few organizations will be able to virtualize every application; some applications have complex inter-dependencies or need direct access to drivers. This means the virtualized and non-virtualized applications will need to co-exist in parallel, potentially until the next OS migration. But this won’t be a problem – provided the virtualized and non-virtualized applications can be stored and delivered using the same management processes and tools. There is only one application virtualization product in the market place that can do this for every software distribution tool and application depot: VMware ThinApp.
This facet of ThinApp demonstrates one of the most important principles for any technology change along the journey to better end-user computing (EUC). Most EUC costs are operational, driven by the actions of management processes and tools. If a technology change would require additional processes and tools, then the change would drive new costs – not help create savings that can be re-invested. It is also unlikely that any technology change will be applied equally across all users at once, so the “old” will always need to coexist with the “new”, at least for a while. It is thus critical that the old and the new can be managed through the same management processes and tools. We refer to this principle as “it works with the existing plumbing” and you will see that it underpins the major technology changes along our journey path.
For the applications that have to be replaced, it’s essential that the new ones will not require the same level of attention (and repackaging) during the next OS migration. The best way to ensure this is to select OS and browser-neutral approaches. SaaS applications and those based on a web-services platform, such as VMware’s Zimbra collaboration suite, should be the preferred options here.
