How to Identify and Prioritize for Testing Program Compatibility

To ensure that potential program problems are resolved before deployment, Microsoft recommends you begin to develop a plan for testing your Windows-based programs early.

Due to fundamental new technologies in Windows 2000, you need to test your business programs for compatibility with the operating system as part of your Windows 2000 deployment project. Even if you currently use Microsoft Windows NT, you should not assume that all of your programs will work the same under Windows 2000.

These programs might not take full advantage of the new features available in Windows 2000. They should, however, still perform as well on Windows 2000 as they do on the current platform.

Many organizations have more programs than they have the time to test. In this case, you need to prioritize them, and then test the ones that are critical to your core business operations.

Identifying and Prioritizing Business Programs

First, identify your Windows-based programs and prioritize them by how important they are to your business.

When you identify your programs, identify which ones are required for each business unit. The following list includes some examples of information you might need about each program:

• Program name and version.
• Vendor name.
• Current status (for example, in production, under development, no longer used, and so on).
• Number of users and their business units.
• Priority or importance to your organization.
• Current platforms where the program is used. Include whether the program is client-based or server-based and which components reside on the client and on which ones reside on the server.
• Web site addresses (or URLs) for Web-based programs.
• Requirements for installation such as security settings and installation folders.
• Development tool or technology (if developed internally).
• Contact names and phone numbers (internal and vendors).

Compile the program information in a central repository where you can easily use it and update it as you gather additional information and prioritize the programs. When you begin testing the programs, you can also use this repository for entering test results and reporting status information.

When prioritizing your programs, you need to consider each program, no matter how insignificant it seems.

IMPORTANT: Any program that does not function properly may have a large impact on the users who depend on it.

You need a prioritization scheme for the following two reasons:

• You might not have time to adequately test all programs by the rollout date.
• You need to know which programs are truly "mission critical" (the programs that absolutely must function properly for deployment to proceed).

The ultimate goal of your prioritization effort is to identify the core group of programs that must function properly before you begin to deploy Windows 2000. When you develop your prioritization scheme, consider the following issues:

• Localization needs.
• Availability of newer versions.
• Number of users affected.
• Importance of the program to the organization.

NOTE: Prioritize your programs for your disaster recovery plan.

If you previously identified which programs must be back online first after a disaster, these programs might have top priority for compatibility testing. As an example, your company might define program priorities as follows:

Mission Critical

These programs can be offline no more than 48 hours after a disaster. They may be required to collect revenue or fulfill a legal obligation. The organization is willing to accept no risk or very little risk of failure for these programs, and the impact (or cost) of a failure would be very high.

Business Critical

These programs can be offline no more than ten days after a disaster. They are required to run the business infrastructure. Human resource programs are an example of business-critical programs. The organization is willing to accept little risk of failure, and the impact or cost of failure would be moderate.

Required

These programs are required to run the business, but can be offline for up to 25 days. The organization is willing to accept moderate risk of failure, and the impact or cost of failure would be low.

Other

These programs do not easily fit in any of the preceding categories, and the business can continue without them.