Why is a discussion of business-oriented concepts essential in a technical on the topic of messaging migration? Quite simply put, it’s because this
can be one of the most significant decisions your organization makes over the Chapter 1. Why migrate from Exchange 5.5 to Domino 10 next several years. It will directly affect many other decisions and opportunities available to you. Most notably, your options to exploit emerging enterprise architecture models—for example, Java 2 Enterprise Edition (J2EE), Microsoft .NET, and Web services—will be fundamentally defined by the choice you make in your messaging and collaboration platform. Note that we do not assert, as do some vendors, that the migration activity is without effort, expense, or even risk. In fact, we emphasize throughout this book that, as with any “touch” of core IT infrastructure, detailed analysis, thorough planning, and clear and constant communication are the keys to success. However, a forthright and honest business-oriented discussion illustrates that the benefits are greater, and the risks far lower, in migrating to Domino rather than remaining on Exchange or continuing on the path that Microsoft has laid out for the future of Exchange.
What does migrating from Exchange to Domino involve?
As an Exchange user, you are familiar with the basic components of client-server messaging and scheduling. Domino offers all of the same capabilities, and many more, although those are outside the scope of this redbook. We’ll touch on the application and solution capabilities of Domino in the “why” section of this
chapter, with pointers to more information, but for the purposes of this discussion we’ll stick to the equivalent messaging and scheduling capabilities of Domino and Exchange.The migration process Both Domino and Exchange fall in the International Data Corporation (IDC) market classification of “integrated collaborative environment,” or ICE. An ICE ssystem is comprised of messaging and scheduling server software and a matching client component. Microsoft offers Exchange as the server and Outlook as the client, and IBM Lotus offers Domino as the server and Notes as the client.
Through evolution, both Exchange and Domino also support alternate client and server interfaces, such as Web (HTTP) for e-mail and scheduling, POP3 and
IMAP for e-mail, and iCAL for scheduling. These are discussed later in this section. Domino also supports Outlook as a client, although Exchange does not
support Notes as a client except through POP3 or IMAP.The migration process itself involves some basic architectural and process
choices, which are covered extensively in this book. The two primary options are:
“flash” cut-over versus coexistence; and data migration versus “clean start”
migration, where previous data is archived and new e-mail and scheduling starts
over at the point of migration. For most moderately-sized organizations using
basic Exchange e-mail and scheduling, it is reasonable to expect a seamless
user experience; in these cases users will simply arrive at work one morning and
The first phase of the migration project involves understanding the current environment. Prelim analysis is performed on the enterprise
network with the help of tools to generate an inventory of existing Lotus Notes infrastructure (servers, workstations etc.) and applications that exist in the enterprise. The tools are also involved in the cleanup job to identify similar databases, system databases, databases that are not used for a long time, etc. It helps in reducing the inventory size.
Tools running on this list analyze each application. Based on the tool based analysis, various reports are generated related to the size of the application, its usage statistics and structure (whether developed on a standard template or customized template; does it have web forms or whether it uses workflow etc.). The applications categorized based on these attributes provide suggestions on target platform. The outcome of this phase is reports that are vital inputs for the next phase.
Migration Understanding and Setup
This phase consists of understanding the application inventory. A quick round of discussion with IT and business users helps make required changes to the migration set. Business dependencies, dependencies with respect to other systems (mails migration, user migration to AD etc.) and applications are identified in this phase. This helps develop the dependency matrix and migration schedule. In this phase, migration development and testing environment are set up with a basic understanding of the production environment.
Analysis phase involves filtering of the application list generated in the prelim analysis phase. Applications are categorized into various
This phase acts as a proof of the migration plan. A small representative set of applications is taken up for migration. As these applications are migrated, rough edges in the plan are identified and corrective actions are taken.
Individual App Migration
This phase involves actual migration, testing and acceptance of applications. It is suggested to execute this phase in iterations. Migration strategy for each application under migration is decided based upon the analysis result and could involve diverse strategies such as automated migration, migration SharePoint to IBM Notes App custom development and so on. Applications migrated in each iteration are picked based on a specific criteria, and subjected to Quality Assurance (QA) and User Acceptance Testing (UAT). After this, business can decide to move the migrated applications to the next phase.