Inserting into Live @ Edu vs. inserting into on premises hardware

We were working with a client doing a migration into Live @ Edu and wanted to get some absolute data on calendar migration performance on their machines versus everyone else. So in true Sumatra fashion we created a test database of 20 users and had them insert it in their test environment. It took 19 minutes.

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.