The funny thing about server migrations is that no vendor ever claims to lose customers from its platforms, yet at the same time, each steadily gains business from all of its rivals.
The fact remains, however, that migrations come in just about every size, shape, and variety: Windows to Linux, mainframe to Unix, NetWare to Windows, as well as upgrades within a specific vendor line HP e3000 to Integrity, Windows NT to Windows 2003, VAX to Alpha, and so on. The primary reasons for such moves generally boil down to upgrades or standardization on a more open platform, as well as consolidation onto fewer, more-powerful machines.
"Most of the server migrations that we see are either upgrades to larger systems or rehosting to a new platform," said Chip Nickolett of Comprehensive Solutions, a systems integration company based in Brookfield, Wis. that has overseen scores of migrations. "The biggest overall trends are standardization of platforms and consolidation of smaller older systems to larger newer systems."
"Unless there is a solid understanding of what supports the current environment, it will be extremely difficult to plan for a migration that is timely, within budget, and delivers what is expected" Chip Nickolett, Comprehensive Solutions
Although the various vendors can't achieve any kind of consensus as to who is migrating to what platform, they do agree on many of the key strategies and best practices enterprises should harness to ease the pain of an upgrade or server change out.
1. Plan carefully: Planning might not make perfect, but it does lead to far fewer imperfect migrations.
"Lack of planning is one of the downfalls of server migrations," said Loretta Li-Sevilla, director of worldwide customer programs for HP Enterprise Servers. "Each step must be well thought out in order to avoid business disruption."
Early in the planning phase, inventory all hardware, peripheral devices, and software assets. With that data in hand, it is easier to objectively consider what upgrades and replacements are necessary or desired. In addition, this puts the organization in a position to analyze the financial, technical, and business impacts of the intended migration.
"Unless there is a solid understanding of what supports the current environment, it will be extremely difficult to plan for a migration that is timely, within budget, and delivers what is expected," said Nickolett.
2. Benchmark:One vital ingredient of the planning process is benchmarking. We recommend gathering key performance and service-level metrics for use as a baseline goal. Determine how long a process takes on the current system so that when the new system is in acceptance testing you can ascertain if it's faster, slower, or the same as the new system. This also provides a quantifiable counterpoint when users or system managers later voice opinions about "how much better the old system was." With actual statistics in hand, you can either throw the numbers back at them or take fast action to remedy genuine performance issues.
Applications are typically a major constraint, as most enterprises want to retain their current functionality, look and feel, and minimize the cost/risk of major changes.
When Comprehensive Solutions conducts a migration it typically has a production lead identify a system's key functionality. It then sends someone to the shop floor with a stopwatch to gather metrics. We recommend doing this several times during work shifts to hit peak loads. After the migration, repeat the same process and generate a report to illustrate before and after pictures. This can go far in securing user and management buy-in.
3. Teamwork: No large migration is done by the systems manager alone. The networking, security, financial, management, and user constituencies must all be involved for accurate planning and effective execution. Also, more than one internal project team is usually necessary for a project to succeed.
"The migration team also has to encompass suppliers, consultants, and external application specialists," said HP's Li-Sevilla.
4. Focus on Applications: Application planning is such an important step that it merits its own section. Applications are typically a major constraint, as most enterprises want to retain their current functionality, look and feel, and minimize the cost/risk of major changes. No one wants to throw out 20 years of business logic just to have the "latest" system, as this would quickly turn the upgrade into a significant downgrade.
When a mission-critical business application is involved, or when moving from one database to another, great care must be taken. When homegrown applications are to be maintained, it may even be necessary to reverse-engineer the software, discover the business rules, map out what the application does, and then map it into its new environment. Planners, therefore, must understand the data formats, the cost of retaining old applications, and any functionality that will be lost by moving to a packaged application. They then must carefully weigh the pros and cons of all possible options.