An enterprise consolidates nine departmental systems that all implement the same capability into one platform. Which risk materialises first and does most damage to the programme?

The deciding property

Every one of the nine systems encodes a set of local exceptions: a department that approves differently, a region with an extra field, a legacy contract with a bespoke rule. None of them is in any requirements document; all of them are in production and someone depends on each.

When the programme starts, the target is "one system replacing nine". When the programme discovers exceptions, the target silently becomes "one system implementing the union of nine behaviours" - which is strictly more complex than any of the nine, costs more to build than the sum of what it replaces, and is why the consolidated platform so often ships late and is then itself hard to change.

This risk arrives first because it arrives during requirements, before any code, and it compounds for the rest of the programme.

Why the other options fail

• "Cannot handle the combined load." The combined load of nine departmental systems is nearly always trivial for a modern platform, and this is the risk teams size carefully because it is the one they know how to size. It rarely bites.
• "Data migration takes longer than planned." True and expensive, but it lands after the requirements problem and is usually a schedule risk rather than a scope risk. It also has a well-understood playbook: profile, map, reconcile, run in parallel, cut over.
• "Users resist the new interface." Real, and the standard explanation offered afterwards. But adoption resistance is usually a symptom of the first risk handled badly: users resist when the new system cannot do the specific thing their old one did, not because the buttons moved.

What makes it survivable

• Decide the exception policy before the design, in writing, with an executive owner: which exceptions migrate, which are dropped, and who is allowed to say no to a department. A programme without a named person who can refuse a requirement will implement all of them.
• Count the exceptions early. Read the nine codebases for conditionals on department, region or customer type. The count is the programme's real size estimate, and it is available in week two.
• Retire before you consolidate. Every system switched off before the build is one whose exceptions never enter the target. Sequencing the easiest retirements first shrinks the requirement set and demonstrates progress.
• Keep one escape hatch, such as a configurable rule table, so genuine exceptions do not become code branches. Then govern what enters it.

When consolidation is the wrong answer at all

When the nine systems genuinely serve nine different businesses with different regulators or different customers. Similar capability is not the same as the same capability, and a consolidation justified purely on the observation that nine teams do "user management" will produce a platform that serves none of them well.