Calendaring is fundamentally different from email even though it usually uses it as a transport protocol.
Historically all migration solutions have focused on email. Not surprising since email is a mission-critical concern.
But where email is static once you have sent or received it, calendars have a crucial difference: they contain evolving meetings that are linked to the calendars of other individuals in the enterprise. In Exchange changing a meeting updates the calendars of attending resources and individuals.
And in a real migration you need to take these links and the data associated with them along or you’re only doing part of the job.
Nobody except Sumatra Development does this for calendaring.
Solutions other than Sumatra's treat calendars exactly like email: they create the events but do NOT recreate live meetings because they ignore the guest lists, responses, recurrence patterns and resource bookings.
Think if it like this: they take a print-out of a calendar and migrate that. We call this a “flat” migration. Most do not even take recurrence patterns.
Sumatra re-creates the state, creating live meetings with guest lists (which you might have to map to new domains or addresses), responses, recurrence patterns, exceptions, and resource bookings.
We call this “full-state.”
Even in the on-premises Exchange to Office 365 world, Microsoft focuses on email and does not even offer a calendar migration path. So we went out and blazed our own full-state migration method.
For small sites this is a tractable (if unpleasant) problem. It's still a productivity loss, but we’re talking a couple of hundred users.
For sites of 500 or more users the productivity hit can be immense.
Put another way: after a full-state Sumatra migration the user and resource calendar data experience a seamless transition: as though the enterprise had been using their new calendaring system all along. With other solutions users actually need to find and recreate their meetings to make them live and update-able.
Finally, other solutions willfully ignore the possibility of failure.
We have an UNDO strategy to gracefully remove only the data we put in in in the event of catastrophe. (We have seen servers fail in the middle of migration).
This is of course an overview from jet plane altitude and by the time we get through the first test phase with a client we’ve brought them to tree-top level.
Our web site: http://www.sumatra.com
It shows how our migrations work, and it also highlights some of the things
we’ve done in calendaring.
In a nutshell: if it involved MS Exchange calendaring / scheduling we can do it.
