Fewer people than a systems integrator will propose, and different ones than a job specification usually lists.
Most conversion programmes are staffed by adding capacity. The more useful question is which capabilities you need to own, which you can rent, and which single role decides whether the rest of it works.
Why is conversion experience scarcer than it looks?
Why is conversion experience scarcer than it looks?
Because "S/4HANA experience" covers at least four different things, and only one of them is what you need.
Greenfield implementation. A new build on a clean system. Different problem, different skills, and considerably more common.
Brownfield conversion. Taking a live ECC system to S/4HANA with its history, its custom code and its data. This is the scarce one.
Selective data transition. A hybrid, with its own set of decisions about what carries over.
Upgrade. Moving between S/4HANA releases. Useful experience, not the same experience.
On a resume these look identical. All four produce the phrase "full lifecycle S/4HANA implementation", which appears on thousands of profiles and means something different on almost every one.
The distinction only emerges in conversation. Which conversions, how many, what did you own end to end, and what went wrong.
Which roles decide the outcome?
Four, in rough order of how much damage their absence causes.
Solution or enterprise architect with a live conversion behind them. The scarcest profile in the market and the one that decides the shape of everything else. They hold design authority, they arbitrate between what the business wants and what the platform should do, and they carry the consequences of both.
Data lead. Migration, master data quality, and cutover readiness. More conversions go badly because of data than because of configuration. Someone has to own whether the data is actually ready, and that person cannot be the same one who is incentivised to hit the date.
Business process owners. Not project roles. These are the people who own the platform after go-live, and hiring them during the programme rather than after it is the difference between owning the system and renting it back.
Integration lead. BTP, Integration Suite, and everything touching the wider data estate. Underestimated on almost every programme, because the integration surface is always larger than the plan assumed.
Everything else is genuinely rentable.
What should you own, and what should you rent?
| Capability | Model | Why |
|---|---|---|
| Architecture and design authority | Permanent | Decision rights and programme memory stay in the business |
| Business process and product ownership | Permanent | Owns the platform after go-live |
| Programme and PMO leadership | Permanent | Accountability cannot be outsourced |
| Data governance | Permanent | The second hiring wave, post go-live |
| Data migration, cutover, testing surge, integration build | Contract | Genuine peaks with a defined end date |
| Functional configuration and co-delivery | Systems integrator | Volume work inside a delivery wrapper |
| Basis and application management | Managed service | Run, not build |
Roughly 80% of a well-run programme proceeds along expected lines. The remaining fifth, where data quality, localization, change management and knowledge transfer sit, is where conversions are won or lost. That fifth needs owners, not contractors.
When should you start hiring
Earlier than feels necessary, for one specific reason.
Specialist SAP roles routinely take more than ninety days to fill, against roughly forty-four days for general IT. An architect search started when the programme kicks off arrives in time for the second phase, not the first.
There is also a timing problem specific to this market. Between 20,000 and 25,000 legacy customers have still to move, and programmes run twelve to twenty-four months. Everyone who chooses to migrate is competing for the same architects in the same window.
Practical sequence:
- Architect first, before the systems integrator is selected if possible. They should be part of that decision, not inherit it.
- Data lead in parallel. The data conversation starts earlier than most plans assume.
- Business process owners during design, not after go-live. They need to have been in the room when the decisions were made.
- Contract capacity when the peaks arrive, which is generally later than the plan suggests.
What happens after go-live?
The hiring does not stop. It changes shape.
43% of technology leaders are now optimizing existing S/4HANA environments, against 31% still transitioning. That second wave runs on different people: product owners, process owners, data governance, and the analytics and AI capability the platform was supposed to enable.
Programmes that treat go-live as the end of hiring typically discover within six months that the knowledge left with the systems integrator.
FAQ
Can our systems integrator supply the architect?
They can supply an architect. Whether you want the design authority for your platform sitting inside the firm delivering it is a different question. When the programme closes, that person leaves with the reasoning behind every decision.
How do we test conversion experience in an interview?
Ask what went wrong. Anyone who has genuinely run a conversion carries a scar, and the answer tells you what they owned. Three flawless go-lives usually describes proximity rather than ownership.
Is it cheaper to use contractors for everything?
On the invoice, sometimes. Contract rates for scarce SAP skills run 30 to 50% above the FTE-equivalent hourly. The larger cost is that capability walks out at the end of the engagement.
How long does an architect search take?
Six weeks from first conversation to start date is achievable on a permanent search. The market average for a specialist SAP role is more than ninety days.
Hiring for an S/4HANA conversion? Book a client consultation.
