|
|
MIGRATION
E-Mail Platform Migrations: A Survival Guide
Get tips and tricks to avoid the many pitfalls and make your migration as smooth as possible.
A few years ago, it seemed every company was migrating its e-mail platform. Between the introduction of Internet-based messaging standards and the lack of Y2K support for many systems, almost every company was planning a major e-mail deployment or migration. It's true the great surge of migration work may have passed, but mail platform migrations haven't died out altogether. These days, they're more commonly associated with corporate mergers, because one of the first major IT initiatives to draw organizations closer is often to bring them online on a single, unified mail platform.
If you've ever found yourself in the hot seat for one of these often politically charged and unpopular projects, you can use the tips and tricks in this article to manage the experience and make your life easier.
Don't expect your project to be popular
Users don't like migration projects. In fact, they hate them. Migrations disrupt the daily routine, introduce technical uncertainty, demand training, and eat up company budgets -- all to provide a service you already have. Few systems impact your users more intimately than their e-mail, and if you're going to make your project a success, you have to bring your users on board. Doing so requires multi-level planning and consideration from the user perspective, and it starts with the first message you send. Help your users understand the positive impact of the migration. Focus on tangible elements, and make sure every member of your team can clearly articulate the value proposition using language your users can understand.
Examples of positive impact include:
- More reliable mail
- Reduced IT support requirements, letting you redirect funds to other initiatives
- Potential to reduce spam
- New Web access while users are on the road
Know your environment
Sure, you've been managing your current environment for years, so you must know it inside and out. Although this may be true of your server-based environment, don't think for a minute the clean, well-structured client environment you deployed so long ago has aged as well. Your client environment is probably a lot more heterogenius than you think. It's important you take full inventory of how your users are using their current messaging environment before you migrate.
Here are some questions to ask yourself about the client:
- Are all versions standard?
- Have your users discovered creative ways to access their e-mail from home?
- Do you have mobile or roaming users?
- Do you have users sharing the same workstation?
- Are any users synching with a PDA?
- Do users replicate locally?
- What other applications link to your e-mail system?
Consider executing a full site survey and question users from each department to understand your current environment better.
Zero downtime
There's no excuse for taking down mail services during a migration. Your migration procedure must take full account of these requirements, and you must be able to account for every mail message sent during this period. There are no excuses for lost mail, and the simplest way to ensure mail delivery is to provide mail account overlap. This involves setting up your new environment in every way except actually serving live users prior to starting your user migration.
A standard migration procedure that manages mail routing includes these steps:
- Start by installing and configuring your new messaging server(s) offline.
- Next, register all your user accounts and mailing groups, and create all your mailboxes. Record a forwarding address on each user profile that points to the current mail account.
- Bring the new server online in relay mode only. Ensure a routing gateway exists between it and your current mail environment.
- Redirect all inbound external mail to route through your new server. Coordinate your DNS changes properly so your old server remains a candidate to receive inbound mail as a failover option during the time it takes the update to replicate everywhere.
- After a user receives his new mail client training, simply remove the forwarding address on the new server and set a forwarding address on the old server to point to the new mailbox.
Here are some things to consider when manipulating your mail routing tables:
-
- If you have a distributed messaging environment, be sure to take into consideration the time it takes to replicate your changes.
- Just to be safe, plan any Internet domain changes for non-peak times, such as 12 a.m. Saturday night.
- Consider if, when, and how you're going to convert data and make it available in the new environment.
Minimize mixed environments
Although you might have a good strategy to move your users from one mail server to the other, don't neglect the impact of maintaining a mixed environment. There'll be issues to support (e.g., meeting invitations are notoriously full of bugs in a mixed environment). You'll have to dedicate more support personnel than usual during your migration period. It's to your advantage to keep the mixed environment duration to a strict minimum. The longer you maintain a mixed environment, the worse the migration experience will be for you and your users.
Tip: If you're looking for some inspiration, consider that with careful planning and a pre-training strategy, you can migrate upwards of 450 people over a weekend using a five-person team.
Maintain the integrity of your new environment
If you're forced to maintain a mixed environment over an extended period, always favor your new platform. If you have to make sacrifices to maintain basic services, make them in your old environment. By maintaining the integrity of your new environment, you'll increase user satisfaction with the new platform and motivate your other users for their own migration.
Data migration: Don't just write a blank check
Data conversion is a budget hog. A nasty data conversion project can make you lose all your hair and shave a year off your life. It can also turn your project and users against you. Here are some issues to identify.
Data location
Most messaging platforms store different content types in different locations. Although active e-mail may be on the messaging server, archived data often resides on a file server, and contact information more often than not is on the local workstation. This adds complexity to your migration because you now have to access multiple physical locations, which would probably require a minimum of two or three different user passwords.
Physical state of data
Expect to come across all sorts of non-compliance issues as you encounter old or damaged data. This can include corrupted files, data that may already have passed through one or more mail format conversion processes and lacks the integrity to make it through another, encrypted data where keys have expired or where IDs have since been recertified, etc. Any of these issues can skew your conversion process and will likely require expensive and potentially extensive manual intervention to address.
Data conversion is never 100 percent
Despite all the tools and processes available, all sorts of things get lost, misinterpreted, or skewed when you migrate data from one platform to the other, even in the absence of any major non-compliance issue. Many of the following things can irk your users: folders not recreated, unread marks that are wiped out, converted messages with a different look than native ones (really!).
Supporting converted data
Converted data introduces whole new sets of support issues in its new environment as users run into bugs and issues trying to manipulate converted calendar content (notorious for causing problems when migrated), responding to converted messages that still refer to the old system's naming convention, or sending messages to personal mailing groups where all the user addresses have changed.
Impact on your migration schedule
There are two major migration activities that control your migration schedule: training and data conversion. Whether or not you can short-circuit your training schedule (i.e., deliver large-scale seminars or e-learning solutions), there are physical limits to how much data you can move through the grinder. The longer your migration takes, the longer you have to support a mixed environment.
Here are some ways to get around some data conversion issues:
- Ask yourself why you're converting all this data. Look beyond the technology available to convert your data and ask yourself if it's worth the cost and effort. Think ROI and business value. You may decide not to migrate.
- Consider alternate viewing options for data. You can just leave it in its current form with the old mail client in place to be used for reference only (deactivate old mail router).
- Sensitize your users to the cost of migrating data, which can easily reach upwards of US$300 to $500 per user after you factor in manual intervention and support post-migration issues.
- If you still get stuck having to convert data, know that e-mail and outside contact information fairs best. Converted calendar data is notorious for introducing issues in its new environment, as are personal mailing lists that still refer to internal users by their old address. Also remember the great majority of calendar data isn't worth the fuss. A typical user only plans 20-30 activities ahead. What is the point of migrating five years' worth of old appointments? A better alternative to migrating calendar data is to have the user re-enter it manually in the new environment. That way, you're sure of its integrity, users get immediate hands-on use to reinforce their training, and you save time and effort by not converting erroneous data.
- Keep converted data separate. Put converted data in a separate archive from the current production mailbox. This can be a separate file that never touches the new server environment, but rather, is stored on a mail file somewhere. This helps to keep your live environment free of complications.
- Creative options -- such as delivering converted data in the days or weeks after a user is migrated -- may also help increase your migration rate, thus minimizing your mixed environment period.
- Set user expectations. Tell them converted data is ugly and won't work well in their new environment. Let them know you hate doing it. They will be more appreciative and supportive of the results.
Training: Damned if you do and damned if you don't
Not all your users will appreciate being pulled from their desks to sit through a formal classroom training session. On the other hand, you know your support calls will be off the charts if you don't help them master the minimum skills required on the new platform. If your organization is like most, you probably have a mixed user group of varying skills. Traditional training strategies that aim for the lowest common denominator won't do. The solution is to make sure your training options appeal to all your users. Use "à la carte" training options that address the different needs of your employees.
A basic strategy could include:
- Full-format, hands-on classroom training for your less computer-savvy employees
- A high-level "what's new" seminar you can deliver to a large audience, perhaps even over the lunch hour
- One-on-one personalized training for your more critical, high-performer employees, given at their own desk using their own mail files
You can use a dragnet to get all the others. Require users who fail to complete one of the training sessions to pass a test that stresses the most common support issues on the new environment before getting access to their new account.
Offer intense short-term support
The days immediately following your users' migration will be the most support-intensive. Provide high-impact support services by having additional support personnel on the floor working directly with your users at their desks in the days immediately following the migration. Have them work in tandem with your usual Help Desk services, linking them with pagers.
The proof is in the pudding
A typical mail migration will ring in at between US$50 and $700 per user when you factor in hardware and data conversion requirements. Where exactly your organization fits into this range depends on the repeatability of your migration procedure and how ruthless you're willing to be about data conversion. All things being equal, the better scripted your migration, the better. Make sure you can stick to your schedule and strategy by setting your policies on how and when you'll handle exceptions and individual user issues ahead of time.
Careful planning
Standardization in messaging and network protocols has made mail migrations easier overall; however, there are still many pitfalls. A carefully planned and well-managed migration plan is the secret to success for this type of project.
Louise Davey is a 12-year veteran of the IT professional services industry. As chief operating officer of Imagina Technology Solutions, she's responsible defining and delivering the organization's solution offerings. Her areas of expertise include business process reengineering, collaborative solutions, messaging, wireless computing, and portals. Imagina maintains a dedicated portal business practice and is a leading service provider in the Canadian marketplace. http://www.imagina.ca
ARTICLE INFO
 FREE ACCESS
Keyword Tags: business strategy, collaboration, compliance, E-Mail, ibm, ibm lotus, it networking, messaging, mobile business, Messaging, training
|
|