Migrator for Notes to Exchange 4.16.3 - Pre-Migration Planning Guide

Develop a written Migration Plan

An enterprise migration is a complex process that requires careful planning and project management. Even a high-level summary checklist of necessary tasks can be long and can expose many details to be addressed for a successful migration. The logistics of the sequence, timing, and coordination of tasks is also important.

The complexity of most migration projects makes planning, foresight, and communications critical to a smooth migration. Halfway through the migration process is no time to discover that a neglected detail or invalid assumption will cost hundreds of hours of user productivity, or cause unnecessary aggravation for end users. Quest recommends that you develop a comprehensive written Migration Plan before you start the migration process.

Developing a Migration Plan is a valuable exercise that leads you to consider and accommodate all the factors that affect an organization's migration. The first six sections of your Migration Plan should characterize your primary needs, environment, and strategies as explained in this chapter:

After the first six sections, your Migration Plan should contain sections and subsections that describe suitable choices for all relevant topics in chapter 3 of this guide: Other strategic planning issues.

Know your migration scenario

Most migrations follow a similar basic process with variations to accommodate circumstances and needs—a migration scenario. It is critical that you understand and characterize your scenario before you begin migration planning because your scenario will influence the decisions about the processes and methods you use to accomplish the migration. Most variations to the basic process result from:

Different combinations of target types and existing local AD can produce an array of migration scenarios. The Migrator for Notes to Exchange Scenarios Guide describes the combinations and explains the migration procedures for each:

The MNE Scenarios Guide also describes three special scenarios that can occur in combination with one of the previously listed scenarios:

Characterize your migration scenario in the first section of your Migration Plan.

Provisioning the target Active Directory

Different target types (a local Active Directory vs. Microsoft 365) require different provisioning methods. A local Active Directory can be provisioned directly from the Domino source using Migrator for Notes to Exchange tools in combination with Quest CMN Directory Connector (or some other directory synchronizing method). For Microsoft 365 you can use Microsoft AD sync tool to copy objects into the hosted AD from a local, proprietary AD (previously provisioned locally), or Migrator for Notes to Exchange tools can provision directly from Domino.

IMPORTANT: If you intend to configure free/busy coexistence between Domino and either a local proprietary Exchange or Microsoft 365, the timing of your pro­visioning task (within the overall migration process) will be affected by this known Exchange behavior: • Exchange cannot send a free/busy query to Domino for any user who has an Exchange mailbox. Exchange can direct such queries only to its own mailboxes. • The significance and implications of this limitation depend on whether you are migrating to a proprietary AD or to Microsoft 365, as explained separately below.

Provisioning includes mail-enabling and/or mailbox-enabling the objects in the target AD. An Active Directory object is said to be mail-enabled when the AD object record contains a forwarding address to which mail can be routed (i.e., to the user Notes address). An object is said to be mailbox-enabled when an Exchange mailbox is created for it.

Review the information that follows to determine your provisioning method, and note it in your Migration Plan.

Provisioning a local proprietary Active Directory

The MNE tools can provision Active Directory from the Domino source. The typical and most direct method to provision a local AD begins with an MNE directory export, followed by a directory update by the CMN Directory Connector, as illustrated.

Your organization may already have an Active Directory running for login and security purposes and, if so, Migrator for Notes to Exchange can synchronize the existing AD objects with the Domino objects and mail-enable the AD objects. In either case, this provisioning step is necessary before any users are migrated.

In many organizations the migrating users are already using AD security objects for network authentication prior to the migration project.Where Notes users already exist as user objects in Active Directory, the CMN Directory Connector (and other directory-update tools) will produce duplicate entities in AD. But MNE includes a Provisioning Wizard that can merge the contact information into the original AD object record and delete the contact, leaving a single mail-enabled object in Active Directory.

Other MNE wizards can mailbox-enable the AD accounts and provision groups in AD.

When provisioning a local Active Directory, be sure to provision all Notes users into AD as mail-enabled objects, without Exchange mailboxes before you migrate the first user. Provisioning mail-enabled objects into AD will facilitate Exchange-to-Notes mail forwarding, to correctly route mail that arrives (or originates) in Exchange for not-yet-migrated Notes recipients. But Exchange mailboxes would disable Exchange-to-Notes free/busy queries: Exchange cannot send free/busy queries to an external server for a user who already has an Exchange mailbox.

This Exchange free/busy restriction becomes irrelevant if you defer creating user mailboxes until before their migration, several steps later. The standard scenario procedures (in chapter 2 of the Migrator for Notes to Exchange Scenarios Guide) follow this approach for provisioning local proprietary Active Directory.