The route to a painless migration

The move to Exchange 2007 is a strategic necessity for many firms, despite fears about data loss. However, there are tools and methods to help ease the transition

Microsoft Exchange Server 2007, the next version of the popular e-mail platform, is due to be released later this month, which means the clock is ticking for users who want to be the first to adopt it.

For many organisations the move to Exchange 2007 is a strategic and necessary one, a building block of their IT strategy for Microsoft's server operating system platform, and the future server operating system release known as Windows Longhorn.

Analysts have warned that the upgrade to Exchange 2007 will be a major release, compared to the relatively simple upgrade from Exchange Server 2000 to Exchange Server 2003.

In a recent survey, 66% of IT managers said data loss or corruption was their greatest fear when migrating data. The study from Vanson Bourne, commissioned by technology integration and services company Morse, found that more than 50% of IT managers were concerned about network downtime during the migration, a factor that could prevent them from taking on a data migration project.

Consequently, users should brace themselves for change and migrations that could cause them some pain.

"While Microsoft expects that the transition from Exchange 2003 to [Exchange 2007] will be more like the relatively painless transition from Exchange 2000 to 2003, than the costly and time-consuming migration from Exchange 5.5 to 2000, this assertion is unproven and must be verified in customer environments," said Erica Driver, principal analyst at Forrester Research.

"Until Microsoft can validate this claim, start planning for an extensive, costly and time-consuming upgrade. Expecting the worst and being pleasantly surprised beats assuming the best and then scrambling," she said.

For organisations moving from Exchange 2000 and 2003, many tools are available to help them migrate their data to the new Exchange platform.

These are far better than relying on back-up tapes where there is a risk of data loss and corruption.

Maurene Caplan Grey, principal analyst at Grey Consulting, said, "Except for small and medium-sized business, nearly all Exchange shops [used] third-party tools to move from Exchange 5.5 to Exchange 2003." For instance, Quest Software's Exchange Migration Wizard is regarded as a "pretty complete" package to do this, Caplan Grey said.

An application like Exchange Migration Wizard can carry out mailbox migration "behind the scenes" said Caplan Grey, so that the existing and new mailboxes can coexist during the transition and migration period. This means that mailbox data is gradually moved to the new environment, she said.

One of the features of the Wizard software is remote users collection, which helps organisations upgrade their remote or laptop users by using Exchange's local offline folders file. Quest said the application will be compatible with Exchange 2007 30 days after its release.

Other migration tools are available from Bindview (now owned by Symantec), Aelita (which was acquired by Quest) and NetIQ (which was recently acquired by Attachmate).

Bindview Microsoft Exchange uses a mix of software and professional services that range from migration assessments to Microsoft Exchange deployment. The product offers a rollback capability, so that migrations can be restored if necessary.

Like the other tools, users can also programme Bindview to schedule migrations during off-peak hours, to cause the least disruption to the business.

Caplan Grey warned that Exchange migrations can have "hidden complexities from an operational standpoint" because the server has so many dependent servers and applications linked to it.

For example, Exchange Server 2007 must now be hosted on a hybrid 32/64-bit server. This may bring some surprises, as other applications and platforms may not be natively compatible with the new messaging platform.

Another potential area of incompatibility is Exchange 2007's unified messaging component, where the message transfer agents are different from previous releases. "The routing architecture changes from Exchange 5.5 to Exchange 2000, then again to Exchange 2007," said Caplan Grey. "There are just so many changes."

Analysts recommend a phased approach to migration, rather than a big bang. This should also be the case for globally dispersed organisations, even if they have made a move towards a centralised datacentre environment and have consolidated their dispersed mail servers.

The reason for choosing a phased approach is that if something goes wrong, the organisation will not have to roll back 20,000 mail boxes in one go, for example.

Exchange migrations regularly go wrong, Caplan Grey warned. Data can become corrupted, IT staff could make mistakes, or the bandwidth may not be suitable for the additional migration requirements. There may also be underlying architecture issues causing crashes during migration.

In these instances, e-mail is likely to get lost, even in rolling back the migration, because e-mail boxes are dynamic, rather than static.

Caplan Grey said, "There was one client where the migration was so awful that they literally ripped and replaced and got another team in. It depends where you are and where you have got to in the migration."

She recommended that users retain their test environment so they have a recovery environment which mirrors the operational environment if it should get corrupted or fail during the migration. Ideally, the test environment should run on a different set of servers.

It generally takes a global organisation with 5,000 people between 12 and 18 months to carry out an Exchange migration, factoring in business issues, such as sales and financial cycles, said Caplan Grey. "It sounds like a long time, and it is a very long time," she said.

Arguably, the biggest mistake companies make is that they do not build a proper business case for the migration. Other problems arise when users do not comprehensively design their end system, or systematically plan the migration.

"Buy-in, design and planning are the three key aspects to a successful migration," said Stuart McMinn, a consultant at Morse.

Once the business case has been made, organisations should consider issues such as disaster recovery and how they are going to divide up their Exchange environment, said McMinn.

A common set-up McMinn had encountered was when companies put all their directors and sales people on the highest performing server, and segmented the Exchange environment so that each department is on a different server or storage group.

However, he warned that such a set-up might cause problems - for example, if the server crashes with all the directors on it. "It would be better to break up the environment in a different way, so that if one exchange server goes down, a whole department does not go down," he said.

McMinn advised organisations to look at the Exchange migration as an opportunity to address the problems they currently face with e-mail. "An organisation I know of had to search for one e-mail for a court case they were facing.

"The problem was the e-mail could have been sent by any one of 2,500 users that were spread across numerous Exchange servers, at any point in the past six months. It ended up costing the organisation more to find the e-mail than the cost of legal proceedings against them," said McMinn.

This is a case where organising the Exchange directories intelligently and using a coherent data archiving system would have helped, he added.

Overall, in terms of best practices for Exchange migrations, organisations should ensure they have comprehensive plans and timelines in place for the migration, so that users are not negatively impacted.

Second, it is essential to have the ability to roll back the migration if things go wrong. Using migration tools from the likes of Quest can help with the process, and these enable users to quickly roll back if needed, without having to rebuild the system and restore data.

The majority of organisations using Exchange are currently running Exchange Server 2000 or 2003. For the handful of users still running Exchange 5.5, migrating to Exchange 2007 will not be directly possible.

Instead, Exchange 5.5 users have been advised to move first to Exchange 2000 or 2003, since tools are available to help them migrate to these platforms. From here, they can then use migration tools to upgrade to Exchange 2007.

Comment on this article: [email protected]

Read more on IT for small and medium-sized enterprises (SME)