In-Depth

Best Practices for IT Migration Projects

Eight best practices to keep the user experience front and center during IT migration projects.

• By Scott Rodgers
• June 20, 2006

Migration can turn the adage “think globally, act locally” on its head. That’s because the experience of users can make or break the success of a project if they don’t adopt or adapt to new technology.

After all, it’s the little things that count – using e-mail to book an appointment, or using a local application to generate a request with your building’s facilities manager. When an executive assistant can’t get to the boss’s calendar while he’s traveling on business, the IT support desk will hear about it.

From my experience helping to move thousands of users from one system to another, making user experience the primary focus throughout planning, staging and execution leads to much greater success in migration projects. Here are eight best practices that keep user experience front-and-center.

1. Consider interdependencies and plan to minimize disruption and maximize utility.

Whether it’s e-mail, a collaboration environment or an ERP application, chances are the system or application to be migrated also interacts with other systems and applications. Interdependencies are often overlooked or ignored for workflow or e-mail-dependent types of applications such as help desk systems that use e-mail for escalation, or ERP systems that use e-mail for workflow-type approval routing. Understand those interdependencies and make an inventory, so that you can account for them in your migration plans and execution. Otherwise, you may put your carefully constructed IT architecture at risk.

2. Don’t assume migration should replicate the present environment.

It’s common to assume that the old environment should be replicated on the new platform. That can be costly and, ultimately, unnecessary.

It’s helpful to conduct several rounds of reviews. For example, an application migration could start with a review of the application inventory to determine which ones “should” be migrated. In many companies, we’ve found up to 60 percent of legacy applications haven’t been used in the last 90 days. The rest are candidates for migration.

In the next round, identify which applications’ functionality is required in the new environment. Some functions may be addressed by other systems now or in the future, such as financial reporting that’s now duplicated by an ERP system. That narrows down the list of migration candidates even more.

In the final review, identify which applications are candidates for automated migration using tools or templates. For example, you can develop front-end interfaces using .NET or Microsoft Access as tools that connect to back-end Lotus Notes databases; later, you can change the back-end system. Tools for migration are available that can help move base discussion databases or document libraries directly to, say, Microsoft SharePoint Server, with little custom development.

3. Consider migration a multi-stage project.

A linear approach to migration can be short-sighted and costly when there are alternatives. For some clients, it’s been more practical to create a Web-based interface to legacy applications, giving end-users the experience of using the new platform, while the IT team worked on the complex back-end migration. Other clients have developed “sunset” strategies for retiring applications—typically those that are mission-critical right now but that will be replaced by another system.

Some clients also lock down development on the old platform. While lock-down can save licensing and development costs, it’s important to create a roadmap to the new platform and train developers—and avoid backlash in response to the shock of a brand-new development environment.

4. Account for major changes that coincide with migration.

Don’t make it harder for end-users to adjust to new technology—consider other changes, from office moves to system upgrades, which may coincide. It might seem convenient to consolidate change and the pain associated with it, but doing so could compound demand on support resources.

Change can present opportunities. For example, as long as it’s not hugely disruptive, adding systems or tools—say, for measurement or tracking—can set the stage for more intelligent operations.

5. Plan ahead for cut-over so that system architecture doesn’t lock you into one migration path.

Plan to get the right people engaged in the pilot phase well in advance. By including select senior executives such as the CIO, and business and technical project sponsors, the project team can identify issues and concerns before it’s too late to modify system architecture or migration path.

Advance planning also needs to factor in ancillary devices. Prepare a migration path for all types of access to help minimize support issues during migration. I’ve seen plenty of senior executives doubly frustrated by lack of BlackBerry access and their own inability to reset the device in order to gain access.

6. Communicate early and often.

Frequent communication is the non-technical support that helps ensure there is buy-in for migration from the top down. From staff meetings to Web portals and e-mail, communication helps smooth the way for everything from timing to post-implementation support. FAQ documents, computer-based training, brown-bag sessions and other communiqués aren’t expensive, and can help cut down calls to the help desk during migration.

Good communication also entails confirmation from the legal department regarding regulatory requirements that should inform new system usage policies, such as rules for e-mail retention.

7. Stage migration to balance efficiency with user satisfaction.

A user-sensitive approach helps balance demand for support. Factor into the migration timeline your users’ access requirements, user roles and the nature of the processes affected by migration.

For example, staff that never requires offline access may be best-served by Web-based e-mail. It takes a bit more work to plan for major categories of access required. But in the long run, it can result in better use of resources, from network bandwidth to help desk support.

Consideration for user roles also can help the project team plan a more seamless transition and design effective training. Take the assistant who may support multiple executives. Moving a few executives at a time will require access to old and new systems that can be frustrating for the assistant as well as the executives.

Finally, planning a good pilot phase is worth the effort. It’s often advantageous to conduct an alpha pilot to test the technology and a beta pilot to test process and communications. With the technical kinks worked out, the beta test reveals what needs to be communicated and how and when that needs to happen.

8. Choose the right tools.

If the project looks too good to be true, it’s almost certain the problems will show up during implementation. Tools for high-quality analysis will reveal flaws early, as well as opportunities to integrate security and existing technology investments.

Our clients find that tools for automation offer significant advantage. Automation can accelerate some of the work—cutting weeks-long effort down to a few days. In addition to reducing risk of human error, automation reduces the time in which old and new platforms coexist. The longer both systems are in place, the greater the chance for problems— lost meeting requests and disappearing files—that lead to poor user experience of the new system.

Last but not least, the lab environment must replicate the production environment. Most likely, the old platform or system has been modified over time and doesn’t resemble an out-of-the-box deployment today. Unless the lab environment reflects the system in use, planning and testing will have limited value.

Think Locally, Act Globally

Technically, your IT team could migrate all users at the same time. The fact is that the pain it would cause—from user confusion to demands on support, network bandwidth and more—makes it necessary to prioritize the non-technical aspects of migration. We find thinking “locally”—that is, about users—and acting “globally” is a great formula for success.