Small Steps & Giant Leaps to Migration

Comment | Print | RSS

• Login to Rate

The simplest answer might be that your organization is going to change one thing -- the client operating system, for example. The problem with that answer is that, as we've heard in an E2 Radio program, migrating a client operating system can mean touching over 15,000 individual pieces of software. Given that, the idea of intentionally migrating applications along with the operating system can seem like the sort of move guaranteed that no employee will get to sleep at home ever again.

Despite the potential problems, there are companies that take a "move it all" approach to migration, figuring that, as long as you're blowing up the infrastructure, blowing up the apps can cause only so much additional carnage.

One potential application migration some are considering is a switch from traditional hosted productivity applications (word processing, spreadsheets, and the like) to a cloud-based model. Imagine, for example, taking the opportunity to move away from desktop licenses of Microsoft Office to Office Web Apps. There are pricing and functionality trade-offs to be considered with the switch, but if such a thing is considered, why stop at the single Office possibility?

Once moving away from the desktop office productivity suite is brought into the mix, why not consider moving to a whole host of online suites operated by Microsoft, Google, or others? The argument could be made, in an online suite's case, that a cloud-based application better fits into the model of the mobile, BYOD-friendly modern enterprise. Furthermore, it might even be argued that moving away from client-hosted applications makes operating system migration less painful, since there is less opportunity for unexpected interactions between application code and the new OS.

Most significant in the "problem" list is the change in user interface. Let's not be coy, here: When changing operating environments, any shift in user interface -- no matter how minor -- is going to carry significant support and training costs. When you change both the basic operating system and critical applications from an interface point of view, you dramatically increase the likelihood that, for some portion of the employee base, productive work will come to a screeching halt and take days, if not weeks, to recover.

On the other hand, changing one major interface will also create a hit on productivity, so you can argue that additional changes cause only a bit more harm, and cause it one time rather than the two or more interruptions that a staged or staggered migration strategy can bring. In either of these cases, you might be right.

So, which do you think: One giant paroxysm of change and disruption, or a multi-stage approach to (what we hope to be) smaller disruptions? Companies will often like the logic of the latter, but I suspect there are problems with this approach -- problems that can mean lower productivity for a longer time than comes with the single-change approach. What do you think? I'd love to discuss it with you and see just what your appetite for change truly is.