What preparation is needed before a Microsoft 365 migration?

Preparation for a Microsoft 365 migration should establish how the organisation will operate in the new environment, who will make decisions, and which technical and business rules must be applied. Alongside the technical work, the organisation needs agreed governance, a clear target structure, user communications, operational ownership and a controlled approach to testing and adoption.

Establish migration ownership and decision-making

Nominate a business sponsor, project lead and technical leads before detailed work begins. The project should also identify representatives from departments that depend heavily on email, shared documents, calendars, collaboration tools or line-of-business processes. These representatives can confirm how work is performed today and approve changes to permissions, document structures and working practices.

Record who can approve changes, who handles user queries, who authorises any postponement, and who takes ownership of the Microsoft 365 environment after the migration. Without defined ownership, technical decisions can remain unresolved and operational issues can be passed between teams.

Define the target operating model

Migration preparation should describe what the finished environment is intended to look like, rather than treating the move as a simple transfer of existing content. Decisions commonly include:

• Which teams or departments will own Microsoft 365 services and their associated settings.
• How administrative privileges will be divided between internal staff and any external IT provider.
• Which naming conventions will apply to groups, teams, shared mailboxes, sites and other resources.
• How new workspaces will be requested, approved, reviewed and eventually closed.
• Which collaboration practices should be standard, such as where departmental documents are created and shared.
• How ownership will be maintained when employees change role or leave the organisation.

These decisions prevent the new tenant from reproducing unnecessary complexity and make it easier to manage as the organisation grows.

Prepare the information architecture

Microsoft 365 includes several places where information can be stored and shared. Before migration, agree the intended use of personal storage, team sites, shared libraries, collaboration spaces and shared mailboxes. Define who should have access to each area and whether access should be granted to individuals, job roles or groups.

It is also useful to establish rules for document ownership, version control, external sharing and the creation of new collaboration spaces. A simple structure is usually easier to govern than a direct replica of years of accumulated folders and ad hoc permissions. These choices should be documented so that new content is managed consistently after the move.

Confirm operational prerequisites

Technical readiness includes more than the migration tooling. Check that the organisation has suitable administrative accounts, secure methods for granting privileged access, an agreed method for recording changes, and a protected location for project documentation. Confirm that the people responsible for the migration can access the required source and destination systems, and that any approval or change-control process will not delay planned activities.

Review workstation and mobile management requirements, including how users will receive configuration instructions and how lost or replaced devices will be handled. Where staff work from multiple locations, confirm that their normal connectivity and authentication arrangements are suitable for the new service. Any constraints should be recorded before the migration begins rather than discovered during user onboarding.

Plan communications and user preparation

Users need practical information about what will change, what they must do, and where to obtain help. Prepare communications for different audiences rather than sending one technical message to everyone. For example, general users may need guidance on signing in, accessing files and setting up applications, while managers may need information about shared resources and approval responsibilities.

A communications plan should identify the messages to issue before, during and after each migration stage. It should explain any changes to terminology, document locations, collaboration methods or user actions without relying on technical jargon. Short guides, demonstrations and frequently asked questions can reduce avoidable support requests. Selective user briefings or pilot groups can also expose unclear instructions before they are issued more widely.

Agree the testing approach

Testing should be based on representative business activities, not only on whether accounts and files appear in the destination environment. Define test cases for common tasks such as sending and receiving messages, accessing shared resources, collaborating on documents, using calendars, connecting approved applications and working from the devices used by each relevant user group.

Choose testers who understand real business processes, including users with different roles and access levels. Record the expected result, observed result, owner and resolution for every test. Set acceptance criteria in advance so the project team knows which issues must be corrected before progression and which can be handled through post-migration support.

Prepare support and continuity arrangements

Decide how incidents and user questions will be logged, prioritised and assigned during the migration. Support staff should have access to the relevant documentation, known-issue list and escalation contacts. Prepare standard responses for common problems such as sign-in difficulties, missing shortcuts, incorrect permissions and application prompts.

Business continuity arrangements should identify essential activities and the alternative process to use if a service or migrated resource is temporarily unavailable. This may involve agreed manual procedures, access to approved copies of essential information or a clear route for escalating a business-critical problem. The arrangements should be understood by the people who operate the affected processes, not kept solely within the technical project team.

Review the final readiness decision

Before authorising the migration, hold a formal readiness review. Confirm that outstanding decisions have owners, communications are prepared, test results have been assessed, support arrangements are in place and business representatives understand their responsibilities. Any unresolved issue should be categorised by impact, with an explicit decision on whether it must be resolved before the next stage or can be accepted and tracked afterwards.

This final review turns preparation into an accountable decision rather than an informal assumption that the organisation is ready. It also creates a useful record of the agreed starting position for managing Microsoft 365 after the migration is complete.