Calendaring and Scheduling Server Migration Central.
The hallmark of Sumatra's software is that we work at the SERVER level rather than the client level. We know of no other server-based calendar migration solution. This allows us in one step to take as much information out of Meeting Maker as is possible and in a single second step insert as much into Exchange as it will take.
Over the years we've been asked for a variety of different migrations, with a variety of different requirements and have amassed expertise in a variety of techniques. This represents a distillation of what we've learned over the years.
Whether we do a particular migration or not, the following will outline the issues involved, the questions to ask, and the background of what makes it all such a Gordian knot.
Lots of companies have come up with solutions for moving your email from one server into Exchange (or elsewhere). There's a very convenient guide to the various email migration products here.
However, moving email while tedious is technically straightforward: text files, attachments, and directories need to pass comparatively few restrictions to go between very disparate systems. What separates them is speed and ease of use.
This is not the case with schedules and calendars. They derive most of their value from the very interconnectedness of the system in which they reside. One user's appointments or activities are easy to move, but dozens of meetings with exceptions, differing locations, and varying guest responses are an entirely different matter.
Most email migration software that handles calendars and scheduling only do so "with restrictions." Usually this means you lose the meeting guest list, or guest response information, or recurrence patterns, or all your proxy lists, or.... you get the picture.
The fundamental difference.
Fundamentally, once email is delivered it's completed its mission.
A meeting invitation though has just gotten started once it's in your inbox.
Taking the example of Exchange 2000/2003, it must be responded to for each user, with a variety of options (yes, I'll attend, no I won't, delegate this to someone else, or I can't look at this now).
This information needs to feed back to the Meeting Organizer, who will in turn make other decisions about it.
Canceling the meeting, for instance, should pull it OFF your schedule. Changing the location should leave it on your schedule, but inform you of the change.
So less like a directory of documents, you have to think of your schedule more like a web of information and its interconnections. Migrating this usually requires more work and forethought than the email migration.
Double the work.
Email migration typically requires getting an email to a new directory on the new system. As we've seen above, for calendaring and scheduling that's the BEGINNING. In Exchange, to bring in previous user states a migration application must effectively re-propose all of the meetings that have been proposed, and then respond to them in place of the users invited.
Needless to say, this adds a level of complexity to the problem that is an order of magnitude beyond the problem of moving Inboxes.
Questions to ask:
- Does this work at the server level or the client level?
- Does it take Meetings (with guest lists) as well as Appointments (just for individuals)?
- Does it take guest responses as well as meeting times?
- Does this handle Resources and Conference Rooms?
- How does it handle mapping user IDs between the two systems?
- Is the process viable? (the best test for this is what if the power goes out while the migration is going on? Can the migration software pick up from where it left off?
- Is it a migration solution (so that I can then cut off my support contract to the previous vendor) or an interactive gateway (which keeps both systems running?
Available solution type matrix
Since we do get many requests we put together this matrix of known migration solutions for other products.
|FROM, TO:->||Meeting Maker||Exchange||Notes||GroupWise||Oracle / CT|
|Meeting Maker||X||S||S, C||C||C|
|Oracle Calendar / CorporateTime||ND||C||ND||ND||X|
Legend: S = Server, C=Client, I=Interconnection, ND=No demand for migration
There are a variety of interconnectivity solutions with off-the-shelf software. This article gives the best summary of the pros, cons, and requirements of each for Exchange to Notes and GroupWise.
Some of the best links we've seen on products that handle migration in general are:
From Meeting Maker to:
|Exchange||Sumatra||Full recurrence, meetings, guest lists, resources, conference rooms|
|Notes||Sumatra and Prevare||Full recurrence, meetings, guest lists,
resources, conference rooms
Client side, no group capabilities.
|GroupWise||Lewis Studios||Client-side, no group capabilities.|
From Notes/Domino to:
Microsoft has recently (Feb 2006) made this much easier.
See also this very useful
We still don't hear about recurrence patterns and guest
responses coming over correctly.
Want to do this? Contact Sumatra.
|GroupWise||Lewis Studios||Client-side, works with Organizer, no group capabilities.|
From GroupWise to:
|Exchange||Sumatra Check out our version.|
|Notes||Sumatra and Prevare||Server side
From Exchange to:
|Notes||Domino Power||Excellent article on setting up interoperability between the two systems|
|GroupWise||GW Migrate||GW Migrate seems to be client-side based and have no group features.|
Oracle Calendar / CorporateTime:
Oracle has recently announced a direction towards interoperability with Exchange (see their January 2006 White Paper on the topic at Oracle.com). Sumatra can also migrate and emulate Oracle characteristics on Exchange.
While there are a variety of companies which offer solutions in the calendar and scheduling migration space, they cluster around either massive individual calendar import, or weak interactivity solutions.
When you're ready to make the switch contact us.
Copyright © 2000-2008 Sumatra Development LLC. All rights reserved.