The bottom line
A multi-year S/4HANA migration forces a resourcing choice: split your best internal experts across legacy support and the new build, or outsource the whole transformation and sideline the people who understand the business.
A field note for leaders who have to keep the current ERP running flawlessly while a multi-year S/4HANA program consumes the calendar.
The views below are my own, drawn from patterns I have watched play out across large ERP transformation programs. They are offered as one practitioner's framework, not a prescription, and reasonable people will resource these programs differently.
The dilemma nobody schedules for
The ERP is the operational nervous system of the enterprise. It clears orders, moves inventory, and closes the books. When it stutters, the business slows; when it stops, the business stops. So it gets treated as a strategic asset — right up until the day a replacement program kicks off, and the organization's attention, money, and best people pivot toward the future state.
That pivot is understandable. It is also where the risk lives. An S/4HANA migration commonly runs three to five years or more, and for the entire duration the legacy estate is still the system the business actually depends on. The future gets the spotlight; the present keeps the lights on with whatever attention is left over.
Two bad options, dressed up as a choice
When a CIO sits down to resource a large ERP transformation, the default menu offers two paths, and both quietly degrade the program.
Split the internal team across both jobs. The same engineers who hold the institutional knowledge are asked to design the new platform and keep the old one alive at the same time. In practice this produces divided attention, burnout, and a higher error rate on both fronts. The transformation slows to a crawl while operational stability erodes — the worst of both outcomes.
Hand the whole transformation to an outside firm. Bring in an external team to own the migration end to end. New capability arrives, but the people who understand why the business works the way it does get sidelined. The result is often technically clean and operationally wrong: a platform that passes its tests and fails to fit the business, with adoption and ownership problems that surface long after go-live.
Each path puts the program's return at risk. The resource allocation question is not a staffing detail to settle later — it is the central design decision that determines whether the transformation succeeds.
A model that resolves the tension: ring-fencing
The more durable approach inverts the default. Consider a global mid-market medical-device manufacturer running a family of more than thirty brands across multiple regions. As it began its own multi-year move to S/4HANA, it confronted the resourcing dilemma directly and chose neither of the two default paths.
Its leadership made two judgments at once. First, the internal IT team was indispensable to the new platform — not as technical labor, but as the holders of the company's process logic, data structures, and operational context. Pulling them in was non-negotiable. Second, pulling them off legacy support entirely was not viable, because the existing estate still ran the business and needed expert hands every day.
The resolution was to ring-fence the core internal experts. Rather than dividing their attention or surrendering it, the company drew a hard line around them and built the program on two sides of that line.
- A dedicated transformation team. The engineers with the deepest institutional and business knowledge were formally pulled out and designated as the S/4HANA core team — and protected from day-to-day operational demands.
- A clear strategic mandate. Their job was to lead the implementation from the inside: shape the system design, translate business requirements for the implementation partner, own the data-migration strategy, and drive user acceptance and change management. Business partners and program leaders, not ticket-takers.
- Legacy support placed with a specialist partner. A third-party provider took full responsibility for the legacy applications and infrastructure, so the internal team could face forward without being dragged back into the present.
Ring-fencing is a structural decision, not a task list. It frees the most valuable internal capability to work on the most important initiative, while a partner holds the floor steady underneath the program.
Why the two-sided structure works
The strength of the model is that each side does only what it is best positioned to do, and the seam between them is explicit.
The internal team, freed from routine support, operates at a higher altitude. It becomes the bridge between business stakeholders and the technical build, so the new platform is configured to the operation rather than to a generic template. It carries years of accumulated process logic into the new system instead of letting that knowledge evaporate in the handoff. And because it led the design, it is positioned to own the platform after go-live and champion adoption — the part external teams structurally cannot do.
The support partner, meanwhile, is the steward of the present. Its mandate is continuity: keep the legacy applications and infrastructure running without service degradation, apply automation and operating discipline to the existing environment, and provide the stable base from which the transformation can launch with confidence. Done well, the legacy environment often gets quieter and more reliable during the program, not less.
A clean division of labor removes the two failure modes that sink large programs — resource contention and divided focus — and lets each team excel inside its lane.
How to structure this on your own program
The pattern is replicable. It is not a universal answer, but the principles travel well to any organization staring down a large ERP modernization.
- Name the resource dilemma as a primary risk. Your internal experts cannot run the legacy estate and lead a full-scale transformation at the same time. Put that on the risk register on day one, not after the first slipped milestone.
- Treat internal IT as strategic, not as capacity. The people who know why the business works the way it does belong at the front of the program, guiding the build — not absorbed into keep-the-lights-on work that anyone could be trained to do.
- Ring-fence the core team formally. Protect them from operational pull with an explicit mandate to work only on the future state. Informal protection does not survive the first production incident.
- Use a support partner for stability, not just savings. Engaging a specialist for legacy support is a continuity decision before it is a cost decision. The point is to buy your internal team the freedom to focus.
- Make the seam explicit. Define exactly where the internal team's responsibility ends and the partner's begins, and communicate it. Ambiguity at the boundary is where accountability disappears.
Adopt this resourcing model and the trade-off stops being a trade-off. You get the upside of the transformation without surrendering the operational stability the business needs while the program runs — which is the whole point of de-risking the journey to S/4HANA.
The economic angle leaders should not miss
There is a cost dimension to ring-fencing that is easy to overlook. The legacy environment a partner takes over is, almost by definition, full of repeatable work — the same incidents, the same batch jobs, the same month-end firefights, quarter after quarter. The right partner does not just hold that line at a flat fee; it studies the repeat work and automates it down over the life of the engagement, so the effort of keeping the legacy estate running is visible and reviewed. That matters for a program that may run five years, because the support layer is no longer a static line item — it is a cost that should shrink while the transformation absorbs the budget that matters.
That is the difference between renting stability and engineering it. One holds the floor; the other lowers the cost of the floor every year you stand on it.
Analysis by Ravi Madhavan. Originally published on LinkedIn. Allari runs the ERP production support layer for JDE, SAP, Oracle Fusion, and NetSuite estates — the steady-state side of exactly this kind of ring-fence — measuring the repeatable work in a legacy environment and finding where it can be automated.
