In several articles for Outlook Exchange, we've covered the technical aspects of a Meeting Maker to Exchange migration. For some companies, the organizational and managerial aspects of the cut-over can be greater challenges than the technical aspects of moving a few hundred megabytes of schedule data. The aim of this paper is to give you the Top "Best Practices" we've seen as users move their legacy Meeting Maker calendar data to MS Exchange.

Remember, the actual data migration is only somewhere between 10%-25% of the total job -- this is a guide to making the remaining portion successful.

Your best bet for success is an early start. If you try to educate your users and migrate/convert the database in a weekend you're going to open yourself up for more problems than you ever want to deal with.

Step one is to set up a test lab that mirrors your production environment and convince yourself that you can move your data in. Don't believe anything but the evidence of your own eyes. The most successful migrations we've seen are the ones that have done the most testing and planning beforehand. Plan on using your test lab as a place where your key people can actually learn to use Outlook. The differences are significant, but our experience has been that several small sticking points are the most grating to users.

Your test lab serves two purposes: First, to ensure the conversion will work in your production environment; Second, to train your key users and to generate that all-important buzz (see below).

Grassroots support usually only works for folk singers and Ralph Nader. By and large the old maxim holds: if you want something done you go to the top. Aside from the fact that they're the people approving the budget the ability to say "The CEO or the CFO wants it done" has an amazing way of banishing nay-saying.

Start there with your plan. Having the evidence that the technology can work and the cost-justifying rationale (see below) for implementing Exchange are usually the two largest points you need.

If they've already come to you and said "get rid of Eudora and Meeting Maker and put in Exchange" you can consider this step checked off.

Usually the most vocal advocates of or impediments to scheduling systems are the admin assistants who run calendars for the top corporate officers. Get their buy-in early by training them beforehand. Bring them down to your test lab for demos of Exchange, learn where they get stuck, deal with their concerns.

How do you identify your top users? Usually from the database of users you're migrating you can extract the usage patterns. For an example of how Sumatra does it, click here.

Changing an email system or a calendaring system rates up with life's other major traumas. Everybody immediately gets stressed: over what happens to their data, over what happens to the way they've been doing things, over learning another software product, etc.

There is only one cure for this and it's to generate as much positive buzz as quickly as possible.

You do this by emphasizing a few things:

• The benefits of integrated email and scheduling in Outlook
• The lower cost of maintenance and upgrades for Exchange vs. proprietary products
• The integration with MS Office
• The fact that there's whole web sites of third party support and tools and an entire development community
• You’ve shown it to the movers and shakers in your company and have already gotten their buy-in

Involve your help desk in this step -- they field daily questions about Meeting Maker (or Eudora, GroupWise or Lotus Notes). They'll be able to reassure users with comments like "This will not be a problem when we upgrade to Exchange." Plus they’ll have a good sense of those users that have a difficult hardware configuration or an "alternative" new-product learning style. You’ll have more time to plan to deal with these one-off, time-consuming situations.

This is also a good time to issue an open invitation for users to see what their calendars look like in Outlook, as opposed to the limited number you brought in the previous step.. Experience shows that a small percentage will take you up on it -- but afterwards nobody can say you didn't give them the opportunity.

This is true when handing out documentation. One company we saw handed out a thirty-page info kit and tutorial to all their 1000+ users. Needless to say to read all of it was to become a zombie and nobody did.

Would you want to come into work on a Monday morning, and have to read a 30-page info kit before you could use your calendar?

The best thing to give out:

A single-page Quick Reference Guide.

A very good one is available at http://www.customguide.com/downloads.htm. Sumatra has no connection with this company.

The biggest sources of confusion post-migration are (usually) a few small things (and it really is only a few). Users were used to doing a few repetitive tasks in Meeting Maker (and I'm sure the same is true for Lotus Notes and Novell Groupwise) that they can't anymore.

We've identified three features in Meeting Maker that don’t exist in Outlook, and typically confuse users::

• Meeting maker automatically has a check box which appears when a meeting is confirmed by all participants.
• Meeting Maker has a quick ability to define a meeting time by holding down control key and dragging. This is not in Outlook.
• Meeting maker lets you press control and then click on their navigation icon to get to today. This is not in Outlook.

Tell your users about this early and you'll find there are fewer complaints.

If you're migrating Notes or Groupwise, the hot buttons are yours to determine.

Adjust the handout to address these key sticking points learned from step 5

7. Test, test, test

Let users look at their converted calendars (of a certain date) and their old calendars. Beware -- it's best to do this while all the data is fresh (a day or at most two old). It's hard for some people to conceptualize that their calendar has evolved since last week. It's impossible to put yourself in your shoes of a month ago.

Give your users fair warning as to how much data you plan to migrate, and how they can get their old data should they wish. Let’s assume you migrate the current meetings, and leave the 3 years of historical Meeting Maker meetings behind. What happens if someone wants those meetings? Offer two strategies:

• All your old data should be in an intermediate file, such as an access database or flat file. We typically use Access due to its ease of use. – You should store all the data from the legacy scheduling system in this readily-accessible format not only for your records, but to research ad-hoc user requests.
• Most other calendar systems will let users archive their data. This provides a good, user-based backup plan.

Relatively speaking, it's easy to transfer email since you've got a series of text files and attachments. Calendars, though, are tricky business because they have built-in a series of connections, responses, and state information.

The tendency is to divide and conquer: migrate email first and then worry about scheduling.

The problem here is that your users then either begin to use two different systems, or that they set up their email system on Exchange in ways that will cause problems as a schedule migration occurs.

See our documentation (here) for a fuller account of Exchange settings you want to turn off as your calendar migration proceeds.

Even in the best situations it pays to have a Plan B.

Have a back-out plan that you've tested, and for gosh sakes have it phased -- since we've seen restores from backup take longer than a complete insertion, there is an "Undo" capability built into our insertion code that removes all calendar data based it's inserted. This is a good, easy first step.

Only do the full restore in the event of server hardware or software catastrophe.

If you're in a rush, the best migrations we've seen are the ones that have started the earliest, gotten buy-in from the top, been thoroughly tested, and generated positive buzz. Make this your mantra and you're on your way to a successful migration.