“Mergers are like marriages.”

 - Simon Sinek

After a merger, the biggest mistake is trying to fix everything at once. The right approach is to first keep the business running, then reduce risk, and only then standardize and optimize the environment.

At the beginning, the priority is continuity. Users need to keep working, and critical services must remain available. That means quickly identifying which systems are business-critical, which integrations depend on identity, network access, or secrets, and what could break once domains, tenants, or permissions start changing.

This phase is not about optimization. It is about minimizing disruption and making sure IT does not slow down the merger itself.

The next step is to clean up access control. After a merger, environments usually become messy very quickly: overprivileged accounts, stale admin users, unused PATs, unnecessary service connections, and unclear ownership.

We should immediately focus on:

• reviewing privileged roles,
• enforcing MFA and Conditional Access for admin accounts,
• restricting access to projects and repositories,
• inventorying technical accounts, secrets, and service connections,
• removing anything that is not required for operations.

Secure the integrations

In post-merger environments, integrations often create more problems than the applications themselves. This is especially true for Azure DevOps, pipelines, agents, deployments, and connections to Azure or other tenants.

The key questions are:

• Who can create or modify service connections?
• Are pipelines using short-lived federation instead of static secrets?
• Are agent pools shared or separated appropriately?
• Is network traffic restricted to approved addresses and services?
• Are logs and audit trails in place for all critical changes?

If these areas are not controlled early, the merger quickly turns into both an operational and security risk.

Decide the target model

Once the environment is stable, the next decision is the target operating model. The worst option is to keep two partially connected environments alive for years, because that creates cost, duplication, and unclear responsibility.

At this stage, the company should answer three questions:

• Are we consolidating into one organization or one tenant?
• What needs to stay separated temporarily?
• What standards will apply to new projects, pipelines, and access control?

This is the point where the team should define one way of working, instead of simply moving old problems into a new structure.

Standardize and automate

Only after stabilization does it make sense to fully standardize. That is the time to clean up naming, policies, pipeline templates, monitoring, reporting, and automation.

We should focus on:

• infrastructure as code,
• automated access reviews,
• regular detection of stale accounts and secrets,
• standardized agents and release processes,
• change control through pipelines instead of manual operations.

This reduces technical debt and ensures the post-merger environment is not only functional, but also manageable in the long term.