<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

By David Butler-McAllister

David Butler-McAllister worked as a senior technical director of a very large investment bank before becoming co-founder and COO of Vappour Ltd - a new startup to tackle application packaging/conversion/automation/remediation of applications to virtual platforms. With years of experience in this field, we are delighted that David has chosen to share his views on application readiness and brings insight to the background and understanding of application packaging.

Application_Readiness

Tackling application readiness for desktop migration to Windows 7 and beyond...

Coming from a technology and finance background, over the last 15 years I have seen many techniques and various approaches to combat application lifecycle management for application migrations and platform migrations.

Applications and application readiness today are at the forefront of OS migrations due to the new and already emerged virtualization platforms for applications and infrastructure and for the future proofing of cloud readiness. Nowadays, applications are very complicated and the scale in which corporates use many thousands of them in such mixed environments is a very scary starting point for the project managers whom are accountable.

Let’s rewind here for a moment and go to the building blocks of how we used to tackle application readiness for platform migrations:

1) We all had a smaller footprint of applications; the scale to manage was far simpler.

2) We either managed the applications DLL or we didn't.

  • If we managed, then we had a good idea of what applications would work and which applications would not via shared DLL or OCX files on the new platform cohesively together, via Access or SQL databases.
  • If we didn’t manage, it wasn’t too much of a headache as we either paid an expert to do this for us, or we reviewed exactly what issues we had in desktop support.

3) We had fewer web apps and web platforms!

4) Staff were experts in Sysdiff/Novel Zenworks/MSI scripting/VB Scripting and were worth their money in this niche area.

5) Staff were mainly local in relation to the region that was conducting an O/S application migration and therefore closer to the business needs which ensured a greater understanding.

6) Application developers had fewer ways in which they could exploit the operating system – however locked down it was.

Let’s now fast forward to today and its complexities as I could very well get hung up back in the good old days and type for England!

Application readiness today is somewhat confusing unless upper management and the application development community grasp the full technical understanding of how applications fit into the overall roadmap of where applications will end up on a platform. Technology strategists and liaison to the business has to get tighter so that everyone knows what they are developing and how the application will get packaged/virtualized and ultimately tested/signed off and deployed.

16-bit applications are still used, and many 32-bit applications will not work correctly on a 64-bit O/S unless re-packaged and tested for full functionality. Many vendors are playing catch-up on making sure their own products are good for 64-bit O/S.

We all now know that not all applications are ready for virtualization and not all applications are ready for VDI. We also all know how great VDI is and how perfect it would be if we could get all applications virtualized so that the capabilities of VDI could be exploited to the fullest extent. Many large corporates are choosing physical desktops and physical applications whilst virtual applications and platforms organically grow and get better. Unfortunate as it is, storage costs, IO speeds and scaling out VDI for all without the applications just makes this platform a very expensive technology.

To tackle application readiness for desktop migrations to Windows 7 and beyond in today’s world means choices and, by golly, do the technology managers have choices! It is currently a world of products, products, products. In order of importance, below are my recommendations on the best approach if the $ didn’t matter:

1) Application View - You have to get a good view of your application portfolio.

  • Do you care about unmanaged locally installed applications or not?
  • Do you have the view on every managed application?

The only clear way I have seen the application view shared is with Juriba’s Dashworks product as you have the ability to link all your managed and non-managed applications in one web-based view and can then plan accordingly your migration.

2) Application Usage - You have to understand and get a very detailed opinion of application usage. Your users are key to understanding priorities for application packaging teams to focus on applications that mean these users are now ready to migrate.

3) Application Compatibility – You need to understand compatibility of your application portfolio. Many products tackle compatibility; the top 2 in the industry are very useful products. These products can assist you in your decision making for virtual and enable you to see the scale and size of your issues before heading towards your future state platform. Equally, they can assist with 16-bit identification and can also help remediate and report.

4) Application Packaging/MSI and Virtual – Either pay for huge packaging teams (onshore/offshore/outsourced/or vendors) to conduct your managed application packaging for MSI and virtual – which is a huge expense and very big management overhead – or, wouldn’t it be great to just push all your managed applications through a web-based tool that you download from the cloud and convert automatically to your virtualization platform of choice (even if only 60% of them really work)? This is what Vappour Ltd can help you with, in addition to helping you remediate your current MSI application from 32-bit to 64-bit automatically – how cool is that?

5) Application Testing – Choose to build large testing environments to mimic the production environment or pay a company to manage this for you as a service. Either way, the user experience has to be good – very good – or you have failed. Vappour Ltd offers a lightweight testing platform so you can test the applications that have been packaged and converted.

6) Application Deployment/Migration – You must manage this correctly in order to complete migrations to plan and keep in sync with business as usual application updates etc. The only way I have seen this view is again with Juriba’s Dashworks.

To finish off, I am going to share a conversation myself and business partner Kim Schulte-Zurhausen had the other day in relation to applications and their readiness for platform migrations. We know it’s far away at the moment, but within about 2-3 years time, with touch screen technology and the cloud platforms, we can see that applications will reside fully in the cloud and will be feature-rich, web-driven and written in HTML5. What will this mean to desktops and locally installed applications? Well, I think that’s another blog to write when vendors are clearer and HTML5 is more mature!

Barry Angell

Written by Barry Angell

Barry is a co-founder of Juriba, where he is focused on using his experience in IT migration to help drive product strategy, pre-sales and service delivery. He is an experienced End User Services executive that has helped manage thousands of users, computers, applications and mailboxes to their next IT platform. He has saved millions of dollars for internal departments and customers alike through product, project, process and service delivery efficiency.

Topics: IT Strategy Windows 10 Migration Application Management