Last week, I briefly mentioned that Microsoft had released an updated version of the Application Analyzer 2006 for Lotus Domino (http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=en&familyid=D94C5719-570D-4ADB-B449-70E1E42CBFC5&displaylang=en ), and I promised to talk more about it this week. More generally, though, it's interesting to look at the state of the art and state of the market, for Exchange migration tools.
First, it's important to use the right vocabulary--or at least the same terms that Microsoft uses in the official documentation. If you move from some other messaging system (e.g., Lotus Notes or a UNIX POP3 server) to Exchange Server 2003, that's a migration. If you move from Exchange Server 5.5 to Exchange 2003, Microsoft also considers that a migration. However, if you move from Exchange 2000 Server to Exchange 2003, that's an upgrade. I'll stick with these definitions for the remainder of the column.
Microsoft has always offered some set of migration tools as part of the Exchange product. The Migration Wizard (migwiz.exe) in Exchange 5.5, for example, could migrate mail and calendar data from several foreign system types (including LDAP/IMAP systems, cc:Mail, Lotus Notes, and Novell GroupWise 5.x). Over time, Microsoft's commitment to shipping migration tools has waxed and waned; in Exchange 2003, the in-the-box tools include an updated version of migwiz and connectors to allow message, calendar, and public folder data interchange with selected versions of GroupWise and Notes. For example, the latest version of GroupWise is version 7.0, and the Microsoft GroupWise connector doesn't officially support that version (although I understand that it works fine). There are many third parties that offer migration tools for other messaging/calendaring systems; for example, Simpler-Webb offers tools to migrate from HP OpenMail, Samsung Contact, and Scalix, whereas Quest Software offers well-regarded tools for migrating from GroupWise and Notes.
For many migrations, it's enough to just move email and calendar data; mail-moving tools are sufficient for users migrating from Oracle Collaboration Suite, IMAP or POP-based systems, GroupWise, and a variety of lesser-known products. However, Notes migrations are a different animal because many Notes customers are also using collaborative applications built with Notes; although Exchange clearly offers a better messaging and calendaring system than Notes (particularly when you include the desktop client in the comparison), companies that have invested heavily in Notes application development quite rightly worry about preserving their application investments.
Microsoft's tack toward these customers is straightforward: The company has moved away from claims that migration is easy to a more nuanced position that admits the way things really are--some applications are harder to move than others. In addition, it has proposed a framework that classifies applications according to the amount of customization and embedded logic in the application; lightly customized applications or those with minimal embedded logic are obviously easier to move than large, heavily customized ones. (To see more about this methodology, see the blog for the collaboration tools team at Microsoft ( http://blogs.technet.com/collabtools ). That's what the new Application Analyzer tool is for. It scans the applications in use on a set of Domino servers and reports back on which applications fall into which categories. As with any other automated tool that attempts to interpret code, its results still require human interpretation. (Oh, the stories I could tell about automated code analysis tools from the days when I wrote Ada compilers for a living!)
The missing piece in the migration story is moving the applications themselves to a new platform. There are several different ways to accomplish this, ranging from completely rewriting the application using the .NET Framework to writing a new front-end in .NET and exposing the existing data through the Component Object Model (COM) interfaces or by embedding Notes data and presentation logic in a SharePoint Web Part. Several companies make tools for moving Notes data (including document libraries) to SharePoint libraries or Exchange public folders, but as yet, the market for tools that attempt to convert the code is still fairly small in scope, with only a few vendors even making the attempt. I expect this situation to change as the battle between Microsoft and IBM intensifies; IBM is pushing Notes, and its successor, Workplace Collaboration Services, as a future-proof way to protect existing investments, whereas Microsoft is countering with the argument that its platform offers better technology, a lower total cost, and more functionality to boot.
Of course, in the Exchange world, most of the attention around migration is focused on moving from Exchange 5.5 to Exchange 2003. I had a great meeting with a customer this week that I think exemplified the *right* way to prepare for such a migration. Next week I'll tell you why I think so.