Many companies have made it clear that their end users want applications and data to follow them across any device and any cloud. But failure has been a painful pill to swallow for many talented architects and engineers who have tried to adopt desktop and application virtualization solutions. Many didn’t know what they didn’t know about the “client clash” in the cloud, with rising mobility, solutions that enable consumerization of IT, and the new generation of digital native users.

Over the years, I have spent quite a bit of time with customers trying to deploy thousands of applications across millions of endpoints on both physical and virtual environments from the client to the cloud. Regardless of company size, pilot pool, or environment, it is clear that fundamental changes in people, processes, and technology are needed for successful transformations to occur.

Based on original research from customers large and small who have embarked on this journey, here is some prescriptive guidance for transforming desktops and applications into universal clients in the cloud.

1: Step away from the machine; start with the user and business

Virtualization enables us to not only decouple the layers in the stack (Machine, OS, APPS) but also to separate the user and business from the technology. Before starting any transformation you need to understand:

  • The user’s role and impact on the business
  • What users are trying to do (content)
  • The context in which they are trying to do it (connectivity, environment, risks)

2: Assess the current asset landscape

The easiest way to get from current state to the cloud is to understand the landscape before plotting your course. What technologies are available from the client to the cloud that already work for your environment? What tools are available that will help ease the migration of your current applications and users to the new paradigm? What applications or tools will support a split environment during the transition and migration process from current to cloud? What partnerships or agreements are already in place to avoid duplicate costs, projects, and expense?

3: Identify and diffuse potential political landmines

The fastest way to kill your project is to not include or get buy in from other teams. The more successful projects include all the key stakeholders from the beginning to diffuse any turf wars over who owns the resources and budget. Every aspect of IT is affected, such as desktop, server, network, storage, asset management, and service desk. Many implementations have failed due to lack of cooperation and/or thought to include the other teams. Nothing kills a pilot faster than when the service desk doesn’t know about it and can’t meet service level agreements for key applications or employees that have significant impact on the bottom line.

4: Get your house in order

Automating bad processes is a bad idea. Before planning your new project, make sure you have automated the processes required to successfully launch a universal client project. If you know your software asset management system does not show what was purchased versus deployed, and this is done through a manual process, perhaps you should look for enterprise license optimization tools that complement your current asset system to replace the manual true up. Or if you know your company is implementing a private cloud, make sure you understand what it is replacing and how you can leverage it for this project BEFORE planning your project to see if timelines align.

5: Assess user and environment requirements

Before walking the proverbial plank down one implementation route or another, assess the user and environment requirements. Understanding overall usage of applications and in what context users need to access them is essential. Be sure the solution you pick will not adversely affect the company’s bottom line. For example, if road warriors need to use a specific application on a frequent basis but are often disconnected, a virtual application solution in a disconnected mode may work better than a software as a service solution. Or if the connectivity from the service provider to the user is not very reliable and/or powerful, an offline solution may be in order. An essential first step in the transformation is to rely on user and environment assessment tools to determine actual software usage.

6: Calculate risks — legal, security, and business

Assessing the overall risk to the company is always a good idea. What are acceptable risks and what are not? Are there key regulations that the company must adhere to, such as personal information acts that would affect where and how they access applications and data? What risks would alternative models such as “bring your own desktop” or streaming virtual applications to personal devices have on the company? Do your license contracts allow those types of implementations? What are the restrictions? Before you talk to your vendors, be sure you know how their licenses are being consumed within your organization today. The number of risk requirements and amount of costs can significantly influence your decision. For example, a less secure online word processor in a public cloud might work for a group of students in an English class but would not be advisable for a group of physicians who need to write notes on patients.

7: Create user profiles (categories)

Once you have details about your users’ overall requirements, the environment, and their roles, you should categorize them into their overall role or function. Examples of roles could be Knowledge Worker, Road Warrior, or Task Worker.

8: Assess application usage requirements

After identifying the right category for your users, it is time to identify the application requirements and good candidates to migrate to the new user paradigm. What applications are being used by multiple groups (such as Microsoft Word or Excel)? Which ones are used only by the Road Warriors (Sales)? How often do they use them? Which ones are used by accounting only once or twice a year for audit? Mapping applications and usage back to user category dependencies will help you create the best candidates for a pilot project. It will also help you understand which applications to virtualize or migrate first and in some cases, which ones should not be migrated/virtualized at all.

9: Assess application compatibility requirements

A good application compatibility assessment tool is critical for planning. The determination of whether to implement a specific application virtualization solution over another will vary depending on the user, content, and context. With three application virtualization architectures on the market today, it is difficult to ascertain the right solution for your desktop transformation requirements. The key is to leverage a streamlined Application Readiness tool that can assess all three application virtualization formats and remediate, convert, and work with your existing and new delivery mechanisms to support both current and emerging cloud infrastructures.

10: Map your route to implementation

Now that you understand the user, content, and context, create a route to implementation based on the business and user requirements. Your route can include a variety of technologies, people, and processes. Be sure to create a unified team across the business to help the success of the plan. Top performers always have a roadmap for success, so that if the pilot project takes off in a big way, they are prepared to scale and pull the trigger in a timely manner to move at the “speed of cloud” to reap the highest benefits. Knowing key performance indicators and defining what success is up front are critical to understanding whether the pilot truly achieved desired state. If it didn’t, take the time to assess and adjust routes to implementation based on changing business needs (user, content, and context).

Jeanne Morain is Director of Strategic Alliances for Flexera Software, and author of Client4Cloud: Desktop Transformation.