The S/4HANA Conversion Factory

Why industrialised conversion delivery is becoming a distinct SAP transformation discipline

SAP S/4HANA conversion is usually managed as a project problem. An organisation identifies a system, assembles a team, plans the work, executes the conversion, stabilises production, and moves on. This model is familiar and can be effective when the number of conversions is limited.

The problem changes when an organisation must convert many SAP systems within overlapping timelines while drawing on the same pool of senior architects, functional experts, Basis specialists, testing resources, infrastructure teams, and business stakeholders. At that point, it is no longer sufficient to ask whether each individual project is well managed. The more important question is whether the delivery organisation itself is designed to execute repeated conversions with controlled quality, predictable use of scarce expertise, and consistent decision-making.

That is the distinction behind the S/4HANA Conversion Factory.

In this article, I use “Conversion Factory” as an operating-model concept, not as an SAP product term. It describes a production-oriented way of organising repeated S/4HANA conversions. The argument is based on delivery practice: running several projects in parallel does not by itself create a factory. A factory begins when the delivery system, rather than only the individual project, becomes the object of design and control.

The scaling problem

A conventional project organisation optimises for the success of one transformation. Governance, staffing, escalation, documentation, testing cycles, and cutover planning are normally designed around the needs of that particular system.

This creates a natural tendency toward local optimisation. A project manager protects the project schedule. A solution architect focuses on the risks of the system in front of them. Functional leads prioritise issues that block their own workstream. Within a single-project model, this behaviour is rational.

At portfolio scale, however, local optimisation can create systemic inefficiency.

The same senior expert may be needed by several projects during the same week. Multiple teams may rediscover the same simplification issue or build different variants of the same remediation approach. Testing environments may compete for infrastructure windows. Cutovers may be planned independently even though they depend on the same small group of specialists. Project-level escalations may appear unrelated even when they originate from the same portfolio-level constraint.

In my experience, the first symptom is rarely a dramatic project failure. More often, delivery becomes progressively less predictable. Senior specialists become bottlenecks. Teams add contingency because they cannot rely on shared capacity. Similar problems are solved repeatedly. Governance becomes heavier because management attempts to compensate for weak systemic control with more meetings and reporting.

This is the point at which conversion becomes a scaling problem rather than only a project problem.

A further consequence is that individual project status becomes an incomplete measure of portfolio health. Five projects can each appear manageable while collectively overloading architecture, Basis, testing, data, or cutover capability. Factory governance therefore has to operate above project level. It must identify risks that may not exist inside any single plan but emerge from the interaction between several plans.

What a Conversion Factory is — and what it is not

The word “factory” is easy to misuse. It may be applied to a central delivery centre, a standard template set, a technical migration team, or simply a programme containing many conversion projects. None of these, by itself, constitutes a factory.

A Conversion Factory is better understood as a production-oriented delivery model for repeated S/4HANA conversions.

The emphasis is on repeated delivery.

A project organisation asks: how do we deliver this conversion successfully?

A factory asks: how do we design the delivery system so that this conversion, the next one, and the one after that can be executed with comparable quality, greater reuse, controlled variation, and more predictable demand on scarce expertise?

This does not require SAP landscapes to become identical. They will not. A system conversion preserves a substantial part of the existing ERP system and therefore carries forward system-specific configuration, custom code, data history, interfaces, and operational constraints. SAP’s own conversion guidance consequently includes dedicated preparation, simplification, custom-code, technical conversion, and follow-on activities.

The factory objective is not therefore to standardise the customer systems. It is to standardise the delivery mechanism around them.

In practical terms, several characteristics distinguish a factory model.

The lifecycle is explicit. Conversions move through a common sequence of stages with defined entry and exit conditions.

Expertise is treated as a shared production capability where appropriate, rather than being replicated permanently in every project.

Knowledge and delivery assets are reusable by design. Assessment logic, remediation patterns, testing approaches, quality criteria, cutover controls, and governance artefacts should improve as the factory executes more conversions.

Progression is evidence-based. A project should not move forward merely because a status report is green; it should move because agreed readiness conditions have been met, or because an accountable decision has explicitly accepted the residual risk.

Finally, the portfolio is managed as a system. Capacity, dependencies, bottlenecks, delivery waves, and shared risks become management objects in their own right.

A factory is therefore not a larger project team. It is a different operating model.

Why this model is emerging now

There is also a structural reason why this discussion matters now.

SAP states that mainstream maintenance for core SAP Business Suite 7 applications, including SAP ERP 6.0 under the applicable maintenance conditions, runs until the end of 2027, followed by optional extended maintenance until the end of 2030. This does not mean every organisation faces the same migration date or business case, but it does create a defined transition horizon for a substantial part of the installed base.

The delivery challenge is compounded by landscape heterogeneity. Long-lived SAP environments often reflect acquisitions, local extensions, different operating models, custom developments, interfaces, and years of accumulated business decisions. Two systems may both be called “ECC 6.0” while presenting very different conversion workloads.

At the same time, experienced transformation expertise is inherently limited. Architecture decisions, complex remediation, custom code, data transition, testing strategy, cutover design, and production stabilisation repeatedly require experienced people.

The conventional response is to add more project teams. That helps only until every additional project begins competing for the same constrained capabilities.

The factory model addresses this by separating repeatable delivery work from scarce expert decision-making.

This is an important principle. Industrialisation should not remove senior expertise from conversions. It should make the consumption of that expertise deliberate. Senior people should be concentrated on decisions, exceptions, and risks where their judgement materially changes the outcome, rather than being absorbed by activities that could be standardised, reused, or delegated.

The operating system behind the factory

A practical Conversion Factory can be implemented in different organisational forms, but the underlying logic is relatively stable.

A core capability owns common methods, architecture principles, quality criteria, reusable assets, and portfolio-level governance. Conversion squads execute system-specific work. Shared expert pools support capabilities where expertise is scarce, highly specialised, or required unevenly across the lifecycle.

Delivery waves provide another control mechanism. Projects should not enter resource-intensive phases simply because their individual schedules say so. The factory has to understand whether aggregate demand can actually be supported.

A common lifecycle then provides the basis for comparison and learning. Discovery, assessment, preparation, technical conversion, functional and technical remediation, testing, cutover, and hypercare may contain different work for each system, but their governance can still be consistent.

The purpose is not bureaucratic uniformity. It is feedback. When comparable stages are repeated, the organisation can see where estimates fail, which issues recur, where gates are weak, which assets are genuinely reusable, and where specialist intervention creates the greatest value.

Without that feedback loop, a “factory” remains a portfolio of projects under a common label.

Industrialisation without oversimplification

This is, in my view, the most important distinction in the entire model.

Industrialisation is often interpreted as simplification: make every project standard, reduce senior involvement, create templates, automate activities, and move more work to lower-cost resources.

That interpretation is dangerous.

SAP landscapes are not uniform production objects. They contain different processes, organisational structures, custom developments, data histories, interfaces, regulatory obligations, and operational constraints. Some complexity can be removed through transformation decisions. Some complexity is intrinsic to the business and must be managed.

A Conversion Factory should therefore not attempt to industrialise complexity away.

It should industrialise the way complexity is identified, classified, routed, controlled, and resolved.

Standardisation and simplification are not the same thing.

Standardisation defines how recurring work is governed and executed. It can standardise assessment criteria, issue classification, remediation workflows, evidence requirements, quality gates, cutover readiness checks, escalation paths, and reporting structures.

Simplification changes the underlying business or solution environment.

A factory requires the first. It cannot assume the second.

Expert judgement therefore remains essential. What changes is the way that judgement is consumed.

In a weak delivery model, senior experts are frequently drawn into routine activity because the process cannot reliably distinguish standard work from exceptional work. They review issues that could have been classified earlier, attend meetings because ownership is unclear, and solve problems that another project may already have solved.

A stronger model creates boundaries. Repeatable work follows defined procedures. Known patterns use reusable solutions. Deviations are visible. Exceptions are routed to the right expertise. Decisions are captured so that later projects can reuse the reasoning, not merely the final document.

The purpose of industrialisation is not to make every SAP system look the same. It is to make the delivery system predictable even when the SAP systems are not.

This is also why a mature factory should become more capable over time. Every conversion produces operational knowledge: which issues recur, where assumptions fail, which quality criteria are useful, which technical patterns can be reused, and where expert intervention actually changes outcomes.

If this knowledge remains within individual project teams, the organisation pays repeatedly for the same learning.

Evidence-based control at a glance

The final element needed to establish the discipline is evidence-based control.

At factory scale, narrative status reporting is not enough. Management needs a consistent basis for deciding whether work is ready to progress and whether scarce shared capacity should be committed to the next phase.

A quality gate should therefore answer a practical question: is there sufficient evidence that the risks of entering the next stage are understood and controlled?

For testing or cutover, that evidence may include remediation status, defect severity, test completion, environment readiness, unresolved business risks, data validation, interface readiness, operational preparation, or rehearsal results. The exact criteria will differ between organisations and phases.

The principle is more important than the particular checklist.

Evidence-based governance changes the conversation from “Are we green?” to “Which readiness conditions have been met, which have not, and what risk are we accepting by proceeding?”

That difference becomes particularly important when one project’s decision consumes capacity or creates risk for several others.

Where the discipline goes next

Once the operating model is established, the next questions concern how it is enabled and scaled.

An integrated transformation toolchain can connect assessment, process analysis, architecture, implementation governance, testing, conversion, adoption, and reporting into a more coherent delivery picture.

Parallel execution requires explicit capacity management, wave design, bottleneck control, and shared-resource governance.

Automation and AI can then support areas such as assessment, evidence analysis, planning, knowledge reuse, risk detection, and quality preparation. Over time, selected coordination activities may become increasingly agentic.

But the sequence matters. Technology should reinforce a defined operating model. Automating an inconsistent delivery system usually creates faster inconsistency.

Conversion as an industrial discipline

The S/4HANA Conversion Factory should not be understood merely as a mechanism for making individual projects faster.

Its purpose is more fundamental: to transform repeated conversion delivery from a collection of locally optimised projects into a managed production system.

Such a system preserves expert judgement while reducing unnecessary variation. It reuses knowledge rather than recreating it. It manages scarce capability across a portfolio instead of treating capacity as an isolated project concern. It moves work through explicit stages based on evidence, not reporting confidence.

For senior leaders, this changes the central management question.

The question is no longer only whether a particular S/4HANA conversion can be delivered successfully.

The more important question is whether the organisation has designed a delivery system capable of executing the next conversion, and the next, with controlled quality, visible constraints, and increasing organisational learning.

That is the point at which S/4HANA conversion becomes an industrial discipline.

Editorial source notes

SAP Business Suite 7 maintenance horizon. SAP’s official maintenance statement confirms mainstream maintenance for core applications through the end of 2027 and optional extended maintenance through the end of 2030. Official SAP maintenance statement

SAP S/4HANA conversion process. The official Conversion Guide for SAP S/4HANA 2025 covers preparation, SUM conversion, custom-code adaptation, and application-specific follow-on activities. Official SAP conversion guide

---

Vasily Verkhovsky writes in a personal capacity. SAP Transformation & Delivery Manager at EPAM — views are his own. This is an invited Special Guest contribution; articles on sapperment are vendor- and firm-neutral. Connect with Vasily on LinkedIn.

Next: meet all sapperment experts — including the Special Guests — or browse the sapperment library.