Migrator for Notes to Exchange 4.15.2

This Guide provides process instructions that show how Migrator for Notes to Exchange is used within the broader context of a migration project. The processes described here include steps that are performed outside the scope of Migrator for Notes to Exchange—within Notes and Exchange, and with coexistence tools like Quest’s CMN—because the sequence and interplay among the solutions and environments are important. Flow charts illustrate the correct sequences of steps for all common scenarios.

Virtually all migrations follow a similar basic process, with variations to accommodate each organization's circumstances and needs—what we collectively call a scenario. Most variations to the 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.

Different combinations of target types and states of an existing local AD (if any) produce an array of migration scenarios. This Scenarios Guide describes all of these combinations, and summarizes the migration process 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.

We also describe three special-case scenarios, each of which would occur in combination with one of the above-listed scenarios:

•

Offline Migration: A migration strategy in which Notes source data that was previously extracted from Notes is migrated directly to the Exchange target. This option supports scenarios where it is impossible or impractical for the source and target servers to both be connected to Migrator for Notes to Exchange at the same time, so the data cannot be copied directly from the source to the target.

•

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.

Chapters 2 and 3 of this Guide provide step-by-step process instructions that cover all of these scenarios. Since all migrations follow the same basic process, with just a few variations for particular needs and preferences, we can generalize to present just two linear procedures that are suitable for nearly all scenarios: one for migration to a proprietary Exchange (described in chapter 2 of this Guide), and the other for migration to Office 365 (chapter 3).

Of course some steps in both primary scenarios are optional or conditional, depending on local variations in needs and preferences, and these are clearly marked within the instructions by this “If” icon and note:


	Conditional Step: Conditional steps appear within the process instructions (in chapters 2 and 3) marked with this "If" branching-arrows icon.

Chapter 4 explains the admin activities and considerations associated with per-desktop migrations, which may occur with or without batch migrations, or may not be used at all—depending on your needs.

The Migrator for Notes to Exchange pre-migration preparations and batch-migration processes are illustrated in two flow charts for each primary target type: proprietary and hosted (Office 365). The flow charts are presented in this first chapter as introductory overviews to the processes, and appear again as references with the process instructions in chapters 2 and 3.

The process instructions in this Guide are also meant to serve as summary checklists, so they do not include the operational details and screen-by-screen field notes for Migrator for Notes to Exchange component applications. Instead, many of the steps in these procedures refer to those details within particular chapters and sections of the Migrator for Notes to Exchange Administration Guide.

Migration to proprietary Exchange

For our purposes, a proprietary Exchange environment is one whose hardware and software are wholly under the control of the migrating organization. A proprietary Exchange server is commonly in the same location as the source Notes environment, but may reside at another location.

When migrating to a proprietary Exchange, some steps in the procedures depend on the state of any objects that may already exist in an existing Active Directory. An organization may have an existing Active Directory for login and security purposes. When user accounts already exist in Active Directory, Migrator for Notes to Exchange can use these objects to preserve the same credentials and security within the environment. AD objects must also be mail-enabled and mailbox-enabled before data can be migrated for those users. (An object is said to be mail-enabled when Exchange can accept a message for it—because the object record contains a forwarding address to which mail can be routed. An object is said to be mailbox- enabled only when it has an active mailbox in Exchange.)

If your target AD has not yet been installed and configured, or if your migrating Notes users have not yet been provisioned into the target AD, our pre-migration preparations include optional steps to install and configure the target Exchange environment, and provision and mail-enable AD objects.


	NOTE: Exchange cannot send a free/busy query to an external server for a user who has an Exchange mailbox. Exchange can direct such queries only to the users’ Exchange mailboxes, so free/busy queries for not-yet-migrated Notes users will work only if the users do not yet have Exchange mailboxes. Since many organizations use CMN’s Free/Busy Connector during the transition period, our pre-migration preparations provision mail-enabled objects into Active Directory without mailboxes. Objects must be mail-enabled for mail-forwarding, but not before, so we do not create users’ mailboxes until just prior to their migration—in the batch migration process (per user batch). This mitigates the effects of the Exchange free/busy limitation by limiting its duration (the time between mailbox creation and migration). If mailboxes already exist in the target Exchange, free/busy queries to not-yet-migrated Notes users will not work until those users are migrated to Exchange. In that case several of the optional pre-migration steps can be skipped, but other configuration and administrative tasks are still required before the actual migration can begin.

All scenarios include optional steps for coexistence, as described later. And the pre-migration preparations include steps to verify all objects’ target/forwarding addresses, to ensure correct mail routing.

In these scenarios, an admin runs Migrator for Notes to Exchange component applications using admin accounts configured with the necessary permissions to access the directories and user data in both the source and the target environments.

Step-by-step instructions and more detailed notes for migrations to proprietary Exchange targets appear in chapter 2.

Selecione seu produto:

Para podermos atendê-lo melhor, informe o Propósito de seu chat:

Soluções recomendadas para seu problema

Migrator for Notes to Exchange 4.15.2 - Scenarios Guide

Visit our Windows Management and Migration online community

Scenarios overview

About Migrator for Notes to Exchange scenarios and this guide

Migration to proprietary Exchange