How Sprawl Happens: M&A, Shadow IT, and Organic Growth

Overview

No CIO ever sat down and decided to build a technology landscape with forty-seven overlapping systems, three conflicting sources of truth for customer data, and integration spaghetti that nobody fully understands. Sprawl is not a decision. It is the accumulated outcome of thousands of reasonable decisions made over time by people who were solving immediate problems without full visibility into the larger picture.

Understanding how sprawl happens is the first step to understanding why it is so hard to fix — and what it costs.

Mergers and Acquisitions

The most dramatic source of IT sprawl is mergers and acquisitions. When one company acquires another, it inherits that company's technology landscape in its entirety. Not just the systems the acquired company was planning to keep — everything. The ERP system they were in the middle of replacing. The custom application that one department built fifteen years ago. The data warehouse that was never quite finished. The SaaS tools that fourteen different teams signed up for independently.

In theory, post-merger integration involves consolidating the two technology landscapes into one. In practice, this consolidation is expensive, time-consuming, and highly disruptive. The systems being consolidated are often deeply integrated with business processes that cannot be interrupted. The people who understand the acquired company's systems may leave after the acquisition. The timeline for integration is usually longer than expected and the budget is usually tighter than needed.

The result is that most organizations that have gone through multiple acquisitions are running systems from multiple eras and multiple companies, at various stages of integration. Some are fully consolidated. Some are running in parallel. Some are connected by integrations built quickly during the merger period that nobody has had time to stabilize. Others are running independently, with data synchronized manually or not at all.

A global organization that has done twenty acquisitions over twenty years may be running five different ERP instances, three different HR systems, and customer data spread across four different CRMs. Each was inherited from a different acquisition, at different stages of a consolidation plan that has been deprioritized every year in favor of more urgent work.

Shadow IT

As discussed in the chapter on SaaS sprawl, shadow IT is technology that is in use within the organization but is not managed by IT. It grows whenever official systems fail to meet the needs of the people doing the work.

The mechanisms are predictable. A team needs a capability that IT says it will deliver in eighteen months. The team finds a SaaS tool that does most of what they need and signs up. A manager needs to produce a report that the official reporting system cannot generate, so they build it in Excel. A department needs to share files with an external partner, but the official file sharing system has access control limitations that would take weeks to sort out through IT, so they use a personal file sharing service.

Each individual decision is reasonable. The cumulative effect is a shadow technology landscape that IT does not fully know about, does not manage, and cannot control. When the organization needs to understand its data landscape for an AI initiative, shadow IT is often the biggest source of surprises. Valuable data exists in unofficial systems that nobody cataloged.

Organic Team-Level Growth

The third mechanism is quieter than M&A and harder to see than shadow IT. It is the simple organic growth of technology at the team or department level over time.

A team starts with a need. They find a tool. The tool works, so they use more of it. They add a second tool that integrates with the first. A new team member joins and brings a tool from their previous job. Over five years, a team of ten people has built a micro-ecosystem of eight tools. Four are redundant with tools elsewhere in the organization. Two are critical to daily operations. None was ever reviewed by IT security.

Multiply this across every team in a large organization and you have organic sprawl at scale. No single decision was wrong. The aggregate outcome is a landscape that is difficult to manage, expensive to maintain, and nearly impossible to fully document.

Why Sprawl Persists

The reason sprawl is so hard to address is that the cost of cleaning it up is always immediate and concrete. The benefit of having a cleaner landscape is diffuse and hard to quantify.

Consolidating two CRM systems requires a migration project: time, money, disruption, risk of data loss, and organizational change management to get people using the new system. The benefit is real, less duplication, cleaner data, reduced maintenance cost, but it is spread across many future projects and hard to attribute directly to the consolidation effort.

Leadership consistently prioritizes new capabilities over landscape rationalization. Every year, there is something more urgent than cleaning up the technology portfolio. The rationalization project gets deferred, the sprawl continues, and the cost of addressing it grows.

What Sprawl Costs

The cost of IT sprawl is distributed and largely invisible. It shows up in a few ways.

License costs. Organizations frequently pay for software they are not using, or pay multiple times for software that does the same thing. IT asset management audits regularly find significant savings from decommissioning redundant tools.

Integration maintenance. Every connection between two systems requires maintenance. More systems mean more connections. More connections mean more maintenance burden.

Data quality degradation. Data that is spread across many systems and synchronized through fragile integrations drifts out of consistency over time. The more systems hold the same data, the harder it is to know which one is authoritative.

Project velocity. Every new initiative has to navigate the existing landscape. Understanding the dependencies, getting access to the right systems, and building integrations all take longer when the landscape is more complex. Sprawl is a tax on every project the organization tries to run.

For AI initiatives, this tax is particularly heavy. AI needs clean, consistent, well-understood data. Sprawl is the primary reason that data is often not clean, not consistent, and not well understood.