And we then inserted the same database into our Exchange environment. That took 12 minutes (not surprising, we have good hardware and not an enterprise-level load)
Then we inserted the same data into Outlook Live @ Edu. It took 71 minutes.
Just to be sure we were not doing something really wrong we ran it twice and got the same manatee-like languid pace. We're used to measuring migrations with a clock, not a calendar.
We're sure we're not processor bound on our client system. The question is whether we're processor-bound on the server (likely) or network-bound (not as likely). The results are in any event troubling for anyone wanting to do a bulk calendar migration.
But wait -- there's even MORE BAD NEWS FOR calendar migrations!
According to Message, Mailbox, and Recipient Limits (tip 'o the hat to Duncan in London), there are limits of 30 messages per minute and 500 recipients per day. And the logs from London's test runs indicate they are already hitting this limit.
Taking calendar data over in a full-state method we re-create all of these and it is not unusual for the even moderately-scheduled user to hit these limits.
Stay tuned. We're working on creative solutions.
There is a ray of hope, though. This thread indicates others are running into the same absurd limits and Microsoft MAY be willing to make exceptions (check out the procedure at the end).
We suggest you folks who want to do a full-state calendar migration contact your Microsoft Rep and ask them if they can get these limits removed for the duration of your migration.