Plan the move around the source system, data and workflows you must preserve. An Exchange replacement, a MailSite 10 upgrade and an update between MailSite 11 builds require different procedures. Use the release-specific instructions and agree the transfer method with Rockliffe before scheduling production changes.
1. Inventory what must move
- List domains, mailboxes, aliases, forwarding rules, mailing lists, quotas and authentication sources.
- Record message and folder volumes, contacts, calendars, recurring meetings, shared resources, delegates, permissions and client-side data.
- Identify applications that send mail and integrations for archiving, retention, compliance or backup. Record exact Outlook editions, builds and other clients.
Use this inventory as the acceptance checklist for the pilot and the final move.
2. Confirm the migration path
- From Exchange or another mail platform: confirm a supported tool or service for each data type with Rockliffe Professional Services. Establish how mail, calendars, contacts and permissions will transfer and how changes made during the transfer will be reconciled. A working IMAP connection alone does not establish a calendar, contact or permission migration path.
- From MailSite 10: use the eligible upgrade path in the v11 installer. Back up the original system and check release-specific compatibility changes before upgrading.
- Between MailSite 11 builds: check release notes for database reset boundaries and client resynchronization requirements. Restoring old binaries alone does not recover discarded database state.
The MailSite configuration export utility excludes messages. A configuration export is not a mailbox-content migration or a complete backup. See the backup and export instructions and migration support FAQ.
3. Prove the move with representative accounts
- Prepare an isolated destination using the deployment guide. Preserve recoverable source data and prevent the pilot from taking over production mail routing.
- Transfer representative accounts using the agreed method. Compare folder structure and item counts, inspect attachments and dates, and verify contacts, recurring meetings, permissions and shared access.
- Create and test the intended client profiles. Confirm how users will reconnect and protect local-only data before changing profiles or caches.
- Test internal and external delivery, mobile synchronization, application mail and the workflows in the inventory. Record failures and resolve them before cutover.
Outlook Connectivity explains why testing one client or protocol does not validate another.
4. Plan coexistence and cutover
- If both systems must run during migration, agree routing ownership, recipient discovery and the treatment of shared calendars and free/busy. Do not assume Exchange hybrid or cross-system sharing carries over.
- Define the change window, final synchronization or write freeze, DNS and mail-routing changes, and client profile/discovery updates. Assign an owner to each step.
- Tell users when changes occur and how to reconnect. Prepare support coverage and a list of post-cutover checks.
- Define rollback triggers and how mail accepted by the new server will be preserved and reconciled. A DNS reversal by itself does not move that mail back.
5. Verify before retiring the source
Recheck incoming and outgoing mail, queued messages, client access, calendars, contacts, permissions and integrations after cutover. Confirm a recoverable backup of the destination. Retain the source and recovery copies according to the agreed retention plan until data and workflow acceptance is complete.