Maynor in the Cloud / Beyond the Tenant
When the forest decision is really about the control boundary and operating model.
When two organizations are combining, the Active Directory question often gets framed too simply:
That sounds like an infrastructure decision.
It is not.
The real decision is which control boundary and operating model the combined organization is prepared to secure, support, migrate into, and own long term.
The forest is only one part of the decision.
Start With the Control Boundary
Before deciding where users should move, I want to understand what the target environment is expected to control and who is expected to operate it.
That includes more than directory objects.
It includes authentication, administration, namespace, application access, Azure relationships, Microsoft 365 workloads, support ownership, and the procedures around all of them.
The root requirement is not build a new forest.
And it is not merge into the existing forest.
The root requirement is to establish a durable control boundary and operating model that supports the combined organization while preserving application access, security boundaries, user continuity, and a supportable end state.
Existing Forest Usually Means Lower Migration Complexity
From a migration and coexistence perspective, consolidating into one existing environment carries lower complexity and lower transition risk because one organization remains largely unchanged while the other is moved into it.
That reduces the number of identities, applications, workloads, devices, and operational processes that have to change at the same time.
The reviewed design reflected that advantage: consolidation required fewer target environments and less reconstruction than moving both organizations into a third environment.
That does not mean the existing environment is automatically the right target.
It may still carry Kerberos-related concerns, technical debt, security gaps, or governance practices that the combined organization should not inherit.
The real decision gate is whether the existing environment can support the combined organization’s operating, security, and governance framework.
If it can, consolidation generally gives you the lower-complexity path.
If it cannot, the migration advantage is not enough to justify making it the target.
Greenfield Does Not Automatically Mean Cleaner
The opposite assumption is just as dangerous.
A new forest can look attractive because it creates a fresh boundary.
That can be valuable.
But a clean target does not create a clean migration.
In the reviewed greenfield design, the new-forest option created substantially more migration work. Application testing increased. Azure identity and access relationships had to be reconstructed. Group Policy required validation. Microsoft 365 workloads still had to move. Users experienced broader identity and access changes.
If you start with two independent forests and two independent Microsoft 365 tenants, a net-new design can temporarily create a third forest and a third tenant.
The two legacy environments do not disappear when the new environment is created.
They still have to operate. They still have to support users. They still have to maintain application access. And the new environment now has to interoperate with them while migration is underway.
So greenfield can add another layer of coexistence and interoperability before it eventually reduces complexity.
That may still be the right decision.
But the organization has to be willing to carry that burden during transition.
Applications Often Decide the Sequence
Applications are usually where the forest decision becomes real.
The reviewed environment included dependencies on SID-based authorization, group scope, forest-local administrative models, Kerberos, NTLM, legacy authentication, and cross-forest access.
That means application readiness can dictate migration sequence even after the target forest has already been selected.
A user account can be technically ready to move while the application that user depends on is not.
If the application still expects the old SID, group structure, authentication path, or forest-local account, then identity migration cannot be treated as an isolated directory task.
The application owner has to validate the new path.
The directory team cannot do that on their behalf.
Coexistence Is an Architecture
Temporary coexistence is often treated like an unfortunate delay between current state and target state.
I would treat it as its own architecture.
The reviewed design included forest trust, DNS conditional forwarding, cross-forest authorization, synchronization, mail coexistence, staged source-of-authority changes, and application validation across environments.
Each of those has an owner, a dependency, and a failure mode.
A forest trust can support cross-forest authentication and authorization.
It does not discover every application that depends on it. It does not fix DNS. It does not resolve routing. And it does not tell support teams where a change should be made.
The same applies to DNS conditional forwarding. It solves name resolution, but it does not prove application access or trust health.
Coexistence therefore needs to be designed deliberately.
And it needs an exit condition.
Reversibility Changes the Standard for Cutover
The reviewed migration also included account and mailbox transitions where there was no practical rollback once identity state had changed.
That matters because the less reversible the change is, the stronger the validation gate needs to be.
That means test accounts, application-owner validation, DNS testing, migration-log review, staged waves, and production validation after migration.
The same principle applies to cleanup.
Trust-removal planning used firewall and domain-controller logs to identify dependencies, but logging could not guarantee discovery of every trust-dependent application.
Telemetry can improve confidence.
It does not eliminate uncertainty.
M&A Target-State Decision Matrix
I would not use a generic pros-and-cons table for this decision.
I would force the architecture team to compare the options against the things that actually change the outcome.
| Decision area | Existing forest | New forest | Temporary coexistence | Extended / permanent separation |
|---|---|---|---|---|
| Control boundary and operating ownership | Can become the common control boundary if accepted | Creates a new control boundary and operating model | Control and ownership are divided by phase and must be explicit | Requires an intentionally divided operating model while multiple environments remain active |
| Security boundary | Inherits existing control history and technical debt | Creates a new boundary that still has to be secured and proven | Trust extends authentication across boundaries temporarily | Separate forest boundaries remain |
| Application dependencies | May reduce some identity changes where apps already align | In the reviewed design, created more identity and access reconstruction | Supports staged application movement | REQUIRES VERIFICATION: some applications may force extended coexistence |
| DNS / trust | Transitional dependency | Transitional dependency | Core coexistence dependency | Required where cross-forest access remains |
| Microsoft 365 | Fewer target environments if an existing tenant remains the destination | May introduce another tenant and additional workload migration | Workloads can move independently of AD | Separate tenants may remain until workloads are moved or intentionally retained |
| User impact | Lower relative change in the reviewed design, but still material | Broader identity, application, and workload change in the reviewed design | User experience may differ by migration wave | Depends on which users and workloads remain in legacy environments |
| Operations | Existing platform team becomes target owner | New operating model must be created while legacy models continue | Multiple teams must coordinate support and escalation | Temporary dual operational ownership is required while multiple environments remain active |
| Technical debt | Existing weaknesses must be accepted or remediated | Avoids some inherited infrastructure debt, but does not eliminate governance or process debt | Both environments continue to carry existing debt | Legacy environments continue to carry their existing configuration and operational debt unless deliberately remediated |
| Cleanup | Source dependencies must eventually be retired | Both predecessor environments still require cleanup | Trusts, forwarding, aliases, sync, and exceptions require exit criteria | Cleanup may be deferred or reduced, but duplicated operational responsibility remains |
The evidence supports these decision areas.
It does not support a universal scoring model.
I would not assign arbitrary numbers and pretend the answer is mathematical.
The weighting has to come from the organization’s actual constraints: business objective, legal or regulatory requirements, application criticality, timeline, budget, support capacity, user-impact tolerance, and cleanup funding.
What I Would Validate Before Making the Decision
- What is the business objective?
- Can the existing environment support the combined operating model?
- Can it meet the combined security requirements?
- Can it meet the combined governance requirements?
- Is there a legal, regulatory, or security reason the environments must remain separate?
- What technical debt would be inherited?
- Which applications depend on legacy identity or authorization patterns?
- What Microsoft 365 workloads still have to migrate regardless of the forest decision?
- How long will coexistence need to exist?
- Which changes are difficult to reverse?
- Who owns each dependency before, during, and after migration?
- What is the exit plan for every temporary dependency?
If those answers are weak, I am not ready to recommend the target state.
The Architectural Judgment
From a migration and coexistence perspective, consolidating into one existing environment generally carries lower complexity and lower transition risk because one organization remains largely unchanged.
But that advantage only matters if the target environment can support the combined organization’s operating, security, and governance framework.
If it can, consolidation is usually the lower-complexity path because only one side of the environment has to make the major transition.
If it cannot meet those requirements without unacceptable debt or control gaps, then greenfield may be justified despite the additional migration and coexistence burden.
And if multiple environments have to operate together for a period of time, coexistence should be treated as an architecture state of its own — with owners, controls, residual risk, and an exit plan.
