Every migration is different, so the best method will differ too. But the use of standard protocols, and Microsoft’s vested interest in getting more people onto their platform, mean that migrating into Nexus365 is usually straightforward, reliable, and simple.
Third-party migration tools also exist, which may be able to bring across more than just messages, but those would need to be managed by the ITSS in charge of the source data. It should also be noted that some parts of the University have simply self-migrated by configuring Outlook to open both mailboxes side-by-side: users can drag-and-drop content from one to the other.
There are a few considerations to bear in mind whatever migration method will be used:
- Email routing and the timing of changes will need to be considered carefully – if the old mailbox is removed prior to the routing being updated, new incoming email could disappear into a black hole. To ensure this doesn’t happen the timing of routing changes, and user communication, is crucial.
- Users may need support in reconfiguring email clients on the day of any routing changes. We strongly advise ITSS to show users how to access Nexus365 webmail (‘OWA’) ahead of time, since that will give mailbox access from any web browser without the need for special reconfiguration.
- There may be forwarding configured on the Nexus365 mailbox to redirect email to the previous departmental system: those forwards will need to be removed on a carefully-managed schedule to avoid creating mail loops.
- Depending on exactly when in the migration process a user connects to Nexus365, they may find their mailbox empty: their old content is ‘backfilled’ into the new mailbox. Setting user expectations for this saves many support issues! Where migration delays would be unacceptable a user could self-import content via a PST file, or equivalent, rather than wait for the migration to finish.
- Existing content, such as calendar appointments, may lose the ‘friendly name’ of the person arranging the meeting once the old server is disconnected (the old address book won’t be available for lookups). We usually advise people to try to generate new items rather than attempt to edit historical ones, in an effort to minimise this effect.
- Users should be made aware that not all content can be migrated (a non-exhaustive list could include: rules, out-of-office messages, tasks, notes, signatures, auto-complete addresses, etc.) A migration from another Microsoft Exchange version will be the most complete.
- Nexus365 mailboxes are sized by the assigned licence, either 50GB or 100GB. Mailboxes in excess of the available space will either need to be assigned an A3 licence (users only; not shared mailboxes) or they will need to request an archive mailbox in which to store the excess content. The archive will usually have an assigned policy moving the oldest content into the archive automatically.
- Users with shared mailboxes will need to document and reconfigure any permissions which allow someone else access to their mailbox’s content. All shared mailboxes on Nexus365 must have a clearly-defined owner responsible for its content.
- Distribution groups and delegated group management will need to be considered and, perhaps, updated to use a different technology, such as a Sympa Mail-List, or a Microsoft Team.
- Resource mailboxes, such as parking spaces or meeting rooms will need to be re-created. Historical meetings migrated into a meeting room’s mailbox may lose their association with their original owner.
- Teams Rooms devices will need to be updated to use a new account, via a service request, which also requires a cost-code to which the associated licence’s purchase cost can be assigned.
- Migration capacity – the migration process creates a lot of simultaneous connections and can overwhelm modest hardware. You should ensure that the migration is timed or batched in such a way that your source server isn’t DDOS’d by the migration process itself.