S/4HANA: the decisions that come before the project
Moves to SAP S/4HANA rarely fail on technology. They fail on decisions taken too early or on too thin a factual basis. We help you take them in the right order.
Four crossroads – and what they really cost
Before anyone talks about timelines, four questions are on the table. Rebuild or convert? Will the system run at a hyperscaler, at SAP, or in your own data centre? What happens to the custom developments that have grown over the years? And how much of the legacy data actually has to come along? Answer these in the wrong order and you will pay to correct it later.
Our role here is deliberately that of the neutral adviser: we do not sell a deployment model. RISE with SAP, HANA Enterprise Cloud, private or public cloud, classic on-premise or a hybrid cut – the recommendation follows from your situation, not from a standard slide deck. That includes the honest answer "your ECC will carry you for another three years; use that time for the homework".
What sets us apart from pure strategy advice: we have done that homework hundreds of times ourselves. Custom code analysis, data cleansing, archiving to slim down the database, retiring redundant legacy systems – these are not theoretical recommendations but services you can also have us deliver. That is why our effort estimates hold up.
During implementation we follow one principle that later governs the cost of every release change: extensions do not belong in the core. Whatever can be solved through side-by-side apps on the Business Technology Platform, through CDS views or Fiori belongs there – not in a modification that resurfaces at the next upgrade.
At a glance
- Neutral recommendation instead of a predetermined model
- Greenfield, brownfield or selective transfer – with reasons
- Custom code analysis with a concrete clean-up plan
- Reduce data volume before migrating
- Clean core: BTP, CDS views, Fiori instead of modification
- Reliable estimates because we deliver the work ourselves
Question 1: greenfield or brownfield?
A rebuild frees you from legacy but costs process work. Converting preserves what has grown – including its problems.
- How well do your processes still fit the business?
- How much of the customising is genuinely justified?
- Is a selective transfer the better middle ground?
- What does data quality tell you about the effort?
Question 2: where will the system run?
The deployment models differ less in technology than in responsibility, flexibility and cost structure.
- RISE with SAP & HANA Enterprise Cloud
- S/4HANA private and public cloud
- On-premise – still a legitimate answer
- Hybrid cuts for landscapes that have grown
Question 3: what about the custom code?
The Z stack is usually bigger than assumed – and to a considerable degree unused.
- Which programs are actually being called?
- What does the standard now cover?
- What has to stay, what gets rebuilt?
- Rework along clean-core principles
Question 4: how much legacy data has to come?
Every gigabyte you do not migrate saves twice: in the project and in later operations.
- Data cleansing before the migration
- Archiving of completed documents
- Retiring systems that only serve enquiries
- Direct effect on migration time and cloud cost
Technical support
Once the decisions are made, our Basis and technology consultants carry the implementation.
- Sizing & capacity planning
- Authorisation concepts for the new landscape
- Interface and system landscape design
- Go-live support and hypercare
If you are not moving yet
That is a strategy too – it just needs to be chosen deliberately and used.
- ECC support in daily business
- Preparatory clean-up without project pressure
- Add-ons that run on both releases
- A later move with a far smaller scope
Frequently asked questions
Do you recommend greenfield or brownfield?
It depends on two things: how well your current processes still fit the business, and how solid your data quality is. If the processes fit and the data is sound, conversion is usually cheaper. If both are questionable, greenfield often becomes the better investment despite the higher process effort. A selective transfer is frequently the pragmatic middle ground.
Do you sell a particular deployment model?
No. We are tied neither to a hyperscaler nor to a hosting model. The recommendation follows from your situation – and occasionally it is to stay on-premise for now.
Why do you raise archiving and data volume so early?
Because data volume feeds straight into migration duration, test cycles and – in cloud operation – running cost. Cleaning up and archiving beforehand means migrating faster and paying less afterwards. It is one of the few levers that works before the project even starts.
What does "clean core" mean for our custom developments?
That for every requirement we first check whether it can be solved outside the core – via side-by-side apps on SAP BTP, CDS views or Fiori. Only what genuinely belongs in the system is built there, and then cleanly in our own namespace rather than as a modification.
How reliable are your effort estimates?
Reliable because we perform the underlying work ourselves: custom code analysis, data migration, archiving and decommissioning are not recommendations we hand to third parties but our own services, with benchmarks from hundreds of projects.
Does this match your project?
Talk directly to our consultants — no detours.