Why adding more SAP consultants will not save your migration

In 1975, Fred Brooks published a line that software engineers have been quoting ever since: adding manpower to a late software project makes it later. Fifty years on, SAP migrations prove him right with depressing regularity.

The staffing reflex

An S/4HANA migration falls behind schedule. The steering committee meets. The recommendation is always the same: bring in more consultants.

It makes intuitive sense. More people, more throughput. But Brooks showed why this fails. Every new person needs to be onboarded. They need context on the landscape, the custom code, the integrations, the decisions already made. The people who have that context stop building and start explaining. Communication overhead grows faster than capacity. The project gets later, not earlier.

This is not a theory. SAPinsider's benchmark research shows typical S/4HANA projects spend 70 percent of their budget on custom code, run two to four years, and experience three times their original cost estimate. The response is almost always more staff. The result is almost always more cost, not faster delivery.

The real bottleneck

The bottleneck in a late SAP migration is almost never capacity. It is clarity.

Teams do not know which custom objects are business-critical and which are dead weight. They do not know which Z-programs are actively used and which were written for a one-off requirement in 2014. They do not know where the real migration risk sits until they are already mid-build and something breaks.

Without that understanding, every new consultant is guessing. They are reading code they did not write, for a business they do not know, in a system that was configured by people who left years ago. They are not slow because they are bad at their jobs. They are slow because they are working blind.

What clarity actually looks like

Before you staff up, you need answers to a short list of questions:

• Which custom objects are actively used? Not which exist, but which ones the business actually relies on today.
• What do they do? Not the technical description, but the business purpose. Why was this built?
• What breaks if you remove or change them? Which objects depend on which, and what is the blast radius of a change?
• Where is the risk concentrated? Which process areas have the most custom complexity, the most integration points, the most variants?

With those answers, you know where to focus. You know what to retire, what to refactor, and what to leave alone. You can staff the right areas with the right people instead of flooding the project with bodies and hoping coverage improves.

Without them, you are adding headcount to a problem that headcount cannot solve.

Intelligence before headcount

This is the principle we built C16 around. Before you staff up, understand what you have. Read the system. Surface the custom code, the usage data, the dependencies, and the business purpose. Do it with AI that reads your live SAP, read-only, and gives your team a clear picture of the landscape before the first consultant writes a line of code.

It does not replace your team. It makes your team effective from day one instead of month three.

Brooks was right in 1975. The answer to a late project is not more people. It is more understanding. In SAP, that understanding is sitting in the system. You just need a way to read it.

See what is in your system. C16 reads your SAP landscape and shows you where the complexity, risk and opportunity sit, before you staff the project. Book a walkthrough to see it on a live system.