Step 1: Application Discovery
Application discovery involves creating a list of applications you consider
to be managed apps; apps which you need to validate on the new platform prior to
deployment. As you continue to evolve your Software Asset Management (SAM)
capabilities, the dimension that has the biggest impact on an application
compatibility project is the prioritization of applications. The ideal state is
to be able to place your apps into one of the following categories. (Although
you may call them something different, what is important is the behavior each
category drives.)
- Managed Apps: These apps are considered business critical, and therefore
require proactive testing to manage the risk when the environment is
changed, and more testing is required in response to higher risk migrations.
You should discover all managed apps before beginning the migration.
- Supported Apps: These apps are important to the business, but they can
be addressed during the pilot phase. While you may be aware of many of these
supported apps, it's not critical that you have discovered every one prior
to beginning a pilot.
- Unsupported Apps: These apps aren't supported by IT, and therefore you
don't need to be aware of them. You won't necessarily go out of your way to
remove them, but users are responsible for their own support of these apps.
- Banned Apps: These apps are ones that you will actively try to remove
from the environment. New technologies, such as AppLocker, can help enforce bans against these apps. While you may need to be aware of these apps to
implement a ban, you don't need to discover them through the application
compatibility project.
In some cases, it makes sense to start this discovery process with an
inventory of applications, ensuring that you have discovered everything that
ought to be managed. In other cases, it's more sensible to build a list manually
by just asking users. (This is particularly true in the case of platforms for
which the apps list is sufficiently large to make rationalizing that inventory
impractical, such as web URLs where a true inventory of unique URLs visited can
often reach the tens or even hundreds of millions.) It's not imperative to
discover every app that anyone has installed or used; "leave no stone unturned"
is not the approach you want to take. However, it is important to discover all
(or nearly all) of the applications that ought to be managed. (It's okay if you
miss a few—it happens. Just don't forget to make a note of those apps for next
time!)
Fortunately, there are a number of tools available that can help automate the
process of collecting an application inventory. You can use Microsoft's free
Application Compatibility Toolkit (ACT) or, another inventory mechanism such as
Microsoft System Center Configuration Manager or Microsoft Asset Inventory
Service. To make your managed apps list most useful downstream, you should
ideally capture more than just the application name. Information about who is
using an application, what the user's role is, and how important that
application is to the user can be very useful both for this migration and for
ongoing SAM activities.
The discovery process can also help you identify widely used applications you
may not currently manage. You'll want to get these into your orbit so you can
ensure they are properly managed, on the approved version, and have the required
software updates.
Step 2: Analyze Your Applications
How many applications do you currently support that have been replaced or
have otherwise fallen out of favor with business users? If you're like most
organizations, a sizable number of them or, in some cases, most of them. Once
you have completed your application discovery and have a good "lay of the land,"
the next step is to scrub your list of managed apps and filter them down before
you undertake the time-consuming—and costly—the process of regression testing. Some
applications should be demoted to supported apps and not proactively tested,
while others may be promoted and now merit additional scrutiny during your
migration. Set appropriate goals for your application portfolio. How many total
apps do you want to manage, and how many are you able to support? At what point
should an application be elevated to managed status?
After you set your goals, it's time to find the low-hanging fruit and narrow
down the applications that need testing:
- Eliminate redundant and unused applications. You'll undoubtedly find
that you have several applications that perform the same function. Now is a
good time to standardize on a single application per function, and eliminate those that have been made obsolete. One tip here is to try and map application dependencies, as you may need to support a legacy version of one application to keep another one supported by the ISV. And you'll want to drop those that are rarely or never used. You will make testing easier, and you might save on licensing expenses as well.
- Remove multiple versions of the same application and standardize on the
most current. In almost all cases, the newest version performs best and is the most secure and reliable. Again, watch for application-to-application
dependencies.
- Collect information from business users to help prioritize apps that are business-critical, and determine which departments are using which apps.
This will be useful when you sequence your testing process; you'll want to
align the timing of your testing to your staged rollout of the new desktop
image.
Step 3: Assess Incompatibilities and Mitigation Options
The next step is to determine which of your managed apps work correctly on
Windows 8. It's important to map out your process for performing this testing.
If an application requires vendor support, make sure your first step is to
research the current state of support. You certainly don't want to pay for the
rest of the process on an app you would never be willing to run! If you require
support but the version you currently have is unsupported, then your next step
is obtaining an updated version that is supported. Some people also choose to
research vendor support even on apps for which support isn't required. If the
applications are commonly used, you can usually find enough support statements
to make this a worthwhile activity—and a supporting statement is a great prediction
of whether the app works or not. Some customers choose to perform smoke testing
by technical staff, static analysis using compatibility tools, and sometimes
both. This technical testing can be very helpful in determining the
compatibility of the packages and the applications.
The final arbiter of compatibility is always user acceptance testing (UAT). The
user is the most important factor in determining that no bugs exist that effect
user scenarios. The work is done before UAT is, in many ways, designed to simplify
the process of UAT for the user, who is typically a volunteer whose cooperation
is not assured.
Along the way, you may find applications that need some work to get them ready
for Windows 8, particularly if you are migrating from Windows XP. At this point
you have several options:
- Replace the non-compatible application with a new version. This is
certainly the most reliable method, but unfortunately, it is also the most expensive. If the application is business-critical or otherwise strategic to operations, this is the way you'll want to go.
- Create shims for your existing applications. Shims are an application
compatibility feature first introduced in Windows 2000 that allows you to modify calls to the underlying operating system. For example, there are shims that allow you to simulate an older version of the operating system,
and shims that allow you to redirect file reads and writes to alternate locations. There is a small amount of management overhead since you'll need to maintain a shim database, but this approach is very powerful and can remedy many compatibility bugs. This is often the more cost-effective route
and might be the only option if the application vendor is no longer around.
One caveat: many vendors will not support shimmed applications. (Of course,
if the application is supported, then you can just call the vendor and
request an update—you don't need shims!)
- Use Group Policy to change the offending behavior of the application.
Modifying the system configuration using Group Policy can often take care of compatibility bugs, but doing so has some downsides. Essentially this approach uses policy to disable a particular feature or function that is causing the application to falter. Unfortunately, in many cases these functions involve the security of the underlying system, so the trade-off is significant. Likewise, the application must have Group Policy settings to enable this manageability.
For custom or in-house developed applications, you can modify the code. This
isn't always an option, but if it is, there are great resources to help.
Application compatibility cookbooks outlining the changes made between Windows
XP and Windows Vista, between Windows Vista and Windows 7, and between Windows 7
and Windows 8. These cookbooks are available as free guides to help developers
understand the changes to the operating systems in order to fix the bugs that
are affecting compatibility.
Step 4: Prepare for the Operating System Deployment and New Application
Delivery Options
The beginning of an operating system migration project is a great time to
rethink how you package and deliver applications to your end-users. Application
virtualization technologies have improved significantly and opened up options
that may not have been available the last time you decided on a packaging
standard; you should consider different models for application packaging and
delivery before beginning the testing process. You might find that the savings
in application packaging costs, along with savings in testing and readiness,
more than offsets the cost of implementing a virtualized environment—while
providing a more flexible and easier-to-manage application environment.
Virtualizing your application portfolio provides a number of benefits for
manageability and flexibility, but one key advantage is that you minimize
application-to-application conflicts. These conflicts arise when you need to run
two versions of the same application simultaneously—for example, when the help
the desk still supports multiple versions of an application, or when the finance
the department is migrating to a newer version of its accounting software but needs
access to the old one to close the fiscal year.
Step 5: Sequence Your Testing, Piloting, and Deployment Efforts
In Step 1, we talked about gathering additional information about your apps
to help out later in the process. One really great way to take advantage of this
data is to support a deployment process that allows you to build momentum and
see success earlier in the process!
One of the most successful deployment methodologies we have seen is to deploy by
role. Of course, deployment tends to wait until application compatibility is
finished, so if you can identify which applications are used by which roles, you
can focus on making all of the apps used within that role compatible first, and
you can then begin deploying to those people. But which roles should you choose
first? Considerations for making this choice often include how many apps are
used by people who perform that role (so you can hit roles with a small number
of apps first and see some early wins), or roles where a failure is more
tolerable (so you can work in a less risky environment while you are learning
your way).
Once you have tested the applications for a particular role, you can start a pilot
testing within that role. You may encounter additional application issues along
the way from your supported apps (hopefully not your managed apps, but if you
do, you can always leverage your fallback plan), but as long as your help desk
has the capacity to support those apps you can continue to expand the pilot until it
eventually becomes a complete deployment. Role by role, you can make your way
through the organization, working closely with the folks responsible for
operating system image deployment to coordinate and continue to build momentum.
Before you know it, you will have reached all of the seats you are targeting for
Windows 8 deployment!