Blast radius is a term borrowed from incident response — the maximum impact of a given failure. In M&A IT integration, blast radius analysis maps what breaks when you change an infrastructure component, and who it affects.
In practice, most integration teams don’t do blast radius analysis. They react to failures after they happen. This is expensive.
The Three Integration Scenarios Where Blast Radius Matters Most
Scenario 1: AD Forest Migration
The change: Migrating user accounts from SourceForest to TargetForest.
The blast radius if done wrong:
- All service accounts using source forest SPNs stop authenticating
- All applications using integrated Windows authentication against the source domain fail
- All VPN configurations referencing source domain credentials fail
- All SharePoint farms using source domain for authentication return 401 errors
- All SQL Server connections using domain service accounts time out
The blast radius if done right: A carefully sequenced migration where each application dependency is verified before the migration wave executes.
ACQI’s contribution: Maps all AD dependencies for all discovered service accounts. Ranks them by blast radius (how many users does this affect, how many applications does this touch, how business-critical is the system). Produces a migration sequence that is safe-by-default.
Scenario 2: M365 Tenant Consolidation
The change: Consolidating two M365 tenants into one (or migrating all users from target tenant to acquirer tenant).
The blast radius if done wrong:
- All Teams meeting recordings stored in the target tenant’s SharePoint become inaccessible
- All OneDrive URLs change (from company-my.sharepoint.com to company.sharepoint.com), breaking all embedded links in documents and emails
- All Power Automate workflows using target tenant connectors fail
- All Power Apps using target tenant data sources break
- All third-party SaaS apps using OAuth tokens from the target tenant require re-authorization
ACQI’s contribution: Identifies all M365 workloads, their interdependencies, and the number of external sharing links that will break. Produces a URL redirect map and a third-party app re-authorization checklist.
Scenario 3: Azure Subscription Merge
The change: Moving resources from the target’s Azure subscription to the acquirer’s subscription (or to a new consolidated subscription).
The blast radius if done wrong:
- All VM network interfaces retain their old NSG rules, which reference the old subscription’s VNet
- All Key Vault access policies referencing the old subscription’s service principals break
- All Automation Runbooks using credentials from the old subscription’s Key Vault fail
- All Application Insights instances tracking resources in the old subscription lose data continuity
The 3-Step Blast Radius Methodology
Step 1: Dependency Mapping
For each infrastructure component that will be touched by the integration, document:
- What other components depend on it?
- What service accounts does it use, and what do those service accounts touch?
- What are the upstream dependencies (what must be working for this to work)?
- Who are the users / how many users are affected if this fails?
ACQI runs this as an automated module. The output is a dependency graph with each node weighted by blast radius.
Step 2: Risk Scoring
Score each integration touchpoint by:
Business Impact (1-5): How critical is this system to daily operations?
- 1 = Non-critical, cosmetic if down
- 3 = Significant business impact within 24 hours
- 5 = Operations halt within 1 hour
Change Complexity (1-5): How many dependencies does this change have?
- 1 = Standalone, minimal dependencies
- 3 = Moderate dependencies on other systems
- 5 = Highly interconnected, many dependencies
Rollback Difficulty (1-5): How hard is it to reverse this change?
- 1 = Trivial rollback, no user impact
- 3 = Moderate rollback effort, 2-4 hour window needed
- 5 = Cannot easily rollback without significant user impact
Risk Score = Business Impact × Change Complexity × Rollback Difficulty
High-risk integration touchpoints (score > 50) require a full rollback test before the migration window.
Step 3: Sequencing
Integrate in dependency order: migrate the providers before the consumers. The rule is simple:
- Migrate or consolidate the identity store first (AD, Azure AD)
- Migrate the network infrastructure (VPN, DNS, certificate authorities)
- Migrate data and application dependencies from most-independent to most-dependent
- Migrate user-facing tools last (end-user workstations, collaboration tools)
Blast Radius Scoring Example: AD Forest Migration
A company with 3,000 users, 180 applications, and 12 major systems. ACQI’s blast radius analysis identifies:
| System | Business Impact | Change Complexity | Rollback Difficulty | Risk Score |
|---|---|---|---|---|
| Domain Controllers | 5 | 5 | 5 | 125 — Cannot proceed without full rollback test |
| DNS Infrastructure | 4 | 4 | 4 | 64 — High risk, requires separate migration window |
| M365 Identity (Azure AD Connect) | 4 | 3 | 3 | 36 — High risk, coordinate with M365 tenant plan |
| File/Print Servers | 3 | 2 | 2 | 12 — Medium risk, migrate in wave 2 |
| Line-of-Business App (ERP) | 5 | 2 | 3 | 30 — High business impact, but contained dependency |
| End-User Workstations | 3 | 1 | 1 | 3 — Low risk, can be done in large batches |
The Domain Controllers can’t be touched until the rollback test is complete and verified. DNS has to be moved before the domain controllers. The ERP can be migrated independently once identity is stable.
That’s the integration sequence. Without the blast radius analysis, most teams start at the wrong end and spend the first week reversing decisions they made on Day 1.