Notes Migraine is Complete!

One of my projects this month has been a Lotus Notes migraine (okay, maybe that should have said Lotus Notes Migration). I have helped move a 700 user organization from Notes to Exchange 2003 and Outlook 2003. On the whole, the user community is happy and they certainly like the web client and mobile options a lot better.

To migrate the calendar, contacts (Notes personal address books), and e-mail information, we used the Quest Migrator for Lotus Notes (formerly Wingra Notes Migrator). On the whole, I'm very happy with the results we got from Migrator; it did save us a lot of time and there are some good tricks you can use to tune it. We looked at using the latest Exchange tools, but were not happy with how the Calendar came across (as an SC2 file that the user had to manually migrate) and the personal address books did not come across at all. By the way, Quest has some of the best tech support in the industry. No hassles, no long queues or next-day call back times. I don't know if they are this way for all their products, but for Migrator for Lotus Notes, they were excellent.

We used the Lotus Notes Connector that comes with Exchange 2003 to do an initial directory sync. It creates mail-enabled contacts in the Active Directory; it does not match up attributes with existing users. I was not amused. However, Quest's Active Directory Object Merge Tool takes the mail-enabled contacts that were created by the Exchange connector's directory sync features and merges those with the corresponding user accounts. Of course, you have to create a mapping file (Users-to-Merge.TSV). I used the samaccountname as the search key and that worked fine.

For this customer, the user's personal address books (the names.nsf databases) were in each user's home directory. We relied on Migrator to scan the file system and match up the owner with the Tools->Preferences information or the names.nsf ACL information. It was not entirely accurate due to so many people being listed as Managers on those files. I strongly urge anyone in a similar situation to go ahead and include the direct path to each user's names.nsf file in the "Users-to-Migrate.TSV" file that you will build to do your migration.

I recommend also doing a FixUp and Compaction on each of the mail databases in order to reduce the possibility of mail database corruption. We had a lot of that.

We also had problems with encrypted messages. A lot of users would encrypt messages and not even realize it. Naturally, Notes does not know how to decrypt a user's encrypted messages. The IT staff here did not realize this until we had already started migration. Run a trial migration and see if this is the case. If so, see the IBM document "Removing encryption from all documents in a mail file" for more information on doing a "bulk decryption". Also, see "How to remove encryption from mail documents when converting licenses from North American to International" for additional information.

One of the challenges to this project was "scope creep". The scope changed frequently. This was partially because we were trying to figure out which applications (shared address books, shared calendars, discussion databases, etc...) needed to be moved in to Exchange and which needed to be moved to Sharepoint. We used a tool called the Proposion Portal Migrator to accomplish this. The tool did what it claimed to do and was pretty darned spiffy! We did not have all that many applications to migrate to Sharepoint, but the tool was still very valuable.

Another reason for "scope creep" was that most of the IT staff had never used Outlook and Exchange before. We had a 2-week pilot and that really was not long enough for the IT staff to get acquainted with Outlook 2003 and Exchange. In hindsight, the pilot should have been 6 - 8 weeks to give internal IT more time to figure out what the users need to be trained on and what they needed to know.

We decided early on in the process that only VIPs would get "all" of their mail. Everyone else would get only the last 4 months of mail and everything else would be available in a PST file for them. This was NOT a popular decision. Some departments make heavy use of their older mail (such as Accounting and Sales) so we had to go back and migrate their older data in to Exchange. This was simple to do with the Quest Migrator tool, but it was something we had to do "after the fact". Plus, a number of users immediately took to OWA and as such needed access to their older mail via OWA. So, some folks we had to import older mail on a case-by-case basis.

The user community is very decentralized and PST access across the company's WAN is also not desireable, so the Help Desk had to talk people through copying the PSTs to their local hard disks if they needed to access historical information. This has been a small fraction of the company, but still something that needed to be considered.

We jumped back and forth between having resource calendars (such as conference rooms) in Sharepoint and in Exchange. In the end, we could not get the level of integration with Outlook that we wanted with Sharepoint, so at the last minute the resource calendars came back in to Exchange. We used Simpler-Webb's Exchange Resource Manager for calendar management; it is cheap and easy to use.

In the Outlook training, I think it is important to let the users know that Outlook is NOT Notes. There are similarities, but often Notes does something one way and Outlook does it a completely different way. Outlook is different (and as an e-mail client, IMHO much better). Don't try to mutate / customize / change Outlook until it works like Notes. You will be disappointed.

For best results with the migration console, dedicate a FAST machine with fast local disks on the same network segment as the Notes and Exchange servers. We migrated a lot of the historical e-mail (all mail prior to a certain date) starting two weeks before the migration. That way, we only had a small amount of data that had to be migrated on cut-over day. On cut-over day is when I included in the Migrator's configuration that it should migrate also Contacts and Calendar information. We did not migrate that data in earlier passes of the Migrator tool.