Migrating Mail from IBM Notes and Verse to Microsoft Outlook on Office 365 - Part 1
It was always just a matter of time. Eventually we were going to have to make the jump from IBM to Microsoft. It's not that IBMs software isn't good. It's very good. It's simply that IBM is the Beta to Microsoft's VHS. Technically the IBM product line is far superior but on the surface, IBMs poor UI will never match the incredible pull of Microsoft's polished Office 365 offerings.
We're just finishing a mail migration from IBM Notes/Verse to Microsoft Outlook, which we did entirely in-house and I thought it would be worthwhile going over the method we used.
The Before StatusPrior to the migration, all of our users had the IBM Notes client on their desktops. We had three production servers and two test/dev servers. All of our user mailboxes were on the IBM Cloud and we had a split with some users on Verse and some on Notes.
We were also running an extensive extranet with a myriad of centrally controlled expansive security options. Our address books contain in excess of 22,000 groups.
LicensingSince we'd decided to use Office 365 for word, excel and powerpoint, the migration was technically already underway with the purchase of Office 365 licensing. It should have been a simple matter of extending the licensing but as we already had a number of 365 licenses, we had to establish the right options.
This meant finding a Microsoft business partner and buying new licenses since there was no upgrade path from Office 365 Pro Plus, which doesn't include outlook to 365 E3 which does.
We later decided that E5 would have been a better choice but funding wasn't available until later and again, there was no easy upgrade option. That's an upgrade we’ll probably do on the one year anniversary instead.
Active DirectoryOur original plans were to migrate to Microsoft’s fully cloud based active directory service and retire our three AD servers. We might still do this but in the meantime, a decision was made to retain our on-prem AD.
This change had a significant impact as connecting the AD to Azure resulted in duplicate users which took some time to resolve. The solution ended up being to delete all our existing AD users and let them get recreated by the sync process.
Unfortunately deleting them required powershell, a tool we ended up getting a bit too familiar with. It also meant that their OneDrive data and yammer posts and profiles got trashed.
SPFThe next step was to get our users familiar with outlook. To do that, we needed to set up routing.
In setting up our office 365 environment, we had to claim our domain. You do this in the Office 365 admin portal which is surprisingly full featured.You have to verify your DNS via txt record and you're encouraged to put in a mx record that includes a spf flag.
We hadn't been using SPF prior to this but as soon as the SPF record took hold, it didn't matter that we had dual routing (with mail primarily going to our IBM accounts and a secondary MX record pointing to Office 365).
Our old connection immediately became “untrusted” and we had to quickly modify the SPF record to include our existing servers.
Stay tuned... in part 2, I'll cover how we managed routing, mailbox migration, and groups.