Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Windows XP Migration: Making the Move to Windows 7, 8.1 or 10? Or am I asking the wrong question?

Damian Dwyer | July 14, 2015
The enterprise is changing. Web-based applications and mobile apps are becoming more prevalent and the way applications are procured and delivered is becoming more standards-based to meet today's multi-platform requirements. While this bodes well for the future, there will always be a requirement to access legacy applications, which adds untold complex processes for any organisation as it embarks upon its next Windows OS migration.

For organisations wanting to avoid the retraining overhead and resultant loss in productivity, Windows 7 remains an attractive option. Although it is now five years old and mainstream support ended in January 2015, it is a proven solution with a current market share of almost 60 percent. Also, a move to Windows 10 further down the line should be much less of an upheaval than the move from XP to Windows 7.

Interestingly, some organisations we work with are looking at a hybrid OS strategy: Windows 7 for office-based staff, and Windows 8.1 for field-based staff, such as salespeople and utilities engineers who need to update centralised databases in real time. This approach adds a layer of complexity relating to the connectivity and applications required, but this is more than made up for by improved productivity.

Application migration planning

Once an OS has been selected the hard work begins. The principal challenges for the IT team stem from the need to migrate infrastructure and applications in a short timescale, while continuing to support business services and adhering to SLAs.

Few applications have ever been deployed out of the box without a degree of customisation, adding an extra layer of complexity to any application migration project. It's no trivial task figuring out how the application has been customised and why. And what servers does it link back to? What dependencies does it have? Can the install be recreated? Where is all this information documented?

Once you know what you are dealing with, it's easier to set about simplifying your environment by rationalising your applications: removing duplicates, non-strategic applications, and applications with functionality now incorporated into other applications. Often a significant cull is possible, resulting in considerable savings in licensing and maintenance. Some of the applications within customer portfolios can simply be removed. A common discussion point relates to the addition of significant features within complementary products: for example, the ability to create PDF files from within the latest version of Microsoft Office removes the need for a separate PDF creator in many cases.

Like a throwback to essay writing at school, the key to a successful migration really is in the planning. Once the groundwork has been prepared, the process of packaging, remediating and virtualising applications can take place using industry-standard toolsets. An audit of which applications reside where, helps organisations to easily manage their software lifecycle going forward too. By adopting a methodical, proven approach known to deliver the best possible outcomes, organisations can minimise risk and avoid the dual spectres of project over-run and cost escalation.

If these hurdles seem too high, there is an alternative way to deliver business services. I'm talking of course about moving to the cloud.

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.