The app consolidation playbook

App consolidation needs authority to close products, not only a new platform. In programs I worked on, the first inventory always found more apps and codebases than expected, often serving the same customer needs.

The Real Cost of Digital Sprawl

The cost appears in repeated work. One market fixes a bug while the same bug remains in three other apps. Several teams build the same account, billing, or support journey, and customers still move between apps from the same company. Knowledge and maintenance also stay split across codebases. In one simple case, ten teams may each fix the same password-reset problem instead of fixing it once.

I would consolidate the overlapping products, but only after deciding which local differences still matter.

How Digital Sprawl Happens

The duplicate products usually come from several reasonable decisions made at different times.

Local autonomy comes first. Each country has different products, pricing, regulations, and customer expectations. Local teams want local solutions. "Our market is different" is a powerful argument, and often true.

Acquisitions add to it. When you buy a company, you inherit their digital products. Integrating them is expensive and risky. So you don't. You end up with parallel apps serving similar customers.

Product silos make it worse. The mobile team builds a mobile app. The broadband team builds a broadband app. The TV team builds a TV app. Each team optimizes for their domain. Nobody optimizes for the customer who has all three.

Different agencies may also build separate products for each contract. A new app can look faster than integrating with the existing platform, but the company then owns another codebase and its maintenance.

Leadership changes add another layer. A new leader may fund a replacement instead of improving the existing platform. After several cycles, the company has multiple partly adopted platforms without evidence that the older one failed.

The Consolidation Decision

The difficult part is closing a product that a team built and a stakeholder funded. Both have valid reasons to protect it, so the decision needs evidence and a clear owner.

Consolidation needs an executive owner who can decide which products will close and support the team when markets disagree. I've seen consolidation work when it had that backing, and watched it stall for years when it was treated as just another digital team project.

Without that owner, each sunset decision returns for another approval and local teams keep their existing platforms.

The Three Questions

For every digital product in your portfolio, there are only three questions that matter: Does it need to exist separately? What do we lose by merging it? And what's the path to get users across? Everything else is noise.

1. Does this need to exist as a separate app?

Some digital products exist because they were built separately, not because they need to be separate. If a mobile customer and a broadband customer have the same core needs (check usage, pay bills, get support), they probably don't need different apps.

Other products exist because they serve different use cases. A consumer-facing retail app has different needs than an internal logistics platform. These might stay separate.

2. If we merge this, what do we lose?

Local customization matters. An identical app may miss local regulation, pricing, or customer needs. Decide which differences affect the customer outcome and keep those configurable.

Pricing, promotions, and campaigns? Keep them under local control. Core journeys like login, billing, and support? They can be standardized.

3. What's the migration path?

Closing an app with active users needs a migration plan. I would move users in stages, measure completion and support demand, then close the old app when the required journeys work.

Use feature parity as the gate: don't sunset the old app until the new one can do everything users actually need. That means what users actually use, which is a much shorter list than everything the old platform could do.

Migration also covers support training, call-centre scripts, marketing material, and every link to the old app. In programs I worked on, this coordination took more effort than the technical switch.

The Central/Local Model

I would use one core codebase with local configuration and integrations, not one identical app for every market.

The central team owns the core: architecture, UX patterns, main journeys, and the component library. They build once.

Local teams own the content: pricing displays, campaign configurations, local features, and market-specific integrations. They customize via CMS and configuration, not code.

This requires a clear contract. Local teams can't demand custom journeys that break the architecture. Central teams can't ignore local needs that affect adoption.

Local teams should describe the business outcome they need, such as reducing billing calls. The central team proposes a solution within the shared architecture, and the local team checks whether it works for that market.

The central process also needs a response time. If local teams wait too long, they will use third-party tools, iframes, or small local apps. That creates another layer of products outside the shared platform.

The API Abstraction Layer

The backend is usually the largest constraint. Markets may use different billing, CRM, and catalog systems, so replacing all of them as part of the app program adds cost and risk.

I would put a standard API contract between the app and each market's backend, as described in my article on the abstraction-layer approach.

The app doesn't know or care if Market A runs SAP and Market B runs Oracle. It calls the same API. Local teams implement that API against whatever backend they have.

Agreeing on that contract is the difficult part. The central product team should propose it, collect input from local teams, and make the final decision when agreement is not possible. Otherwise ten markets can keep the design open indefinitely.

What Gets Cut

Consolidation should also reduce the feature set. Use product data to identify which features customers still use, applying the same prioritization approach. Keep features that support the agreed customer outcome. Remove unused features and fix local workarounds at their source instead of copying them into the shared app.

Feature removal will be challenged, so the central team needs authority to decide and an executive owner to handle escalations.

The Timeline Reality

For the portfolio I worked on, the program took over three years. Eighteen months would not have covered the platform, migration, and local rollout.

The Results

The expected gain is less repeated work. A shared codebase allows one fix or feature to reach several markets, while new markets start with an existing product and integration contract. The program still needs to measure delivery time and maintenance cost to confirm that gain.

Name the decision owner

Architecture is not the main blocker. Someone must decide which app closes, which local feature stays, and when a migration is complete. That owner also needs to support the team when a market, agency, or product owner escalates the decision.

Start by naming that person. If nobody has authority to close an app, the consolidation program is not ready.