Chat now with support
Chat with Support

Migrator for GroupWise 4.7.1 - Scenarios Guide

About this guide Scenarios overview Migration to a proprietary Exchange target
Pre-migration preparations Batch migration process Post-migration activities
Migration to Office 365
Migration to Office 365 Pre-migration preparations Batch migration process Post-migration activities
SSDM (per-desktop) migration

Offline migration

Migrator for GroupWise supports offline migrations—whereby a copy of the GroupWise Post Office data is shipped to a central location and then migrated from the central location into Exchange. An offline migration is useful if, for example, your source and target servers are physically far apart, and limited bandwidth and a large volume of mail make live data transmissions impractical. In this case you could copy the GroupWise postoffice to a portable large-capacity storage medium, then physically transport the medium to another location where you have—or can create—a more favorable bandwidth connection to the Exchange server.

"Offline migration" can refer to either a migration from the GroupWise source to an offline storage medium (without a direct connection to an Exchange target environment), or a migration from an offline copy of the Post Office to an Exchange target. The most common scenario is when a copy of the GroupWise Post Office is transferred prior to the migration, but migration to PST is also an option. For migrations to PST this means selecting PST as the target for all data types. This is done either in a Migrator for GroupWise program screen, or by these gwmigapp.ini parameter settings:

Also, the software may attempt to query and set information in the Exchange environment as part of the conversion process, but the attempt would return an error if there were no direct connection to an Exchange server. These actions can be disabled, however, with these settings in gwmigapp.ini:

These settings will allow a successful migration to PST without access to the target Exchange environment.

A more common approach to offline migration with GroupWise is migrating without a connection to the source GroupWise Post Offices, accomplished by migrating from a backup of the GroupWise Post Office data files. With this approach, two things must be configured prior to the Post Office backup:

Migrator for GroupWise must be installed and allowed to establish itself as a Trusted Application within the GroupWise environment.

With these settings in place, a backup of the post office data can be taken and shipped (if required) to a central location for migration. Migrator for GroupWise is configured to connect directly to the backup files on a local file system for the migration.

This flexible approach is highly effective in low-bandwidth environments, and a variety of other scenarios.

Phased (staged) migration options

The term "phased migration" or "staged migration" refers to the process of pre-migrating or pre-populating data to target Exchange mailboxes prior to a final (or "cutover") migration. The staged migration may occur across the bandwidth or, in many cases, may be implemented in conjunction with the offline method described in the preceding section.

With this approach, a majority of the data can be pre-populated to the target mailboxes, which can reduce the amount of data that must be transferred during the final migration. Users remain active in GroupWise throughout most of the transition period, receiving and sending mail and managing their calendars in GroupWise just as they always have, while their oldest data (perhaps 90-95% or even more) is migrated to the new Exchange environment. After the older data has been migrated, the much smaller volume of data remaining can be migrated comparatively quickly, so that larger numbers of users (or all of them) can be migrated together within a shorter window. Since Migrator for GroupWise migrates copies of GroupWise data (does not delete the originals), the older data is still available to users in GroupWise throughout the transition period.

If a well-planned phased migration can condense the final cutover to a single weekend, the strategy may eliminate a need for coexistence. In our migration processes (chapters 2 and 3 of this Guide), we have flagged the steps you can skip for a no-coexistence migration.

A phased migration thus requires that you separate older mail from newer mail, and this can be accomplished by either of two methods:

Archives method: End users archive almost all of their mail, to within the current week, and then the admin uses Migrator for GroupWise’s Admin-Driven Batch Migrator to migrate the GroupWise archives to Exchange over a period of weeks. Then, after all archives have been migrated, the Batch Migrator can migrate all users to Exchange, with their remaining Post Office data.
Date filter method: The Admin-Driven Batch Migrator lets you specify date limits and ranges for messages to be migrated—to migrate only messages timestamped on or after (or before) a certain date, or within a particular range of dates.

Note that Migrator for GroupWise contains Smart Remigration technology, so that already-migrated items are detected and not duplicated if they are inadvertently migrated again.

Either of these methods will separate older mail from newer mail, but note that the date-filter method can eliminate the need for end user participation.

End-user communications are critical in a phased migration, to ensure the users understand the migration schedules. Modifications and deletions made in GroupWise between the migration events may not be reflected in Exchange after the final migration.

In a phased-migration strategy, by either method, the Exchange accounts and mailboxes must be created to accept the migrated data before end users actually start using their Exchange mailboxes or calendars. You therefore must run the Batch Migrator at least twice for each user group:

First Pass: to mailbox-enable user accounts on Exchange, set mail-forwarding rules on Exchange (to forward mail back to GroupWise until the users migrate), and migrate users' older data (archives, or date-filtered) to the new server; and then ...
Second Pass: to migrate the remaining (newer) data to Exchange, and migrate the users themselves to the new server—by reversing the mail-forwarding rules (to forward mail from GroupWise to the new Exchange mailboxes).

Users in this scenario will require continued access to their GroupWise mailboxes while the administrator migrates their older data, so they should keep their unique, secure passwords throughout the transition period. The program's access to GroupWise accounts should therefore be accomplished by some method other than by a common-value password. For an overview of the other methods, see Method of Access to GroupWise User Data in chapter 3 of the Migrator for GroupWise Pre-Migration Planning Guide.


Migration to a proprietary Exchange target

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 typically is on the same premises as the GroupWise source, but might also be located at some other site.

Migration to a proprietary Exchange environment includes an array of "sub-scenarios" depending on whether the organization already has its Active Directory configured and, if so, whether any objects it may already contain are mail-enabled, or mailbox-enabled, or neither.

NOTE: A mail-enabled Active Directory object is one with a mail-address attribute for an address outside the Exchange domain, so AD can forward the object’s mail to its other address. A mailbox-enabled object is one that has an Exchange mailbox. An AD object that is mail-enabled but not also mailbox-enabled cannot receive mail in Exchange since it does not have an Exchange mailbox; it can only forward mail to an object’s external forwarding address.

An organization may have an existing Active Directory already in place, for login and security purposes. When user accounts already exist in an established AD for login and security purposes, Migrator for GroupWise can use these objects to preserve the same credentials and security currently in use within the environment,, but the objects must also be mail-enabled and mailbox-enabled before data can be migrated to their target mailboxes.

When mail-enabled user objects exist in Active Directory, the Pre-Migration Preparations include extra steps to verify objects’ target/forwarding addresses (to ensure correct mail routing), and to create mailboxes for existing objects. When mailboxes already exist in Exchange, several of the optional steps in the Pre-Migration Preparations can simply be skipped.

Coexistence strategies also figure into the overall procedures. Most organizations’ migration plans include some form of coexistence, which requires a few extra steps to configure.

In these traditional scenarios, Migrator for GroupWise tools are run by admin accounts that are configured with the necessary permissions for access to directories and user data in both the source and the target environments.

This chapter provides process instructions for this group of scenarios.

NOTE: These procedures do not create users’ Exchange mailboxes until just prior to their migration (in the Batch migration process, per user batch), because Exchange is unable to send a free/busy query to GroupWise for a not-yet- migrated user who already has an Exchange mailbox. Exchange can direct such queries only to Exchange mailboxes. If you will not configure free/busy coexistence, you could create Exchange mailboxes earlier in the process, in these Pre-Migration Preparations—as long as you also set Exchange-to-GroupWise mail forwarding during the transition for not-yet-migrated GroupWise users.

Pre-migration preparations

Any migration scenario requires prior preparation of the source and target environments, configuration of admin accounts and a coexistence strategy, and preparation of the required software you will use as part of the migration process. These procedures can be complex because they include configuring necessary account permissions across separate environments, configuring applications running concurrently to facilitate the migration, and various other considerations. However, these tasks are typically performed once, before the first user group or first user is migrated, so they do not need to complicate the entire migration process.

The flow chart below illustrates these pre-migration preparations for migration to a proprietary Exchange target. Note that the step numbers in the flow chart correspond to the step numbers in the process instructions here.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating