Many organizations are skipping Vista and looking forward to Windows 7. This research provides the necessary steps to prepare for Windows 7 and ensure a successful migration with adequate operating system (OS) support.

• Preparation is essential for a successful migration. Most organizations will require 12 to 18 months to prepare for a Windows 7 migration.
• Organizations that have tested or prepared for Vista and have good management systems and processes could complete the preparation process in 12 months.
• Complex environments will face additional issues and require more time.

• Allocate sufficient time and resources to upfront activities to lower the costs during migration.
• Although your planned migration may be more than a year away, don't delay the initiation of the preparation process.
• Form a project committee that includes members from each major business unit, as well as operational groups in the IT organization, to oversee the development of a project timeline that features high-level milestones and estimates required resources.
• Establish a formal, comprehensive and workable testing methodology to ensure that issues are identified and categorized.
• Plan on piloting for a minimum of three months. The shorter the pilot, the more problems will occur during the deployment.

The tepid corporate response to Windows Vista indicates that, for most organizations, Windows 7 will be the first major OS migration project in more than six or seven years. As they start their projects, many organizations are unsure how to approach the planning and testing process. Given that proper preparation is essential for a successful migration, enterprises should allocate sufficient time and resources to upfront activities. For most, this will take between 15 and 18 months, although some well-organized companies could trim the time to 12 months. More-complex environments will undoubtedly cause additional issues that will need to be addressed and added to the plan. It's important to get started early and regularly review timelines and plans.

For the most part, we assume that organizations have not made any significant progress with Vista preparations and migrations. Organizations that have done some preparation for Vista should find that most of their efforts are directly applicable to Windows 7, so they will be able to reduce their overall timelines (see Figure 1).

Organizations should establish a project committee and develop an overall project timeline. The project committee should include members from each major business unit, as well as operational groups from the IT organization. The project timeline should include high-level milestones and estimates of required resources.

Companies must obtain a detailed inventory of the user environments, including hardware, software and processes. Without this, planning and testing will be hit-or-miss, based on IT perceptions, rather than reality. Although many companies have a general handle on the PCs in their environments, most have more difficulty with the other components. A full inventory will include the following areas:

Although organizations should primarily install Windows 7 on new equipment, having a complete inventory sizes up the problem and provides guidance as to the order in which users are likely to be migrated. Organizations that have skipped Vista will probably need to perform some forklift upgrades, and will find that a detailed PC hardware inventory is even more essential. The inventory will also help identify deviations from corporate standards, and should identify where user data is being stored.

Along with basic configuration, age and model information, the inventory should also include more-detailed data (for example, BIOS levels, memory and disk space), as well as installed components (for example, adapter cards and chipsets). The Windows 7 Hardware Assessment tool can help identify potential issues. For the most part, systems purchased since early 2007 (machines that were released after the introduction of Windows Vista) should have no problems running Windows 7, unless they were poorly configured.

Decide which machines to upgrade based primarily on their age and secondarily on their configurations. If PCs purchased in 2009 and 2010 are chosen for upgrade to Windows 7 in 2011, their configurations won't really matter. Unless your migration costs are extremely low, don't plan to upgrade any PC that has less than two years of useful life left before replacement.

Even when PCs are replaced, attached devices are frequently retained. These may include monitors, specialized keyboards and mice, external storage devices, printers or other items that require supporting drivers. Business-critical devices (i.e., essential to the completion of a business function) should be identified. Fortunately, most devices supported on Windows Vista carry that support directly to Windows 7. This means that, for most organizations, only older legacy devices are likely to pose an issue for Windows 7. Device driver compatibility should be somewhat less of a problem with Windows 7 than it was initially for Vista. Only a complete inventory of peripherals can expose potential problems. If your plans include installing 64-bit Windows 7, expect to find more legacy devices without suitable drivers. This will require budgeting for their replacement, and adding time to allow for the additional work.

A software inventory must include all applications and utilities installed on corporate PCs. Many software inventory tools exist, including Microsoft's free Application Compatibility Toolkit (ACT) 5.5. It is not sufficient to restrict testing to "formally supported" applications, because users' opinions may differ significantly from those of the IT organization, resulting in substantial delays during implementation. All applications should be categorized into four buckets: business-critical, user-critical, support tools/utilities and all others. A weighting should be added that establishes each as broadly deployed, narrowly deployed or specialized. All business-critical applications must be determined to work on Windows 7, while all user-critical applications must operate or have reasonable workarounds. Because most support tools will require a new version after an OS change, replacements or upgrades must be identified for each utility.

Although not typically considered an asset, the processes and procedures that an organization has created to make the user environment functional are likely to be affected by an OS change. Hence, it's critical that organizations document all the processes associated with outfitting their users. This should also include a list of policies, including group policy objects (GPOs).

During this initial phase, organizations should create a testing facility/laboratory. It should include a representative sample of systems expected to be used with Windows 7 throughout the organization. Although it's impossible to have one of everything, any hardware combination used by more than 5% of the user base or part of a business-critical function should be represented.

During this phase, key members of the technical team should begin using Windows 7 (final code should be available to corporate customers in September 2009, or in August under programs such as MSDN and Technet) as part of their daily routine, followed by most IT staff. This leverages the most technically competent (and least likely to be seriously impaired) employees to spot potential problems. It also serves as an informal training ground.

The replacement of the OS is an opportunity to update the user environment and implement best practices. As such, it is good to survey the stakeholders (e.g., user groups, developers and IT support) to determine whether there are pain points or other issues that must be addressed. With this feedback and the complete inventory, four separate development areas must be addressed.

Organizations already using Windows Vista should find that little change is required for Windows 7. For the most part, all GPOs and administrative processes function the same for Windows 7 as they do for Windows Vista, with a few additional options.

Organizations currently on Windows XP will require more-extensive changes. Using Windows XP processes as a starting point, organizations must identify where Windows 7 5 administration will deviate. Organizations must examine the new features and capabilities within Windows 7 and determine a response. They will also need to become familiar with new GPOs introduced with Windows 7, as well as those that came with Vista.

Determining the deployment techniques that will be used is a critical decision. Even organizations bringing in Windows 7 on new equipment need to review image distribution, software deployment, and migration processes for data and settings. Organizations should also familiarize themselves with newer options, such as application virtualization, which might be appropriate for some applications.

Organizations also must identify the implications of leveraging new administrative capabilities in Windows 7 and plan to address these issues. This goes beyond changes to the administration tools built into the product; it extends to third-party tools that are likely to require an update.

Organizations need to determine guidelines for hardware selection. Although Microsoft has provided general hardware recommendations, these must be interpreted with respect to corporate standards and procurement practices. Organizations should review our regularly updated hardware configuration recommendations.

Companies must also revisit the question of lockdown for their user environments, given the improvements in this area provided with Windows 7. Again, organizations that have skipped Vista are likely to have more to do to prepare for a more locked-down environment, but even organizations running Vista will need to decide if any changes are required, based on the new user account control levels in Windows 7.

The final and most-critical piece of the development process involves the creation of an initial master build for a corporate user environment. This will include all the common elements included in a corporate desktop PC (for example, major applications, management utilities, security, and anti-malware tools and communication tools). It will be used for initial application testing, user pilot testing and as the basis for further customized builds.

Windows 7 adds a number of new networking and operational capabilities such as Direct Access, Branch Cache or Federated Search, which could have server dependencies and significant networking impacts. These will require additional planning and education to determine whether they are compatible with your infrastructure and, if so, how to properly integrate them into the environment. For example, the BranchCache feature may improve your software distribution capabilities, but the content that users access must be on Windows Server 2008 R2.

Organizations must establish a formal, comprehensive and workable testing methodology to ensure that issues are identified and categorized (for example, impact, scale/scope of issue and risk assessment). Unfortunately, most companies lack formal assessment processes, which results in inadequate and inefficient testing (for example, poor allocation of resources, insufficient test scenarios and incomplete regression). This slows the migration and drives up costs. Beyond providing assurance that the new OS will function for users, a well-designed testing process serves as a critical learning mechanism and development tool by identifying the shortcomings of the proposed environment and driving the development of workable solutions. Once the migration is under way, a formalized testing methodology will help organizations manage system images, application rollouts, service packs and other major initiatives that will emerge.

Establishing a testing methodology requires setting appropriate goals in the context of business objectives for exploiting Windows 7's capabilities. Organizations must decide early what "successful testing" means for different stakeholders. Although most think of testing purely for compatibility purposes, that is only one objective, particularly given the compatibility improvements during the past decade. Testing provides derivative value in training and experience; impact analysis of images, support processes and changed configuration options; and design, including the identification of opportunities for optimization provided by new features of the OS. A key requirement for testing is documentation to ensure that information gleaned from the process is recorded and followed up.

Before the new environment is rolled out, three types of testing must be performed: basic application testing, image testing and environment testing. Application testing involves testing applications' functionality with the new OS. Image testing includes testing a complete collection of applications and tools, ensuring compatibility of the image with hardware platforms and implementation tools. Environment testing evaluates the supportability of the new environment, including the processes for management, administration and technical support. It also includes usability testing, gauging users' reactions to the new environment and making necessary tweaks to ensure that it fits their needs.

It is impossible to test all combinations of hardware and software within any major organization. Most large enterprises can pare down the number of permutations by finding common system patterns. For configurations that cannot be represented in the laboratory, unless some business-critical external force is at work, a "test in production" methodology will generally suffice, assuming that high-level testing has been performed on similar configurations.

The way PC activation works for volume license customers changed between Windows XP and Windows Vista (and, by extension, Windows 7). During testing, enterprises should ensure that they are familiar with the volume activation options and include them in testing scenarios.

Application testing can be conducted concurrently with initial hardware testing. For each product, a formal checklist of test parameters and goals should be created, containing five sections:

• Installation: Does the application install cleanly or are tweaks required?
• Basic functionality: Does it start up, and do major functions work?
• Advanced functionality: Do specialized or rarely used functions, such as macros, perform?
• Interoperation and interaction: Does the application coexist with others, do communication and data interchange functions still work, and has the user interface changed?
• Performance: Does the application behave differently, and have hardware requirements changed?

Regression testing (that is, testing against previously discovered problem scenarios) is critical to ensure steady progression to a release candidate. Test scenarios should be built using help-desk records and notes from previous testing exercises. Reintroducing old problems will severely damage the IT organization's credibility and turn an otherwise successful implementation into a failure. During testing, any anomaly or change from the current version must be recorded. This implies that the tester is somewhat familiar with the current environment.

Deeper functionality testing is likely to require the participation of a user or a developer to create a formal script. IT groups should prioritize the application testing order based on the breadth of deployment, with the most widespread handled first. This will speed up the process of shifting to full image design and testing. Companies should also consider the ability to run applications in a reduced-rights user environment.

One difference between Windows 7 testing and previous versions is the availability of richer and more mature testing tools. Acresso's Installshield and Symantec's Wise Installer include capabilities to detect and mitigate conflicts between applications and the OS. Microsoft's ACT 5.5 has emerged as a solid tool for finding potential issues with application and device compatibility. It can be run on Windows XP systems to help triage the testing effort, enabling organizations to better allocate resources during testing and remediation. Customers should download and familiarize themselves with the ACT.

The Microsoft Deployment Toolkit (formerly known as the Business Desktop Deployment Toolkit) has also been expanded to include more tools and best practices. Testing tools that continually look for incompatibilities with new versions of Windows, as well as Service Packs, are available from such vendors as App-DNA and ChangeBASE.

Two areas of special concern for testing that might be overlooked are testing browser-based applications for compatibility with IE8 and testing applications in a 64-bit environment. With Vista, customers reported the most serious and often most difficult to remediate compatibility problems with IE6-targeted Web applications failing under IE7. This situation is unlikely to improve with IE8 in Windows 7. We strongly recommend that customers begin this phase of testing as early as possible, because remediation efforts may require recoding or adding virtualization to their environments. On the 64-bit front, it is likely that, by 2011, some users may require 64-bit support for their environments. Adding a 64-bit test environment will identify potential issues early, and, although it will add some additional effort, it will not seriously complicate the testing process.

Once application testing is well under way, attention must be turned to the development and testing of system images. This testing includes the same five categories as for applications, with particular attention given to interaction and installation. Image testing requires matching images to particular hardware configurations, and is likely to demand the largest effort. Device drivers for legacy peripherals must also be validated, especially if you're implementing 64-bit. Once the first few images are completed, subsequent ones will require a minimum of three days to create, followed by a day or more of testing.

The final area is the testing of internal processes. Many well-established procedures and policies will need fine-tuning or outright replacement with Windows 7. Particular attention should be given to migration processes, moves/adds/changes and ongoing support processes (for example, software distribution and system backup/recovery).

Once formal lab testing is done, pilot testing should begin. Piloting moves the testing out of the lab and exposes real users to the new environment. Most pilots should consist of at least two phases. The first should test basic builds, establish training needs, gauge general user reaction and enable IT staff to exercise their new Windows 7 skills. This pilot should be limited to a small group of users (fewer than 50) that does not perform mission-critical (or high-profile) activities, and should optimally last for 45 to 90 days.

Following this, a second, broader pilot extends the first by field testing installation and support processes within a production (but still closely monitored) environment. The broad pilot should optimally run an additional 45 to 90 days to ensure that the pilot tests extend across several different business process cycles (for example, month-end and quarter-end). For most organizations, a three- to four-month piloting period will be sufficient; however, those with more-complex environments, or those that encounter significant problems in early testing, may need to run for the full six months.

In many cases, organizations may be tempted to cut back on piloting to speed the overall timeline. Although both phases of the pilot could be completed in as little as two months, shortening the pilot period increases the likelihood that some underlying issues will not be encountered until the production rollout phase, when making repairs is more disruptive.

Once the piloting process has been completed, the preparation process is effectively completed. Organizations can then conduct staged rollouts of the OS to their user populations. Critical to all testing and piloting is ensuring that a suitable feedback mechanism is in place.

A formal testing process significantly smoothes the Windows 7 migration path by enabling companies to spot potential problems, adjust designs to better leverage new features and build experience with the nascent platform.