Domain and identity dependencies
Map custom domains, hybrid identity components, and any federation or B2B relationships the current tenant maintains.
Independent IT security review
Know what the tenant depends on before the project plan is written.
A tenant-to-tenant merger, a domain migration, or an office move that touches network and identity all rest on assumptions about the current tenant. This review replaces the assumptions with evidence before the migration plan is built.
- Before any access
- Written question and scope
- Agreed evidence method
- No automatic tenant changes
Inventory what the current tenant actually depends on.
A migration project plan is only as good as its dependency map. The review establishes what identity, licensing, and applications the organization actually relies on before anyone commits to a cutover date.
Licensing and SKU inventory
Confirm which licences are actually assigned and in active use, since a migration is the wrong time to discover unexplained licence sprawl.
Application and automation dependencies
Identify connected applications, service accounts, and automations that authenticate against the tenant and would break silently on cutover.
Separate cutover-risk findings from pre-existing security findings.
A pre-migration review surfaces two different kinds of finding: what will break during cutover, and what was already a risk before the project started. They need different owners and different timing.
Cutover-risk findings
Flag dependencies that a project timeline must account for-mail routing, DNS records, or an application that only trusts the current domain.
Pre-existing configuration risk
Separate out findings-stale guest access, unowned privileged roles-that exist regardless of the migration and deserve their own disposition.
Owner assignment before the plan
Assign each finding to either the migration project team or tenant leadership before the project plan is finalized, so nothing falls between the two.
Read the review as evidence for the plan, not the plan itself.
This review gives a migration project team facts to plan from. It does not design the migration, execute the cutover, or replace the implementer’s own runbook.
What this review provides
A dependency map and a risk register connected to the current tenant, written so a project team can plan around it.
What it does not provide
Migration execution, a cutover runbook, or DNS and mail-routing changes-these belong to the migration implementer, not this review.
Handoff to the implementer
Structure the findings so they can be handed to whoever executes the migration without requiring them to re-discover the same dependencies.
Time the review before commitments are made, not after.
The review is most useful before a vendor is selected, a cutover date is announced, or a network change is scheduled-while findings can still change the plan instead of only explaining what went wrong.
Before vendor selection
Use the dependency map to ask a prospective migration vendor more specific, harder-to-dodge questions.
Before a cutover date is committed
Surface dependencies early enough that a realistic cutover window can be set instead of discovered midway through the project.
Before an office-move network cutover
Where a physical move touches network trust or hybrid identity infrastructure, connect that project to the same evidence base as a tenant migration.
Next step
Define the review before sharing evidence.
Start with the trigger, decision, and known boundaries. Do not send passwords, recovery codes, or tenant exports.