A business email move looks simple when described only as a number of mailboxes. In practice, staff also rely on shared addresses, delegated access, calendars, contact lists, archived messages and the devices they use every day. A useful quotation names these dependencies before anyone assumes that moving email completes the project.
Build an inventory your team can approve
List active users, shared mailboxes, aliases, account owners and approximate mailbox sizes. Identify people who work across multiple devices or who have access to a colleague’s calendar. Record where files and historical archives are stored. Ask a business owner to confirm which accounts remain necessary; do not silently omit an account simply because it appears inactive.
Keep passwords and sensitive mailbox exports out of ordinary enquiry forms. The initial brief needs scope information, not secret credentials. Technical access should be arranged through an approved process with named administrators and clear permission boundaries.
Choose a method based on the source
Microsoft documents several migration routes, including Exchange, IMAP and imports of existing mailbox information. Their capabilities are not interchangeable. In particular, Microsoft states that IMAP migration moves email items but not contacts, calendar items or tasks. If your team relies on those features, require a separate plan and test it before agreeing that the job is complete.
Ask the provider to explain source compatibility, tool limitations and what will not move. A smaller mailbox with complicated permissions may require more planning than a larger simple account. Mailbox counts alone are therefore a poor substitute for a written scope.
Prepare access and staff expectations
Confirm the intended licence mix, who will administer the environment and how users will enrol in the agreed authentication controls. Document which applications, phones and shared resources need reconfiguration. Plan staff communications so users know when to stop using the old environment, where to find help and how to report missing items.
Run a representative pilot
Choose pilot accounts that cover the real ways your business works. Test ordinary messages, older folders, shared access and the agreed collaboration features. Record what moved, what did not and whether exceptions need a different method. A pilot should uncover limitations before they affect the entire team, rather than serve as a demonstration with only the easiest account.
Agree cutover and acceptance
Set an approved transition window and define who can authorise a delay. Agree how the team will check incoming and outgoing email, expected historical messages and the non-email content included in scope. Keep an exception register with an owner for each unresolved issue. A successful migration-tool status is useful evidence, but it is not the same as users confirming that their business workflow functions.
Separate migration from ongoing support
Ask what happens after handover: who manages new users, licence changes, device issues and recovery requests? Confirm whether backup subscriptions, migration tools and post-launch assistance are included or separate. Do not assume that a once-off implementation includes indefinite support or a guarantee of uninterrupted service.
MBICT welcomes enquiries from all nine provinces. Review Microsoft 365 setup and migration, compare the existing package scopes and include your source system, mailbox inventory and intended transition window in your brief. For a wider system move, see the data migration validation checklist.