From 8 April onwards Microsoft will no longer support nor patch Windows XP. Therefore, the time for a Windows XP exit is now! Nearly 30% of all personal computers worldwide are still running on Windows XP. The fact that it has been one of the most stable Windows operating system (OS) explains this phenomenon.
Companies often underestimate the impact of such migration projects. From technical point of view it is considered as a kind of maintenance with less risks. But a Windows migration project touches everyone in the organisation: from the engineers in the field to the VIP’s in the board room. Any malfunctioning will not stay unnoticed.
For these reasons it is better to think twice before starting that kind of upgrade and take following points into account.
- Windows 7 or 8?
It all starts with the decision about the next version of your OS. Choosing for the smallest step possible, Windows7 will probably be the better candidate as it still has a similar Windows XP look and feel. Windows 8 with its metro style layout is a big change for end users and can evoke a lot of resistance. However with a good communication and training plan, which is typically part of a change process, this impediment can be dealt with.
- Deployment strategy
Deploy a new OS to all devices in the organization is not a simple walk in the park. It requires a detailed planning and a very good insight in the business of the company. For example it is not a good practice to upgrade all workstations of a nuclear control room in one shot. Similarly trading rooms will not allow any interruption or downtime due to a Windows migration project. In such cases a phased roll-out with some buffer period is a must. Having key users of all departments on board of the project can help a lot to develop a bullet proof deployment strategy.
Another important tip: take the necessary time for the roll-out. Based on our experience in most companies it takes one year from the start until the last migrated device. In case the upgrade must still be done, there is no year left before 8 April 2014. Following suggestions can help to define the strategy:
- Strip the content of the migration to a strict minimum. This means that only the Windows operating system will be migrated and any other upgrade (e.g. MS Office, Acrobat Reader) is out of scope.
- Get an overview of all devices which are in scope of the migration
- Define waves and allocate the devices to one these waves based on criteria (e.g. business criticality, …)
- Start the migration after a period of thorough testing of the new configuration. For more info about testing see further in this post
- Other correlated migrations
Migrating an OS is often the trigger to upgrade other basic software components as well, like Office, Acrobat Reader, Java Runtime, Oracle client…. If these upgrades are combined with the OS upgrade it increases the complexity in terms of installation sequence, configuration settings and group policies. Moreover it will increase the scope and depth of applications that need to be tested on compatibility with the new platform.
This aspect is too often neglected but will definitely contribute to the success or failure of the migration project.
The choices made on the previous topics will define how the test strategy looks like. Just a small example: if the 64bit version of Windows7 is chosen, the risk exists that a lot of legacy applications are no longer compatible.
Like in an application development project, some basic testing rules can be applied:
- Risk based testing
Especially when the OS upgrade is combined with other upgrades (e.g. Office, Java runtime) an overview of all impacted systems is needed. Based on this overview prioritizing test efforts based on the MoSCoW principle can be started.
- Regression testing
In theory upgrading towards a new version of a product (e.g. Windows, Office) does not change the existing functionalities of an application
. However testing for regression as result of other group policies, configuration settings, deprecated VBA functions is required.
- Hardware testing
With an upgrade of an OS new device drivers will come along as well. Besides a regression test of the applications all devices (e.g. labelprinters, webcams, conveyors, …) require compatibility testing with the new OS.
- Involve the business
In theory business should not develop their own applications. But there are a lot of own developed or bought systems which are in most cases not officially supported by the IT department. Moreover some of these “custom build” sheets, documents etc. are business critical and need to get support in case they are incompatible with the new platform. Therefore it is important that key users can test on a sandbox which contains the new configuration.
- Risk based testing