Office 365 Migration Security Best Practices

An Office 365 migration temporarily brings together privileged identities, application permissions, mailbox data, migration reports, and access to source and target environments. Each element needs a named owner, a defined purpose, and a planned removal date. The security objective is straightforward: give people and applications only the access required for the migration, monitor how that access is used, and remove it when the work is complete.

This guide is written for Microsoft 365 administrators, security teams, migration engineers, and service providers preparing an Office 365 migration. It covers the controls to review before data movement, the evidence to collect during migration, and the access cleanup required after cutover. Product permissions and authentication choices should always be matched to the selected workloads and migration direction.

1. 1. Establish the security baseline before migration

   Start with a written inventory of the source and target environments. Record the workloads in scope, migration administrators, application registrations, role assignments, mailbox delegation, retention requirements, network paths, and locations where reports or temporary files may be stored.

   Define ownership and approval

   • Name an owner for source access, target access, application consent, Conditional Access changes, and post-migration cleanup.
   • Document the approved migration window and the administrators allowed to start, pause, retry, or cancel jobs.
   • Identify regulated or sensitive mailboxes that require additional approval, logging, or validation.
   • Record the expected role assignments and mailbox permissions before migration so unexpected changes can be detected later.

   Assess the migration provider and operating model

   Confirm where the migration software runs, whether data is staged, which tenant permissions are requested, how credentials are protected, what information appears in logs, and how project data is deleted. Review support access, subprocessors, incident notification, data residency, and contract terms when they apply to your organization.

   A vendor security statement does not replace tenant-side controls. Your administrators still control consent, role assignment, migration workstation security, report access, and removal of temporary access.

2. 2. Protect administrator and application identities

   Use task-based least privilege

   Select roles and API permissions from the actual migration tasks. Avoid assigning Global Administrator merely for convenience. Some setup actions may require a privileged role, but that role should be activated only for the required task and removed when it is no longer needed. Where licensing permits, Microsoft Entra Privileged Identity Management can provide time-limited role activation, approval, MFA, and audit records.

   • Use separate named administrator accounts for migration work rather than shared credentials.
   • Do not use migration administrator accounts for email, web browsing, or unrelated daily tasks.
   • Require MFA for human administrators and use phishing-resistant methods where organizational policy supports them.
   • Keep emergency access accounts available and monitor their use so Conditional Access changes do not create a tenant lockout.

   Handle application access separately

   Unattended applications and service principals cannot respond to an MFA prompt. Use the documented OAuth app-only flow where it is supported, assign only the required application permissions, and protect the associated certificate or secret. Prefer certificate credentials over shared secrets where the migration workflow supports certificates.

   • Register the application in the correct tenant and verify publisher, redirect URI, credential expiry, and consented permissions.
   • Store certificates and secrets in an approved credential store. Do not place them in scripts, tickets, shared folders, or migration notes.
   • Set a credential owner and expiration date, monitor service-principal sign-ins, and rotate credentials if they may have been exposed.
   • Review EdbMails guidance for Office 365 migration using app-only authentication before granting tenant-wide application consent.

   Test Conditional Access without weakening protection

   Test the exact interactive and app-only authentication paths before the production migration. If a policy exception is required, scope it to the specific identity, location, device, or application that needs it. Give the exception an owner and expiry date, then remove it after validation. Workload identity policies should target service principals directly where that control is available.

3. 3. Protect migration traffic, workstations, and temporary data

   Use approved migration hosts

   • Run migration software on a supported, patched operating system with endpoint protection and restricted local administrator access.
   • Limit interactive access to approved operators and prevent unrelated software from using the migration host.
   • Use encrypted storage for temporary exports, logs, credential material, and configuration backups.
   • Synchronize system time so migration reports, sign-in events, and audit records can be correlated accurately.

   Restrict network access to the required services

   Use HTTPS and current TLS settings for Microsoft 365 and migration connections. Configure firewalls and proxies for the documented service endpoints rather than broad outbound access. Review the Microsoft 365 migration URLs and endpoints used by the selected workflow.

   If a proxy performs TLS inspection, confirm that authentication and Microsoft 365 connections work through the approved configuration. Remote administrators should use a managed device and the organization's approved protected connection. A VPN is necessary only when organizational policy or access design requires it.

   Control reports and exported data

   Migration logs are useful for troubleshooting, but they may contain user principal names, mailbox identifiers, folder paths, error details, or item-level information. Restrict access, redact logs before sending them to third parties, and use an approved support channel. Define how long reports, screenshots, CSV mapping files, and temporary exports will be retained.

4. 4. Monitor the migration and preserve evidence

   Before the first production batch, confirm that Microsoft Purview audit search, Microsoft Entra sign-in logs, security alerts, and EdbMails migration reports are available to the people responsible for monitoring. Microsoft 365 audit logging is generally enabled by default, but administrators should verify that records are searchable and that the available retention period meets project and compliance needs.

   Monitor during each migration window

   • Review successful and failed administrator sign-ins, unfamiliar locations, risky sign-ins, and unexpected Conditional Access results.
   • Watch for new role assignments, application consents, credential additions, mailbox permission changes, and changes to security policies.
   • Compare migration job volume with the approved batch plan and investigate unexpected mailboxes or workloads.
   • Retain EdbMails reports that show source, target, timestamps, status, and errors for the approved evidence period.

   Prepare an incident response route

   Define who can stop migration jobs, revoke tokens, disable an account, remove an application credential, isolate the migration host, and notify affected teams. If suspicious activity appears, preserve relevant logs before changing the environment so the incident can be investigated.

5. 5. Remove temporary access and validate the target

   Cutover completion is the start of the cleanup phase. Compare the target with the approved baseline, close temporary access paths, and record the evidence required by operations, security, and compliance teams.

   • Remove temporary role assignments, group membership, mailbox delegation, firewall exceptions, and Conditional Access exclusions.
   • Disable or delete dedicated migration accounts when they are no longer required.
   • Revoke unused application consent and remove expired or unneeded certificates and secrets. Delete the app registration or service principal only after confirming that no ongoing migration or coexistence task depends on it.
   • Validate Full Access, Send As, Send on Behalf, folder, calendar, shared mailbox, and public folder permissions according to the migrated workload.
   • Confirm retention, holds, sensitivity labels, DLP, audit settings, and eDiscovery requirements in the target. These controls should be validated separately rather than assumed from successful mailbox data movement.
   • Securely remove temporary exports and mapping files according to the documented retention schedule.

   Record exceptions that must remain after migration, including their business owner, approved scope, review date, and removal plan.

Common security risks during Office 365 migration

Office 365 migration security checklist

Before migration

• Approve the workload scope, migration window, administrators, and application identities.
• Baseline roles, app consent, mailbox permissions, Conditional Access, retention, and audit access.
• Use named migration administrators with MFA and task-based least privilege.
• Secure application credentials and record their owner, expiry, and removal plan.
• Patch and protect the migration host; restrict local and remote access.
• Verify required endpoints, proxy behavior, TLS inspection, and firewall configuration.
• Confirm report, staging-data, and support-log handling requirements.

During migration

• Monitor sign-ins, role changes, application consent, security alerts, and EdbMails job reports.
• Compare migrated mailboxes and workloads with the approved batch plan.
• Restrict report access and use approved channels for support files.
• Investigate unexpected sign-ins, permission changes, or migration volume before continuing.
• Document temporary exceptions and keep their expiry dates visible.

After migration

• Validate mailbox access, delegation, security controls, compliance settings, and auditing.
• Remove temporary roles, accounts, application credentials, consent, and network exceptions.
• Delete temporary exports and mapping files according to the retention plan.
• Archive the required reports, approvals, exceptions, and validation evidence.
• Assign an owner and review date to any access that must remain.

Conclusion

A secure Office 365 migration depends on disciplined identity management, controlled application access, protected migration hosts, useful audit evidence, and prompt cleanup. The migration team should be able to explain who had access, why it was required, what activity occurred, and when that access was removed. Treat these controls as part of the migration acceptance criteria rather than a separate task completed after cutover.

---

Additional resources:

• Office 365 migration best practices
• Office 365 migration checklist
• Office 365 migration FAQ
• Office 365 migration challenges and how to avoid them
• Validate mailbox permissions after migration