Performance Optimization in a Beehive to Exchange Calendar Migration

We've been fine-tuning the performance in the Beehive Calendar to Exchange calendar migration.

A little bit of background is due here.  We use the rate of 850 objects per minute as a rough gauge of Insertion time into Exchange in our Meeting Maker or OCS migrations.  But that is ONLY for insertion into Exchange from our own data structures and does not include the time for any processing of Legacy calendar data (the Extraction phase).

For Beehive, we've combined the EXTRACTION and INSERTION into one application where we read directly from Oracle's relational database.

And needless to say performance varies hugely with the Beehive topology and servers.

So a few general results:

• Your migration performance improves  20-30% if you SHUT DOWN Beehive (technically our results were 18% to 33%, in a variety of configurations, but rounding makes them easier to wield).
• Going into on-premises Exchange yields more reliable performance than insertion into Office 365.
• Extraction involves a certain amount of overhead that is difficult to remove and highly dependent on Beehive system and configuration.  Think of it this way: it always takes a certain amount of time to pull up a user.
• Given that, look at your summary report for you top users and use that data in conjunction with your test experience to gauge your insertion times.  If you need help analyzing this contact us.
• Calendars with more objects take longer to insert so only take data as far back as you need.  If we see serious requirements for lots of past data we'll modify the code to allow you to insert current data as quickly as possible (so you are functional) and then go back and insert your historical archive.  This has been a regular feature of our other migrations for a while now, but Beehive migrations are relatively new.