Preparing for migration to Global Mailbox
Before migrating your mailboxes to Global Mailbox you must make sure you are prepared for the transition. Consider which mailboxes, users, and routing rules that are defined in your source system that you want to have in your target system.
Traditional mailboxes are served in one data center. If there is an outage in that data center, service is interrupted. With Global Mailbox, the mailboxes and operations are replicated to other data centers. When these data centers are configured for high availability, an outage in one data center can be covered in another data center until service is restored.
- Each traditional mailbox in Sterling B2B Integrator that is to be migrated. These mailboxes must be individually identified with no implied parent or child inclusion assumed. There must be no mailbox gaps between identified mailboxes.
- All users to be migrated. The users must have virtual roots for a migrating mailbox. Users
without a virtual root in Sterling B2B Integrator have
an implicit virtual of
/(including admin). Migrating users without a virtual root must have one explicitly created from the Sterling B2B Integrator dashboard before proceeding with migration. - All Sterling B2B Integrator routing rules to be migrated. These routing rules must correspond to mailboxes to be migrated. You can migrate a manual routing rule, but it is disabled in Global Mailbox.
- Which mailboxes have messages to be migrated, and when they will be migrated. This depends on what the messages are being used for (producer or consumer), whether they are being actively processed, whether there is active inflow, if they are deleted externally, and other business considerations.
| Traditional mailboxes to be migrated | Whether messages in the migrating mailbox must be migrated, with notes on the types of messages | Users to be migrated, with a virtual root associated with the migrating mailbox | Routing rules to be migrated, corresponding to the migrating mailbox |
|---|---|---|---|
Consider whether downtime is required for the migration. For example, if the files that are transferred must not be sent more than one time, or if it is critical that no files be lost, there is less risk if operations are stopped before the migration. If this is the case, plan how that can be accomplished. Methods for stopping operations include removing permissions or disabling protocol adapters.