Reducing Concentration Without Breaking Services

Reducing concentration means lowering the extent to which important services would fail together, without breaking the services in the process of changing them. That balance is the central challenge. Moving a service to a new provider, splitting it across providers, or changing its platform can reduce dependence, but each change introduces its own risks: migration errors, data loss, staff unfamiliarity, and new dependencies that are not yet understood. A reduction programme that ignores those transition risks may replace a known concentration with an unknown one.

The work therefore starts with prioritisation. Not every concentration needs the same response, and not every response needs to happen at once. The most important concentrations, those affecting the most critical services or the widest set of services, deserve attention first. Less critical concentrations may be accepted, monitored, and revisited later. That judgement, made openly and recorded, is more useful than a blanket aim to diversify everything, which is rarely achievable and can distract from the risks that matter most.

Splitting a service can mean dividing it between providers, so that no single provider supports the whole service, or dividing customers, regions, or functions between providers, so that a failure affects only part of the service. It can also mean keeping a primary provider while building a secondary route for the most critical functions, so that an alternative exists even if it cannot carry the full load. The choice depends on the service.

Splitting is not free of risk. Two providers mean two relationships to manage, two sets of contracts, two monitoring arrangements, and potentially two different ways of handling data and incidents. A split should therefore be checked against the dependency map: does it genuinely reduce shared dependencies, or does it only increase the number of contracts.

Exit planning matters because it tests whether a concentration is reversible. A firm that cannot describe how it would leave a provider, move its data, and transition to an alternative or to an in-house arrangement, is more concentrated in practice than a firm that can, even if their current supplier lists look identical. Exit planning forces questions about data portability, about the availability of alternatives, about the skills needed to run a transition, and about the time a transition would realistically take.

Those questions are valuable even if an exit never happens. They reveal where a provider holds leverage, where data is locked in, and where the firm lacks the knowledge to operate without the provider. They also inform contract negotiations, because a firm that understands its exit options can seek protections that preserve them, such as data return arrangements and cooperation duties. Exit planning is therefore a resilience tool, not only a procurement tool, and it belongs in concentration work even for providers the firm expects to keep.

Consider an illustrative firm that wants to reduce dependence on one payments provider. Rather than moving all payments at once, it might first build a secondary route for a subset of payments, test that route under realistic conditions, and train staff to operate it. It might then move a portion of traffic to the secondary route, observe performance, and only then consider a wider split. At each stage, the firm can compare the new route with the old, and can revert if problems emerge.

That staged approach illustrates the principle of reducing concentration without breaking services. The firm gains a genuine alternative, learns how it behaves, and reduces the share of payments that depend on one provider, while keeping the primary route available throughout. A sudden, complete migration, by contrast, would concentrate risk in the transition itself, and any error would affect all payments at once. Staging trades speed for safety, and for an important service that trade is usually worth making.

Reduction can create new risks that need to be managed. A new provider brings its own dependencies, its own security practices, and its own incident history, which the firm needs to assess. A new platform brings migration and integration risks. A split service brings coordination risks, where two providers must work together during an incident and may have different procedures or priorities. Those risks do not make reduction wrong, but they mean reduction should be treated as a risk decision, with its own assessment, rather than as an automatic good.

Complexity is a particular new risk. A firm that spreads a service across many providers may find it harder to monitor, to test, and to respond coherently during an incident. Staff may need to understand several systems, and incident communication may need to coordinate several suppliers. Where complexity grows faster than the firm's ability to manage it, the net resilience may fall even as the supplier count rises. That is why reduction should be targeted, not maximal.