Contract, contract‑to‑hire or permanent: choosing the shape of an SAP hire

The question

Three engagement shapes are available for almost every SAP role, and the choice between them is usually made on which budget line has room in it. Capital budget favours contract. Operating budget favours permanent. Neither of those facts has anything to do with the work.

The more useful question is simple: does this need end when the programme does?

Why it is harder than it looks

Work in an SAP landscape comes in two shapes that look identical on a job description and behave nothing alike.

Project-shaped work has an end. An upgrade, a conversion, a rollout, a remediation. It needs depth immediately, it needs it for a defined window, and when the window closes the need genuinely goes away. Hiring permanently into that shape produces someone excellent with nothing to do eighteen months later — which becomes a retention conversation nobody planned for, and usually ends with the person leaving anyway, taking the programme knowledge with them.

Capability-shaped work does not end. Regression that runs every release. Test data that has to stay current. Authorisations that change as the business does. This work looks smaller at any given moment, which is exactly why it gets staffed with whoever is passing. Filling it with contractors is not wrong, but it makes the knowledge rented rather than owned, and the cost of that only shows up at the handover.

The third shape, contract‑to‑hire, exists because the answer is often genuinely unknown at the start. That is a legitimate reason to use it. Using it to defer a decision that has already been made is not, and consultants can tell the difference.

A better way to think about it

Ask the question in this order.

Does the need survive the programme? If yes, it is capability and it should be owned, whatever the budget line says. If no, it is project work and a permanent hire is borrowing against a future problem.

How fast does it have to start? Permanent recruitment carries notice periods that project timelines rarely accommodate. This is the honest argument for contract on a fixed date, and it is a better argument than cost.

Who holds the knowledge afterwards? Every shape has an answer to this. Contract engagements need the handover designed in at the start rather than negotiated at the end — and it is worth agreeing, before anyone begins, what happens if the fit is wrong, rather than discovering the terms while a programme is short‑handed.

What it looks like in practice

A programme that has thought about this staffs its upgrade regression with contract depth for the window, and keeps one permanent person who owns the pack afterwards. The contractors carry the volume. The permanent owner carries the knowledge. Neither is asked to be the other.

The failure mode is the reverse and it is common: permanent hires brought in for a burst of project work, and the ongoing capability left to whoever has capacity that month.