Migrating to Windows 7 is presenting more challenges to business than any previous operating system migration, for a number of reasons.
Historically, Microsoft rolled out NT4 in 1996 and followed up with XP in 2001. Windows 2000 I would label a "stop gap" release which was skipped by many companies. Vista was released in 2006, but was bypassed by the majority of corporates due to its demanding hardware requirements and the perceived problems in migration. So in essence, a significant major release of windows has happened on average every five years.
With the poor uptake of Vista, clearly there was significant impetus to bring Windows 7 to the market as soon as possible, and to make it everything that Vista should have been. So Windows 7 appeared three years after Vista, and offered significantly improved performance over Vista allowing it to be used on the majority of existing hardware currently in use in corporates - hardware which has until now been running 32 or 64 bit versions of XP. Importantly, much of the hardware would run without significant degradation of performance, while offering substantial improvements in security and manageability.
However, there is no escaping the fact that the operating system forms only a small part of the corporate IT infrastructure, and that infrastructure is likely to have been running with XP for anywhere up to 8 years. During that time, the application inventory has undoubtedly grown without having undergone any rationalisation exercises since the deployment of XP.
Application rationalisation and compatibility testing now becomes the largest and most business critical component of any migration to Windows 7, but having the right back end infrastructure is also a vital component of a successful migration.
Having had some involvement with the early adopter program offered to selected corporates by Microsoft, it is clear that even with help from MS consultants, there were innumerable issues to face and overcome that were not initially perceived as critical path. Early adopters commit to deploying a certain number of desktops running Windows 7 as a pilot project, and as there is some business risk associated with a pilot, the users chosen to participate typically include some users from an IT department such as the Helpdesk,
and other users from a business group that is not a profit centre, such as the HR department.
The business "end users" chosen for pilot often have a smaller application portfolio, and are able to perform most of their duties using the standard Office apps. This simplifies the application packaging and compatibility testing workload substantially, and at the same time provides the company with a basic platform to use for further testing.
Early adopters face a number of additional challenges, as many application and utility vendors wait until the RTM release of an operating system before starting any serious testing programs for new software releases.
This can cause problems where vital components such as antivirus programs are not fully certified for use with Windows 7 at the time that the corporate testers are ready to roll out pilot machines. More critically, hardware suppliers can take several months to provide Windows 7 drivers for their various PC models, especially for older hardware. However, this aspect has been handled particularly well by
Microsoft, who have clearly learned from past mistakes and for Windows 7, have spent a considerable amount of time and effort providing drivers for the standard chipsets used in a substantial proportion of the hardware that has shipped in recent years.
Having performed test updates on a variety of ageing hardware, it was unusual to find any system that showed more than one or two missing drivers after a clean install of Windows 7. One particular 64 bit system based on an MSI motherboard and an NVidia video card was found to require NO additional drivers after a clean Windows 7 install - a most impressive achievement.
At the same time, many legacy printers are still able to be used, as drivers are available via Windows Update. Our test printer, an ancient HP deskjet 720C from the early 1990s, is still being used in our Windows 7 environment as driver support is still available. Once again, Microsoft have worked very hard to allow users, both corporate and domestic, to leverage existing hardware and thus minimise migration costs, at least from a hardware perspective.
Once a pilot is underway, the shortcomings in the existing back end infrastructure become increasingly evident, and the scope of the migration project starts to grow. Many companies use SMS for application deployment and have not migrated to SCCM as there was no technical requirement until Windows 7 arrived. However, Windows 7 requires SCCM and thus companies are having to undertake a parallel project to update their SMS environment to SCCM. This move is often a catalyst for a review of server utilisation and rolls into a server migration from hardware to virtual server environments to offer improved load factors at reduced cost, power and cooling requirements. Thus what started out as an operating system update starts to grow into a much larger, much more expensive, and much more complex, infrastructure update, and the project end date starts to vanish into the distance.
Existing tech resource is stretched increasingly thinly over an ever growing workload and the chances of a major IT disaster start to increase exponentially.
Thus for any company planning their first major migration in 7 or 8 years, it is absolutely vital to undertake a root and branch review of the entire IT infrastructure to determine what elements are Windows 7 ready, and what elements will need to be updated in order to support the new operating system "build". This must include the staff who will be providing first line support to the business users, as business continuity has to be give a high priority in the overall project.
So what comprises a "build"?
I often draw a comparison with an onion - a whole made up of many layers.
The simplest, innermost layer, is the operating system itself, with the necessary drivers to support the hardware inventory of the corporate user base. Microsoft provide comprehensive toolsets to facilitate the creation of Windows 7 builds, and the ultimate goal of many companies is to create a single 32 bit and a single 64 bit image that can support all the different desktop and laptop machines that users work with.
In practice, the number of operating system builds tends to be greater than two, driven by specific business and/or regulatory requirements which demand a non standard configuration for specific user groups.
This layer also typically contains the SCCM agent or whatever application deployment agent the company uses, as without this agent, the deployment of any additional apps remotely becomes impossible.
The second layer contains standard runtimes and framework files. In this layer I would expect to see all the .NET frameworks up to 4.0, plus standard runtimes such as the many versions of ISScript.MSI, Visual C++ 2005, 2008 and 2010 series runtimes plus the latest windows media player, quicktime player, Java Runtime, DirectX drivers, Antivirus and Antispyware programs, and any other drivers or runtimes that are utilised by in-house developers and/or are relevant to the entire user community. This may include any company specific management utilities and applets.
The third layer consists of the standard Office apps and site licensed utilities. In this layer, I would expect to find programs such as Adobe Reader, Microsoft Office, (or equivalent), Visio Viewer, Winzip (or equivalent), whatever browser(s) are supported by the company, messaging clients, and business specific apps that all users will require.
The fourth layer consists of applications that are specific to each business unit and which are therefore deployed to small groups of users.
The fifth layer consists of highly specialised software that is licensed on a per-seat basis and may require addition hardware such as a dongle, and may also require manual installation, or have a hardware component associated with it.
How this onion is sliced varies from corporate to corporate, can vary over time, and can vary according to supply chain.
In my experience, the most common approach taken by corporate users is to combine layers 1-3 into their base image, which is then sysprepped ready for deployment to hardware by one or more of several methodologies. In a major migration project, where a substantial inventory of new desktop and laptop hardware is being deployed, it is common to find that the base image is provided to the hardware vendor and is pre-installed on new machines, so that they are ready to be put on desks and joined automatically (or manually) to the corporate network. The same base image is also made available to in-house support teams for deployment and redeployment to existing hardware as and when required. If the infrastructure is capable of handling the traffic, remote deployment of these images to existing hardware can also be undertaken, as part of a larger migration strategy that can include retention of user preferences such as desktop
wallpaper and browser favorites.
Layer 4 is then typically installed by the application deployment system based on the membership of each machine in the appropriate business group in active directory or in SCCM. For large business groups, a "tactical build" may be created which contains layers 1-4, to speed deployment, but once the initial deployment phase is complete, the tactical builds are retired as otherwise their ongoing maintenance and update requirements would increase overall service costs.
Layer 5 is typically a manual install where hardware components are involved, or where the user group is less than 5. Complex software protected by dongles can be extremely time consuming and complex to prepare for remote deployment, so from purely a cost perspective, manual installation and configuration is a much cheaper, faster and more reliable solution.
Clearly there are many different ways that these layers can be defined and managed and each corporate will try to fine tune their processes to most efficiently represent their business requirements, some with more success than others !!
I mentioned earlier that application rationalisation and compatibility testing is the largest and most business critical component of the migration, yet this aspect is frequently given a much lower priority than it demands, if the business is to be kept operating at peak efficiency. All too often, the operating system build design team, the application packaging and deployment team, and the desktop security team have
little or no contact with each other until the build is released, causing all sorts of avoidable problems when pilot testing commences. These activities cannot be carried out in isolation and these teams need to work together from day 1 to ensure that pilot testing is more an affirmation of correct design rather than the start of endless bug fix releases, with attendant disruption to, and ultimately disillusionment of the user community.
Those companies that skipped a migration to Vista, now have to come to terms with the additional security features of Windows 7, that build on the security features such as User Account Control (UAC) that were first introduced in Vista.
Windows 7 no longer supports 16 bit applications, and in addition to this, the latest generation of desktop and laptop machines now ship with dual core and quad core processors and often have a minimum of 4Gb RAM installed, and are thus prime candidates for 64 bit operating systems. Application compatibility testing thus has to address two separate issues.
The first is to identify all applications that are 16 bit and will therefore not be able to run on the native Windows 7 platform, and the second is to identify all apps that will not run on the 64 bit version of Windows 7. Although WIndows 7 supports an XP-compatibility add-on, this in itself presents many additional implementation and management issues and thus many build designers regard this as a last ditch solution when all else has failed.
Audits of application inventories in large companies frequently identify several business critical applications that are 16 bit and have been running unchanged for several years. In some cases these apps were written by an employee who left the company several years ago, and of course the source code has long since been lost. In other cases, bespoke software purchased from an external supplier needs to be updated to a current version, or an update commissioned, with attendant costs and delays. Where the costs of updating cannot be justified, an alternative solution then has to be developed and factored into the project plan. Many old applications were developed at a time when operating system security was much less stringent than it is today, by developers that assumed users would have admin privileges, and who wrote information into INI files located in the windows folder, totally ignoring Microsoft best practices. Code signing and manifests were unheard of, but today form an integral part of new applications written for Vista and Windows 7.
Making these applications work in the Windows 7 environment while maintaining system security can present a substantial challenge.
Badly written apps that do not follow Microsoft standards for API calls and shell folder definitions may not run correctly on 64 bit windows even though they are true 32 bit programs, and this too can prove extremely challenging to resolve.
Microsoft's Application Compatibility Toolkit is invaluable in such application testing as it quickly highlights potential security and permissions issues within an application running with standard user rights, and thus facilitates the identification of project milestones that will need to be hit before any specific business unit can be migrated successfully.
It is vital that the output of the compatibility testing is available to the build, application packaging and security teams. From this output, a set of security and packaging standards can be prepared. This ensures that the application packaging process conforms to standards that are understood by all tech teams, and facilitates the generation of group policy settings where appropriate. The application packaging team
are best placed to know all the runtime components that should be in layer 2 of the build, and also to advise on any variations to standard file, folder and registry permissions that may be required by individual programs in order to ensure correct execution. By placing these runtimes into the base build, the packaging process is considerably simplified, costs reduced and maintenance enhanced as the runtime components then come under the control of the standard update processes.
From a migration planning perspective, it will be necessary to engage with each business unit, to identify their current application portfolio using audit tools remotely and/or manually. The audit will usually indicate that substantial rationalisation is possible and will often highlight deficiencies in product licensing that need to be addressed.
Inevitably there will be disagreements about funding as business units will argue that a corporate upgrade which is being "thrust upon them" should pick up any migration costs from central budgets, while the migration project managers will argue that software licensing of
applications specific to a business unit should come out of the business unit's own budget. So from a political perspective, it is wise to establish corporate ground rules for the budgetary aspects of a major migration ahead of the event, so that business units can factor some costs into their next budgets and not end up in a battle over costs when the focus should be on ensuring business continuity.
Identifying migration leaders in each business unit, and ensuring they receive regular briefings of the project status will go a long way to ensure buy in from the users, and their cooperation during pilot testing.
A migration from XP to Windows 7 additionally presents the user base with a GUI that has significant differences, so the project plan must include training and support for the user community both before and during the migration phase, to ensure a smooth transition. Clearly some users will already be familiar with the Aero interface from having it on their home machines, but others may still be happily using XP at home and be unfamiliar with the new GUI. Since many corporates are also still running Office 2003, it is likely that a major migration will result in deployment of Office 2007 or 2010. Once again, the change in the Office GUI warrants provision of user familiarisation and training ahead of the migration. Such training can be provided by targetted one day courses in a dedicated training room, or by online CBT modules, or a combination of both.
To achieve a successful and trouble free migration therefore requires a substantial investment in both time and manpower, both from the IT teams and from the business. The scale of the project will naturally be determined by the size of the company and by the size of the application portfolio, and costs will always be an issue.
Nevertheless, it is vital to consider the hidden costs in terms of lost productivity if insufficient funds and manpower are allocated to ensure that all points discussed here are adequately resourced.