// SAP S/4HANA Transformation
Johannes Schulz
SAP Business ByDesign: Phased out in a whisper. Why many customers believe they still have time – and are completely mistaken
If you, as an SAP Business ByDesign customer, think today: "We still have time for that," you are probably right. However, you have significantly less time than the word "time" in your calendar suggests.
There is no email from SAP telling ByD customers: "It's over on date X." From a marketing perspective, this is understandable. From a customer perspective, it is a problem – because the human brain reacts differently to quiet signals than to loud ones.
Exactly this constellation – a phase-out without a bang, without a fixed deadline, without a clear address to the individual customer – is what ByD user companies currently have to deal with. And it is worth briefly and soberly looking at what exactly has happened.
The phase-out in slow motion
The situation regarding SAP Business ByDesign is factually clear, even if it was not communicated that way:
ByD has disappeared from the official price list.
There are no more active sales to new customers.
The range of functions is no longer being significantly developed.
Strategically, SAP Cloud ERP (formerly S/4HANA Cloud Public Edition) is the clearly designated successor.
Maintenance is ongoing, but with a defined horizon.
In the SAP environment, this is the unmistakable translation of: This platform will not be the system with which SAP operates for the next ten years. What SAP wisely did not do: prominently communicate a fixed deadline. What they did do: strategically let the system phase out.
Why this doesn't feel like a phase-out
Three reasons why ByD customers typically react to these signals with inertia – and this is not a question of naivety, but of psychology:
The system is running. Daily business functions. The next patch arrives. No error message drives anyone to the whiteboard.
The users notice nothing. Sales sells, accounting books, warehouse delivers. No one feels in their everyday operative life that the strategic advancement of the system has been frozen.
The calendar trigger is missing. In behavioral economics, this is a well-documented pattern: What lacks a clear date is reliably postponed. A tax return with a deadline gets done. An "address the ERP at some point" gets deferred.
This combination is the psychologically perfect delay trap – and it works very reliably. Exactly for this reason, a quiet phase-out is more dangerous for the affected customers than a clearly communicated one.
The time illusion: What an ERP migration really requires
An ERP change is not a half-year project. Whoever wants to run stably on a successor system at the end should calculate realistically:
Decision phase (6 to 12 months): Clarify target architecture, align stakeholders, select implementation partner, calculate business case, move budget.
Scoping and preparation (3 to 6 months): Record active functions, fit-gap analysis, data migration concept, interface planning.
Migration and implementation (12 to 18 months): Configuration, data migration, testing, cutover, rollout. With multiple companies or locations, even longer.
Hypercare and stabilization (3 to 6 months): Users, processes, data quality.
This totals 24 to 42 months from the starting signal to stable productive use. Calculated backwards from the realistic end of maintenance, the decision – i.e., the point at which it is clear where the journey is going and how it will be set up – lands strikingly close to "today". For some ByD customers, the window for an unstressed migration has already largely closed. For others, it is two, maybe three years. Rarely is it longer.
Three years feel like a lot. Three years of time to change an entire ERP system is practically the day after tomorrow.
Where to? The question of the target picture
The obvious path for ByD customers is SAP Cloud ERP – similar cloud-first logic, similar standardization philosophy, low in-house effort in operation. Exactly for this reason, SAP explicitly built this bridge.
Obvious, however, is not automatically suitable. Three questions should be answered before anyone writes "migration" into the minutes:
Which actively used ByD functions find their equivalent in SAP Cloud ERP?
Where are there hard gaps – i.e., functionalities that are simply not provided in the standard of SAP Cloud ERP?
Which in-house developments and third-party applications must migrate along, be rethought, or replaced?
These are not theoretical questions. This is exactly where migration projects fail most often – not due to technical migration, but due to late-recognized functional gaps, which must then be bridged through improvisation under time pressure.
How? The underestimated implementation question
The "where to" question is usually discussed extensively in preliminary discussions. The "how" question significantly less so – and that is risky, because it is the actual hard nut to crack. A cleanly set up migration comprises four interlocking phases:
Scoping – which processes migrate along in what form, which ones are newly set up, which ones are dropped completely?
Migration planning – data strategy, cutover logic, fallback scenarios, interface mapping.
Implementation – configuration, adaptation within the standard framework, user onboarding, structured testing.
Hypercare – the first weeks after go-live, in which data quality and process stability are decided.
Whoever does a fit-check and then parks the implementation as "we'll take care of it later" strategically only has part of the necessary basis for decision-making. The fit-check is a prerequisite. The implementation is the actual task.
What you can already do today
Whoever wants to counter the delay reflex without falling into operational hecticness has three pragmatic steps at hand:
Honest inventory of active usage: Which ByD functions are actually used (not: which are in the requirement specification)?
External fit-assessment against SAP Cloud ERP: Structured check: Where are gaps, adaptation needs, or in-house developments that need a follow-up concept?
Preliminary calculation against the maintenance horizon: Set up the backward calculation from above cleanly once for your own company. This turns "still time" into a concrete date.
Three steps that in total are less effort than an average quarter-end closing. But they fundamentally change the discussion – from gut feeling to a factual basis.
My suggestion: The critical factor is the starting point
A silent phase-out is no less real than a loud one. It is only more uncomfortable because it does not set a calendar trigger – and thus leaves the responsibility for the right time completely on the customer side.
For SAP Business ByDesign customers who want to honestly face this calculation, IBIS Prof. Thome supports them within the framework of the Transform solution with a data-based fit-assessment against SAP Cloud ERP, the scoping of the migration, the implementation itself, as well as support through the hypercare phase – so that "still time" becomes a planned transformation instead of a project under time pressure.
What does your ByD timeline look like? Are you still in the analysis phase, or is planning already underway? I look forward to the discussion in the comments!
The featured image was generated using AI.
