Most S/4HANA programmes start the same way: a series of workshops to work out what the current system does, followed by an estimate built on what people said in the room.
The trouble is that workshops capture what people remember. After fifteen or twenty years of customisation, a lot of what the system does isn't remembered by anyone.
Where the surprises come from
- Custom code nobody in the room knew still ran.
- Enhancements tied to a process that changed years ago.
- Documentation that describes the system as it was designed, not as it runs.
- Interfaces that only surface when they break in testing.
Each of these turns up later, in realisation or testing, when fixing it costs the most. That's the scoping problem nobody budgets for.
Scope from evidence instead
Vera reads your custom code and your documents before anyone estimates. She links each custom object to the business process it serves, flags where specification and code disagree, and lists the gaps where nothing is documented.
The result is a readiness assessment you can defend: what to bring across, what to retire, what to rebuild, and what needs a decision. Every finding comes with its source.
Not just S/4HANA
S/4HANA is the most common version of this problem, but it isn't the only one. Cloud migrations, platform consolidations and carve-outs all start by asking what the current estate really does. The approach is the same: read the evidence first, then plan.
If you're planning a move, Vera is now open to work, with a limited intake. Interview her