Why SAP S/4HANA Migration Needs Clean Process Mapping First
S/4HANA migrations fail on process clarity more often than on technology. Before any system conversion, an organisation needs a documented map of…
Dedicated consultant
A named individual working continuously on your landscape develops something a rotating team cannot: knowledge of why things are configured the way they are, which historical decisions still constrain the design, and who to talk to in the business. That context makes them significantly faster on your system than an equally skilled person who is new to it.
The costs are concentration and coverage. When they are on leave, you have no depth. When they leave, the context leaves too unless documentation has been maintained deliberately. And a single consultant covers one or two modules well, not five.
- Suits steady work in one or two modules
- Builds context that materially improves resolution speed
- Creates a single point of failure for knowledge and coverage
- Requires deliberate documentation to reduce dependency
- Needs a defined backup arrangement for absence
Project team
A team assembled for a defined outcome, an implementation, a rollout, an upgrade or a migration, brings the mix of skills a project needs at the point it needs them, and disbands afterwards. The commercial structure aligns with a deliverable and an end date.
The failure mode is using this structure for work that does not end. Operational support delivered by a project team produces knowledge that walks out at project close, and a client who then discovers that nobody internally can explain the configuration.
| Factor | Dedicated consultant | Project team | Managed service |
|---|---|---|---|
| Work pattern | Continuous | Defined outcome and end | Variable, ongoing |
| Skill breadth | One or two modules | Broad for the project | Broad across modules |
| Context depth | High | Moderate, then lost | Moderate, retained by provider |
| Coverage during absence | Weak unless arranged | Team covers | Built in |
| Cost pattern | Fixed | Front-loaded, ends | Variable or retained |
| Knowledge retention | Person-dependent | Requires handover discipline | Provider-dependent |
| Best for | Steady module-specific work | Implementation, rollout, upgrade | Multi-module support |
Managed service
Shared capacity across modules, priced by ticket volume or retainer, suits demand that is unpredictable and spread thin. You get coverage in areas where you could not justify a dedicated person, and continuity does not depend on one individual’s availability.
The trade-off is context. A managed service engineer picking up your ticket knows SAP; they may not know why your organisation configured a particular process the way it did. Providers that assign a consistent named team, rather than a pure pool, reduce this considerably and it is worth specifying.
Hybrid arrangements
Most established SAP estates end up with a combination, and it is usually the right answer rather than a compromise: an internal or dedicated resource holding business context and owning the relationship, a managed service providing module breadth and out-of-hours coverage, and project teams brought in for defined pieces of work.
What makes hybrids work is a clear boundary between what routes where, and a single point of accountability. Without that, tickets bounce between parties and the client becomes the coordinator by default.
Protecting knowledge whichever model you use
The organisations that suffer least when resources change are the ones that treated documentation as a deliverable rather than an aspiration. Configuration rationale, integration inventory, custom object register, and known issues with their workarounds.
Make it contractual. Documentation produced as a condition of payment gets produced; documentation requested as good practice does not.