Featured Post

How the Sumatra Double-Booking cmdlet works

First: you can always get help at the PowerShell prompt with: get-help Get-suDoubleBookedMeetings Let's say that we have the followin...

Thursday, April 09, 2009

True Inquiry Stories Part 1 "We want it all, but one user at a time"

Recently we got a set of requirements from a government agency that read like this:

We're looking to migrate our existing Meeting Maker 8.5.3 user, resource
account and conference room calendars to an existing Exchange 2007 server. Here
are the requirements from our customers:

1. Preserving as much of the meetings, activities, tasks, category information and contacts as possible....

2. If possible, we'd like to be able to import the Meeting Maker information on a per-account basis.

3. For the most part, our Meeting Maker server is actively used by only about 40 users at this point. However, because of a requirement from our customers, we have not deleted many older accounts from Meeting Maker to help maintain a historical record of meetings and activities. ....

The main problem with this is that 2. and 3. contradict 1.

Those of you who have been through the process or even the evaluation have heard us talk about the "spider web" that calendaring represents: Moving email is relatively easy since the data is static. But migrating calendar data while preserving guest lists and responses is harder -- you are literally picking up a spider web and moving it from one proprietary environment to another.

So moving one user at a time destroys the links between other users. Move all your users at once and you can preserve the links and associated information.

The corollary to this is also no surprise, keeping users on your original server for historical purposes works fine -- but you'll need to decide what to do when the time comes to migrate them. Not taking old users to Exchange is the same as removing them from your original system: their data disappears. Think of it this way: if a user does not exist - how does Exchange react when you put them on a live guest list?

Since we have gone through an intermediate database in our migration technology (a very wise design if I do say so myself) we do have options to reformat data on its way into the eventual target system, but this does require time and expertise. There really is no such thing as a free lunch.

After their initial inquiry they went out and tried to write their own tools (our recession-era tax dollars at work).

I leave the results to your imagination.

Keep an eye on this blog: we're working on a guide for evaluating calendar migration solutions. You don't have to go with us, but whatever solution you choose you should choose with open eyes.

No comments: