Calendar Migrations: The 80/18/2 rule

Enterprise migrations are as much a social engineering issue as a data conversion issue.

Keep in mind, we're talking organizations here as opposed to single-users, and we're focused on server-to-server solutions as opposed to client-to client solutions.

Let's get into that social engineering by way of the perceived utility among your user base, shall we?

If you're acquainted with the 80/20 rule, we're going to give you, based on our experience of doing this kind of stuff since 2001, our own 80/18/2 rule when it comes to migrating into Exchange or Office 365.

To wit:

• 80% of what you need to migrate is email.
• 18% is calendars (full-state or flat, doesn't matter), contacts, tasks 
• 2% is user preferences, settings, delegates 

Getting 80% done should cost you NOTHING

Email is manageable with imapsync and your cost is  €100 EUR for product and support no matter your enterprise size.  Why on earth would you pay anybody for email migration when this is available (unless you have a backroom deal with a consultant)?  We've even done a couple of guides one of which you can download here.

We've done several posts on how to use imapsync to migrate into Exchange / Office 365.

If all you (need to) care about is email you're done here.

Your likely result in this 80%:  
Your end-user efforts: Minimal
Your Admin efforts: Moderate to high
Your End User Satisfaction: Moderate (if you stop here)

Your next 18%

Contacts and tasks are not other-user-connected information and (worst case) you can move them via CSV/TXT file methods.

Calendars are a more complex discussion.  In fact this entire blog is dedicated to migrating calendars and keeping as much of the useful connections between users intact.

Anybody who's promising you "no data loss" in a migration and takes calendars without re-creating the guest list has been dealing in alternate facts.

If you do not care about attendees, attendee responses, and resource bookings, there are a variety of solutions.  If your enterprise wants "no data loss" when it moves to a new collaboration platform, i.e.,  to keep its meetings as meetings, please search this blog for the legacy system and read the appropriate articles.

We do charge for that capability.

Your likely result in this 18% with Sumatra methods: 
Your end-user efforts: Minimal
Your Admin efforts: Moderate to high (depends on experience level)
Your end-user satisfaction: HIGH

Your likely result in this 18% without Sumatra methods:  
Your end-user efforts: HIGH (Need to re-create meetings, resource bookings)
Your Admin efforts: Low.  (We have seen sites choose based on Admin efforts -- their call)
Your end-user satisfaction: Low to moderate

The final 2% (the last mile to the finish line)

Let's talk about that last part since it's portrayed out of proportion to its time value: 

• User preferences, 
• Delegates
• Junk Mail filtering rules
• Client-side Outlook re-configuration

User Preferences
Many of these are scriptable.
One of us has in fact has been itching to write about how to script user preference migration so keep an eye on this blog.
The important things to keep in mind here are:

1. From almost any legacy system there is going to be a disconnect between user preferences offered and Exchange / Office 365.
2. Even if there is not a disconnect in a specific functionality, the question is can you get at the legacy data via server-side utilities?
3. Setting user preferences is a great opportunity (a "teachable moment") to enforce encourage your users getting training and actually taking steps in Exchange before or after a migration.

Delegates
You would LIKE to think Delegates are a simple matter.

This is exactly incorrect.

First off, because the model for delegates is usually very different between your legacy system and Microsoft Exchange.  Example: In Oracle Calendars delegate access (called Designate access in OCS) is OBJECT-BASED and in Exchange it's FOLDER-BASED.  

Second because over time the number of delegates in legacy systems has usually out-grown the organization's needs and some re-thinking is most definitely in order.  During a migration is the perfect time to reset those access permissions. Or, worst case, you migrate all legacy delegates (and we mean it’s the worst case.) 

Third because after you set those delegate permissions in Exchange you discover that users can edit conference room bookings, and can see other’s calendar information. What’s the worst case: there is no good way to reverse the permissions.  Exchange has some native peculiarities that you're not going to really understand until you're in the thick of actually production deploying it and then it's either too late to change or a pain in the neck to re-do.  See: Two ways to grant access to a Resource in #MSFTExchange.

While it is possible to devise very clever technical solutions (and we have!) experience in this shows that (in stark contrast to a full-state calendar migration) it always leaves a subset of users grumbling that it did not do what they wanted.  

And grumbling is the enemy of a successful enterprise migration.  We prefer a few whining grumbling users to the entire organization ready to “run you out of town.”

Our conclusions from doing these: The effort is better spent as a training opportunity to get users active in setting up their delegates post-migration. 

Junk Mail / filtering Rules

This is potentially a real pain.  Thunderbird HAD a tool for email filtering migration but it's atrophied.

While Microsoft makes it possible to export rules from Outlook and import them to other Outlook clients, in general the methods for taking rules from legacy systems and migrating them simply to Outlook are lacking. And we've never seen it done server-side.


Best strategy we've seen for those who need to deal with it is to identify the high need individuals and get them or their admins training to help re-create essential rule sets. 

Client-side Outlook re-configuration
If users were using Outlook as a client in your legacy system you need to point them all to your Exchange domain now.

Not too difficult.  See Deploy Outlook mail profile settings via GPO or script

The process as described in that link is solid, but we have found problems with the VB script in it. If you are a Sumatra client please feel free to ask us for our VB script:  deployprf.vbs

Your likely result in this 2%:  Experience tells us user response is almost a complete crap-shoot if you try to automate it.  Best you can hope for is a low complaint level.  No one is ever really grateful for it.
Your end-user efforts: Low to Moderate
Your Admin efforts: Moderate to high
Your end-user satisfaction: it’s dependent upon end-user communication and expectation management