Chat now with support
Chat with Support

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

About the Migrator for Notes to Exchange documentation Introduction Critical considerations Other strategic planning issues Appendix A: Known limitations of the migration process

Critical considerations

•
Develop a written Migration Plan
•
Know your migration scenario
•
Provisioning the target Active Directory
•
Diagram before-and-after site configurations
•
Migration scale
•
Coexistence during the transition
•
About Migrator for Notes to Exchange statistics
•
Test and pilot migrations

Develop a written Migration Plan

The migration of any enterprise is typically a complex process that requires careful planning and project management. Even a high-level summary checklist of necessary tasks can be quite long, and will expose a good number of details that must be addressed for a successful migration. The "choreography" in 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 dozens or hundreds of hours of user productivity, or cause unnecessary aggravation for end users. Quest therefore recommends you develop a comprehensive written Migration Plan before you begin any migration process.

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

1
Migration Scenario
2
Provisioning Method
3
Before-and-After Site Configurations
4
Migration Scale
5
Coexistence During the Transition
6
Test and Pilot Migrations

After those first six sections, your Migration Plan should contain (at least) 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

Virtually all migrations follow a similar basic process, with variations to accommodate each organization's circumstances and needs—what we collectively call a scenario. It is critical that you understand and characterize your scenario before you begin your migration planning, because your scenario will influence many important decisions about the processes and methods you will use to accomplish the migration. Most variations to the basic process result from:

•
Migration Destination (the Exchange "target" type):
•
Proprietary Exchange network
A proprietary Exchange environment is one whose hardware and software are wholly under the control of the migrating organization. Ordinarily this is a local Exchange network—on the same premises as the Notes source, or at least near enough to use high-performance network cables. But a proprietary Exchange target may also reside in a different location from the Notes source.
•
Hosted Exchange platform ("the cloud")
A hosted Exchange platform is one in which the hardware and software are owned and controlled by a third party. The hosting entity then sells, as a service, access to disk space and the Exchange software features. This service model is also known as "cloud" computing. The overwhelming majority of migrations to a hosted Exchange are to Microsoft’s Office 365.
•
Pre-Migration State of Existing Local Active Directory (if any): Part of the migration process depends on whether your organization already has a local Active Directory running for login and security purposes and, if so, the state of any objects already provisioned there.
•
If migrating to a proprietary Exchange: Do you already have an Active Directory up and running? If an existing AD has already been provisioned, are its objects already mail-enabled, mailbox-enabled, or neither?
•
If migrating to Office 365: Will you use a proprietary local Active Directory to provision the hosted environment and, if so, will you keep the local AD active after the migration? This method of provisioning permits single sign-on, also called identity federation, so users can access Office 365 services with the same corporate credentials (user name and password) they use for the local Active Directory. Alternatively, you could provision Office 365 without a local AD, by using Migrator for Notes to Exchange to provision Office 365 directly from the Notes/Domino source.
Your organization’s scenario and circumstances may point to a particular method of provisioning the target AD, or you may have a choice. See Provisioning the target Active Directory below for information to help you determine how you should provision the target AD.

Different combinations of target types and states of an existing local AD (if any) produce an array of migration scenarios. The Migrator for Notes to Exchange Scenarios Guide describes all of these combinations, and explains the migration procedures for each:

•
Migration to Proprietary Exchange:
•
No pre-existing Active Directory (or no AD objects yet exist).
•
AD objects exist in pre-existing Active Directory.
•
Migration to Office 365:
•
Provisioning Office 365 from a local Active Directory.
•
Provisioning Office 365 directly from Notes/Domino source.

The Scenarios Guide also describes three special-case scenarios, any of which would occur in combination with one of the above-listed scenarios:

•
Offline Migration: A strategy in which Notes source data that was previously extracted from Notes is migrated directly to the Exchange target. An offline strategy can be valuable:
•
if problematic bandwidth makes direct connection impractical (e.g., if the source and target servers are far apart—geographically and/or from a network perspective); or
•
if the Domino environment is managed by a third party that does not allow admin access; or
•
in a disaster scenario, where the Domino server is destroyed, but backup NSF files survive.
An offline migration can be accomplished by either of these two approaches:
•
Notes source data is saved to replica or otherwise-disconnected NSFs, and Migrator for Notes to Exchange’s Data Migration Wizard then migrates from the NSF files directly to Exchange.
•
Migrator for Notes to Exchange’s Data Migration Wizard migrates Notes source data to PST files (rather than directly to an online Exchange target), and the PST files are then imported into the Exchange target by some other application. Quest’s Migration Manager for PSTs would be a good choice for this purpose.
•
Phased (Staged) Migration Options: A migration strategy in which all but the most recent source data is "pre-migrated" to Exchange while all users remain active in Notes, so that the remaining Notes data (a much smaller volume) can be migrated much faster—often so that all users can be migrated together in a final "cutover" migration. Users continue to receive and send mail and manage their calendars in Notes throughout the transition period, while their older data is migrated to Exchange. If the final cutover can be accomplished in a single day or weekend, this strategy can eliminate the need for email, calendar and free/busy coexistence.
•
Silent Mode Options: A strategy to configure Migrator for Notes to Exchange's SSDM (the per- desktop migration app) to hide some or all of its screens, and take all of its required entry values from values stored in its pre-configured .ini file, thus eliminating or minimizing any need for interaction with the end user.

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. Office 365) require different provisioning methods. A local Active Directory can be provisioned directly from the Domino source by Migrator for Notes to Exchange tools in combination with Quest’s CMN Directory Connector (or some other directory synchronizing method). For Office 365 you can use Microsoft’s 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 Office 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 Office 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’s Notes address). An object is said to be mailbox-enabled when an Exchange mailbox is created for it.

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

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating