The 61% of SAP customers staring down the December 31, 2027 deadline to migrate from SAP ECC to S/4HANA are facing an inflection point. They must soon decide: Conversion or transformation?
Conversions focus primarily on the technical task of migrating to S/4HANA. The project is typically brownfield, with change intentionally constrained — and often underestimated — as the existing system largely remains intact, and the goal is as little disruption as possible.
A transformation, by contrast, uses the move to S/4HANA as an opportunity to rethink and advance how the business operates — redesigning processes, data usage, security models, and user experience to fully benefit from the platform’s capabilities.
The distinction matters. That’s because of an age-old rule in project delivery: fast, cheap or good (also known as time, cost or quality.) You can only choose two. While Systems Integrators (SIs) offer templated conversions optimized for speed (fast) and cost (cheap), they often deliver little more than a technically compliant system, falling short of delivering meaningful (good) business change.
In other words, the system moves forward — but the business stays largely the same. In this blog, we’ll explore what you should consider to enable your S/4HANA migration to deliver real transformation.
What’s motivating the transformation advice you’re getting?
Once you understand the difference between a conversion and a transformation, the next question is why so many S/4HANA programs default to the former.
Much of it comes down to how SAP operates. SAP’s strategic focus on cloud adoption and subscription-based models naturally aligns with faster migration cycles, where success is often measured by technical completion rather than long-term business change.
SIs operate within the same framework. Standardized conversion approaches are easier to scope, quicker to deliver, and better aligned with revenue targets, SAP credits, and delivery KPIs.
By comparison, transformation work introduces not only technical complexity and cross-functional dependency, but also significant organizational change and adoption challenges. These factors extend timelines, increase delivery risk, and make transformation far harder to package and commoditize.
As a result, important transformation elements are often pushed out of scope to the detriment of the business. Capabilities such as Ariba, Concur, SuccessFactors, EWM, and cloud security solutions are treated as follow-on initiatives, rather than being designed into the S/4HANA program from the outset. And the delays process to standardization, operating model change, and security-by-design limit the business value that S/4HANA is meant to unlock.
The result is predictable: A migration that meets its technical objectives but falls short of its transformational potential. Instead of creating a modern, secure foundation that supports growth, resilience, and long-term change, organizations are left with a technically upgraded system that still reflects old operating models — and their weaknesses.
Where does the conversion approach go wrong?
The problem is not that conversions fail technically, but that the delivery approach is optimized for system readiness rather than business readiness, security, and sustainable access design.
The SAP Activate typical project lifecycle is Discover, Prepare, Explore, Realize, Deploy, Run. However, in a conversion scenario, Discover and Explore are often heavily truncated. These phases become checklist-driven technical exercises, rather than opportunities to redesign business processes, access models, segregation of duties, or prepare the organization for change.
There are deficiencies in the Realize (or design) phase as well. From an authorization’s perspective, the focus is on delivering the bare minimum and relies primarily on the SAP S/4 Simplification items. In these cases, Transactions are depreciated and replaced by utility transactions such as BP (Centralized Business Partner maintenance). Without considering underlying authorizations, it becomes too easy to assign authorizations by default when that BP transaction is required. Where historically customers and vendors are segregated by different default transactions, now both could be maintained in one place. Consequently, a single user could be unwittingly assigned the ability to maintain settings for either vendors or customers, or both.
Likewise, where new Fiori apps are technically delivered, these may simply be generated according to SAP app library settings. In this manner, very little consideration is given to whether the app is presenting potential for process discrepancies, Segregation of Duties (SoD), or the user access strategies.
Toward the end of the Realize phase and entering Deploy, viable testing is often minimized in a conversion. This can also leave gaps in authorizations, business role alignment, and Segregation of Duties (SoD).
Overall, without early attention and focus, security risks increase and the scale of business change is significantly underestimated, which affects adoption and productivity.
Missed opportunities — and the consequences
So, what do you miss out on or leave yourself open to by going down the low-cost, high-speed conversion route? As it turns out, quite a lot:
-
Missed opportunity to streamline and standardize business processes through automation, efficiency, and global collaboration
-
Higher total cost of ownership through poor process optimization
-
Lost adoption, talent mobility, and productivity due to suboptimal user experiences, and through users not understanding how to use the system or the access provisioned
-
Increased organization risk through gaps in security, compliance and internal controls, and through starting with an outdated or insecure codebase
Opting for the conversion approach is effectively still spending a significant sum to deliver limited business value. It creates a disruptive change event, despite the intentions to avoid that very thing. And it remains a timely and costly technical program of work without tangibly improving upon old inefficiencies and operational constraints. Moreover, experience tells us that it’s impossible to outrun transformation — a conversion merely defers it until after go-live, when it resurfaces under time pressure, audit scrutiny, or operational disruption.
True transformation goes beyond migrating existing functionality and considers the ‘who’ and the ‘how’ of work, and how systems can support and control those activities. A key part of that transformation is to embed security as a key part of the business change workstreams from the outset, integrate controls early, and avoid retrofitting security later.
How to approach the full transformation
It may seem like there’s more work to do with a transformation compared to a conversion — but, in reality, it just brings that work forward, where it can be planned, governed, and aligned to business outcomes — rather than addressed reactively when it becomes a problem.
Businesses that put the right preparation in place for a transformation can better align different stakeholders, improve security controls and audit readiness, and standardize and simplify business processes. Notably, those that go down the transformation route are actively investing in business value creation through efficiency and innovation initiatives. Importantly, their planning to execute only one project.
To fully unlock the opportunities for value and adoption, you should:
-
Start with clear planning and gain an understanding of what the transformation should achieve
-
Involve security as early as possible and treat it — and authorizations and controls — as an integral to proactive change
-
Assess alignment of IT with business adoption, to break down the mindset that it’s just a software migration, and ensure everyone is aligned with the goals of adoption, efficiency, and compliance
-
Review and optimize business processes for automation and global standardization
-
Ensure you dictate the terms of the transformation, not SAP or your SI
In summary: Putting your business at the heart of your transformation
Remember that you’re in control of the transformation, and it should be guided by your business goals accordingly. Don’t be swayed by conflicting interests, don’t be pressured into a conversion that doesn’t meet your needs, and take the opportunity to embrace transformation for optimized, standardized, and simplified processes.
By planning carefully, engaging strategically, and aligning IT with business outcomes, you can maximize the potential of efficiency, adoption, and compliance. And by factoring in user needs as early as possible, you can ensure that the business investment of the transformation is fully justified.
Turnkey Consulting can ensure your technology, processes, and people are perfectly aligned to make your transformation as smooth, secure, and future-proof as it possibly can be. Get in touch with our team to find out more.
Frequently asked questions about S/4 HANA transformations
1: What’s the difference between an S/4HANA conversion and an S/4HANA transformation?
Conversions focus on the technicals of moving to S/4HANA. Changes are technical in nature based upon the SAP delivered code base changes, not business process and adoption changes. The aim is keeping the system running, and the project is often brownfield. A transformation, on the other hand, redesigns business processes, data usage, security, and user experience to fully maximize the benefits of S/4HANA capabilities.
2: Is security really impacted if my organization ‘just’ does a technical conversion?
Absolutely. S/4HANA introduces new transactions and applications, consolidated processes such as Business Partner, and Fiori apps that replace classic transactions. Few existing roles map cleanly to S/4HANA usage, meaning legacy authorizations still in place may break business processes, create SoD conflicts, or lead to over-provisioned access.
3: When should security and access management be involved in an S/4HANA transformation?
From the beginning, and throughout process design, build, testing, and deployment. This is because security is more than just a technical control. It supports business change, training, testing, and adoption. Retro-fitting security later can lead to increased risk, cost and project timeframes, and so security needs to be funded and present for the duration of the program.
