The 2026 World Cup concluded in July after 48 teams competed across Canada, Mexico and the United States. What stayed with me was not only the football. It was the amount of preparation behind a few high pressure match days.

That is also how I look at an SAP S/4HANA conversion.

The SUM downtime gets most of the attention because that is when the business is watching the clock. But the quality of a conversion is decided much earlier, through readiness, remediation, architecture decisions, rehearsal cycles, cutover planning and recovery preparation.
The World Cup analogy is useful only to make that point. An S/4HANA conversion is not a weekend technical upgrade. It is a coordinated business and technology program, and the architect’s job is to make sure all the moving parts arrive at the same point at the same time.

Start with the transition path, not the tool

Before discussing SUM, DMO or downtime, the first decision is the transition approach.

SAP broadly supports three paths to S/4HANA: a new implementation, a system conversion and a selective data transition. A new implementation gives the organisation an opportunity to redesign processes and start with a cleaner core. A system conversion, commonly called brownfield, retains the existing system, history, configuration and much of the custom development, while adapting them to the S/4HANA data model. Selective data transition sits between the two and allows selected data and processes to move into a new target.
This article focuses on a system conversion, with a move to SAP S/4HANA Cloud Private Edition or a similar target where DMO with System Move may be part of the technical approach, subject to the source release, target design and SAP supported migration path.

1. Readiness is where the conversion really starts

A good conversion begins with facts about the current system.

SAP Readiness Check is one of the first artifacts I want on the table. It helps identify relevant simplification items, custom code impact, add on compatibility, sizing considerations and other conversion topics. I prefer to treat it as a living assessment rather than a report that is generated once and filed away. As remediation progresses, the picture changes and the assessment should become cleaner.

In parallel, Maintenance Planner confirms whether the intended software path is technically valid. This is where add ons, active business functions and product dependencies have to be understood before SUM becomes the centre of attention. Unsupported components discovered late can change the entire plan.

There are also conversion prerequisites that need their own workstream. Customer and vendor integration is a good example. In S/4HANA, Business Partner becomes the leading object for customer and supplier master data, so CVI preparation and data consistency cannot be left until the technical conversion weekend.

At architect level, I normally want the preparation backlog grouped into a few clear areas:

1. Simplification items and functional remediation.
2. Custom code analysis and adaptation using ATC and the relevant S/4HANA checks.
3. Business Partner and CVI readiness.
4. Add ons, business functions and target release compatibility.
5. Data volume, archiving and housekeeping.
6. Interfaces, RFCs, middleware, batch jobs and external dependencies.
7. Security, roles, Fiori, SSO and technical authorisations.
8. Target sizing, storage, network throughput, HA and DR design.

If these topics are still moving close to production cutover, the risk has already shifted into the wrong phase.

2. Simplification and custom code are not Basis activities

One of the common mistakes in a brownfield program is to treat the conversion as a Basis project because SUM performs the technical conversion.

SUM is important, but it is only one part of the program.

S/4HANA changes the application data model and removes or replaces parts of the old ERP architecture. Simplification items therefore need functional ownership. Finance, logistics, procurement, sales, manufacturing and industry solutions may all have conversion actions that must be understood and tested.

Custom code needs the same discipline. ATC and the S/4HANA readiness checks help identify code affected by changed tables, APIs and application behaviour. Usage information is equally important. There is little value in spending time adapting custom code that has not been used for years.

The objective should not be to carry everything forward simply because it exists. The better question is: what still has business value, what can be replaced by standard S/4HANA capability, and what should be retired?

That is where an S/4HANA conversion can also become a useful clean up exercise instead of only a technical migration.

3. Size the target from evidence, not assumptions

Sizing is another area where architecture decisions have long term consequences.

The target needs enough HANA memory, CPU, storage and I/O capability for the converted workload, but sizing is not only a database calculation. The application tier, batch workload, interfaces, reporting, Fiori usage, growth, HA and DR footprint all matter.

For a RISE or private cloud target, the sizing result also feeds the infrastructure and commercial discussion. Undersizing creates performance problems immediately after go live. Oversizing may leave the business paying for capacity it does not need.

I also look at data volume before the first serious mock conversion. Large historical tables, obsolete data, old clients, spool growth and unnecessary technical content all affect migration time and storage. Data that does not need to travel should be dealt with before it becomes part of the downtime problem.

4. Rehearsal cycles are where production risk is removed

The production conversion should never be the first time the complete process is executed end to end.

I prefer a sequence that starts with a sandbox conversion, followed by one or more conversion cycles on production like copies, then a final dress rehearsal. Each cycle should produce evidence, not just a statement that the upgrade completed.

The useful outputs are things such as:
• actual runtime by SUM phase
• longest migration tables
• SPDD and SPAU effort
• application and interface defects
• resource bottlenecks
• transport sequencing issues
• functional and security validation gaps
• backup and restore timings
• the real business downtime

UPGANA and SUM runtime analysis are particularly valuable because they allow the team to tune the next cycle using measured data.
A rehearsal is also where the cutover runbook becomes real. If a step has no owner, dependency, duration, validation method or rollback condition during the rehearsal, it will not become clearer under production pressure.

5. What DMO with System Move actually does

For supported scenarios, the Database Migration Option of SUM can combine the software conversion with the move to SAP HANA. DMO with System Move extends that model when the target environment is on different infrastructure.

The exact mechanism depends on the selected procedure, but conceptually there are coordinated SUM activities on the source and target sides. The source performs the conversion preparation and data export activities. The target receives the migration content, loads it into SAP HANA and completes the S/4HANA conversion process.

It is better to describe this as an orchestrated source to target transfer rather than assume that every project uses the same shared mount or file system design.

There are a few technical areas I watch closely during these cycles.

SPDD and SPAU. Modified SAP dictionary and repository objects need controlled adjustment. These tasks must be prepared, tested and transported correctly between conversion cycles.

Transport control. Development activity, retrofit or dual maintenance, release strategy and the final transport sequence need to be agreed well before cutover. The production conversion is not the place to discover an unreleased dependency.

Background processing and interfaces. Jobs, inbound and outbound interfaces, middleware queues, RFC traffic, SLT or other replication activity need a defined ramp down and restart sequence.

Database and migration throughput. R3load process counts, database capacity, CPU, memory, storage throughput and network transfer rates have to be tuned from evidence collected during earlier runs.

HA and DR. The converted database, application services, HANA System Replication and disaster recovery design need their own activation and validation steps. A successful SUM completion does not automatically mean the production resilience design is ready.

6. Downtime is an architectural problem, not just a SUM parameter

The business experiences the conversion mainly through downtime, so this is where technical optimisation needs to be tied to business expectations.

SAP provides downtime optimised approaches that move eligible migration and conversion work into uptime. For example, downtime optimised DMO can migrate selected large application tables while the source remains productive, with changes captured and replayed later. Downtime optimised conversion can also move supported conversion work into uptime.

Large tables should be analysed for migration behaviour and partitioning. Parallel R3load and other SUM process settings should be tuned within the capacity of the source, target and network. The goal is not to set the highest possible number. The goal is to find the point where more parallelism still improves throughput without creating contention.

During DMO, SUM manages specific target HANA settings required for migration, including the temporary use of log mode overwrite, and returns the database to normal log mode after a successful migration. That makes the post migration full database backup particularly important.

Silent Data Migration can also move selected application data conversion work out of the critical downtime path, but it should be treated as part of the conversion design and monitored after go live, not used as a generic way to postpone unresolved work.

The most important point is simple: downtime should be proven in the dress rehearsal. It should not be estimated for the first time in a steering committee slide.

7. Cutover is the real integration point of the program

This is where the World Cup analogy is most useful. Match day looks simple to the audience because hundreds of activities have already been sequenced behind it.

A production cutover is the same.

The runbook should connect business freeze, Basis, database, cloud infrastructure, security, integration, development, functional validation, SAP support and operations. For a RISE or private cloud program, it should also clearly define which platform activities are performed by SAP and which remain with the customer or implementation partner.

A practical cutover normally includes these control points:
9. Final business and transport freeze.
10. Source health checks and confirmation of prerequisite jobs.
11. Confirmed backup or restore point before the irreversible phase.
12. Controlled stop of business jobs, interfaces and replication as applicable.
13. SUM downtime and migration execution.
14. Technical validation of the converted S/4HANA system.
15. Database, application, interface, security and batch validation.
16. Functional smoke tests and agreed business validation.
17. Explicit go or no go decision against predefined criteria.
18. Full HANA backup after successful migration and return to normal log mode.
19. HA and DR enablement or validation as designed.
20. Controlled reopening to users, interfaces and scheduled processing.

Rollback deserves the same level of design as the forward plan. The team needs to know the last safe decision point, what backup or snapshot is being relied upon, the expected restore duration, how external systems are returned to the original state, and who has authority to make the decision.

A rollback plan that starts with “if something goes wrong” is not yet a rollback plan.

8. Go live is the start of operational proving

The technical conversion may be complete, but the system still has to prove that it can run the business.

Post processing includes SPAU completion, transport unlock and other SUM follow up activities. ABAP load generation through SGEN may be performed using different SUM strategies or completed after the update, depending on the plan. The important point is that load generation is deliberate and does not become a surprise for users.

From there, the focus shifts to operational validation:
• business critical transactions and Fiori apps
• RFCs, APIs, IDocs, middleware and queues
• background jobs and job servers
• spool and printing
• workflow
• security roles and SSO
• HANA performance and expensive statements
• dumps, update failures and system logs
• monitoring, alerting and backup jobs
• HA and DR status
• business reconciliation and financial controls

Hypercare should have clear entry and exit criteria. The objective is not to keep the project team around indefinitely. It is to prove that support teams can run the new platform as normal operations.

9. The architect’s view is end to end

The strongest S/4HANA conversion plans I have seen are not necessarily the ones with the most slides or the most tools. They are the ones where dependencies are visible and decisions are made early.

The architect needs to keep several views connected at the same time: application simplification, custom code, infrastructure, integration, security, data, testing, downtime, cutover, resilience and operations.

That is why I do not see production conversion as a single weekend event. The weekend is only the visible part of a much longer campaign.
The 2026 World Cup was decided on the pitch, but no team reached those matches on talent alone. Preparation, rehearsals, coordination and recovery mattered just as much.

For S/4HANA, the principle is similar. A well run conversion should feel uneventful on go live weekend. That quietness is not luck. It is the result of months of disciplined preparation.

Technical reference points

This article has been technically checked against current SAP guidance for SAP Readiness Check, Maintenance Planner, Business Partner and CVI, SUM 2.0, DMO with System Move, downtime optimised conversion, SGEN and conversion rehearsal practices. Exact procedures and supported options depend on the source release, target release, SUM level and chosen SAP S/4HANA deployment model, so the project specific SAP guides and notes should remain the operational source of truth.

The term “Autonomous Enterprise” is no longer a concept in a Gartner report. It is quietly becoming the operating model of the world’s largest companies — most of them running SAP.

In two decades working with enterprise technology, we have watched ERP go from on-premise monoliths to cloud, from ABAP customisations to clean-core mandates, and from waterfall implementations to agile delivery. Each shift redefined what it meant to be an SAP consultant. The shift happening right now — driven by AI, Joule, autonomous agents, and Business AI embedded across the SAP stack — is not incremental. It is a platform-level transformation.

If you are an SAP professional, this piece is for you. Not to alarm — but to give you an honest view of what is changing, why it matters, and precisely where your 10, 15, or 20+ years of experience becomes your most valuable asset.

What is the Autonomous Enterprise?
The Autonomous Enterprise is an organisation where AI systems — not just humans — make, execute, and optimise business decisions in real time. Routine processes run without human intervention. Exceptions are flagged and contextualised before a human ever needs to act. Systems learn from outcomes and adjust continuously.

In the SAP world, this is being built through four converging forces:

01 SAP Joule — the AI copilot embedded across the suite
Joule is not a chatbot bolted on. It is a natural language interface woven into S/4HANA, SuccessFactors, Ariba, and BTP. It translates business intent into system action — reducing the need for a human to know menu paths or T-codes.

02 AI agents running end-to-end processes
SAP’s Business AI portfolio now includes agents that can autonomously close month-end, reconcile invoices, match open items, and trigger downstream procurement workflows — with a human reviewing rather than executing.

03 Clean Core and BTP as the AI delivery layer
SAP’s push for clean core removes legacy customisations that block AI adoption. BTP — SAP Business Technology Platform — becomes the orchestration layer where AI models, integrations, and extensions live.

04 Real-time data via SAP Datasphere
Autonomous decisions require trusted, real-time data. SAP Datasphere connects business data across the entire landscape so AI agents can act on current ground truth, not yesterday’s batch.

What is actually changing on the ground
The honest answer: a significant portion of what junior and mid-level SAP consultants have been paid to do for years is being automated. Configuration tasks guided by AI, test script generation, basic functional design documentation, and routine support tickets are all in scope.

“The SAP consultant of 2027 will not be measured by how many transactions they can configure. They will be measured by how well they help an organisation decide which decisions should stay human — and design the AI systems that handle everything else.”

A lesson from the last big shift: on-premise to cloud
To understand what is coming, it helps to look at what already happened. The migration from on-premise SAP landscapes to cloud — particularly the move from ECC to S/4HANA on RISE with SAP — was the most disruptive transition this industry had seen in a decade. And it exposed a clear divide in who thrived and who did not.

Organisations that had been running SAP on-premise for 15–20 years often had landscapes that were deeply customised: tens of thousands of Z-objects, bespoke interfaces to legacy systems, modified standard programmes that no one fully understood anymore. When the cloud imperative arrived — driven by end of ECC maintenance, infrastructure cost pressure, and board-level digital transformation mandates — many of these organisations did not know where to start.

The consultants who became indispensable in that moment were not those with the deepest ABAP knowledge or the longest list of module certifications. They were the ones who could walk into a room with a CIO, a CFO, and a Head of Operations, and translate years of technical complexity into a credible business case for change. They knew which customisations were genuinely differentiating versus which ones were accidental — built to work around a process gap that SAP standard had long since solved.

That same profile — technically grounded, business-fluent, trusted to lead through uncertainty — is exactly what the autonomous enterprise transition is asking for now. The technology is different. The nature of the challenge is not.

Why experienced consultants have the edge
Here is what the narrative around AI disruption consistently gets wrong: it treats experience as a liability. In enterprise technology — and in SAP specifically — depth of experience is exactly what AI cannot replicate in the near term.

An AI agent can execute a three-way match. It cannot tell you why a particular client’s procurement policy will create exceptions at month-end, or how their intercompany structure makes standard SAP Group Reporting behave unexpectedly in a cross-border scenario. That knowledge lives in people with scars.

A. Ask the right question before designing the automation
The most dangerous thing in the autonomous enterprise is automating the wrong process at scale. Senior consultants who understand why a process exists — not just how it works — are essential for preventing expensive AI failures.

B. Navigate organisational reality
Technology decisions in SAP programmes are rarely purely technical. They are political, financial, and cultural. Building trust, managing stakeholders, and knowing when to push back — this is the domain of seasoned professionals, not models.

C. Design for outcomes, not outputs
Autonomous systems optimise toward the objective they are given. Experienced consultants define the objective correctly in the first place — connecting business strategy to system design in a way that junior resources and AI tooling both depend on.

The skills to build now — without starting over
For SAP professionals with 10+ years of experience, the path forward is not to abandon functional or technical depth and become a data scientist. It is to layer adjacent capabilities on top of a foundation that already sets you apart.

PRIORITY SKILLS FOR EXPERIENCED SAP PROFESSIONALS
SAP BTP Architecture, Joule / Copilot Configuration, AI Agent Design Patterns, Clean Core Strategy, SAP Datasphere, Integration Suite, Process Mining (Signavio), AI Governance Frameworks, Prompt Engineering for ERP, Change Management for AI

SAP is investing heavily in learning resources through SAP Learning Hub, the AI Skills initiative, and the BTP certification track. For experienced professionals, 6–12 months of deliberate upskilling in even two or three of these areas materially repositions your market value.

What this means for the market over the next 3 years
Demand for transactional SAP configuration work will soften. Demand for advisory, architecture, and AI-augmented programme leadership will increase sharply. The consulting firms and clients who recognise this first will move quickly to secure experienced professionals who bridge both worlds.

The autonomous enterprise is not a future state. RISE with SAP clients are already running Joule in production. Early adopters are piloting autonomous finance closing. The window to position yourself ahead of this curve — rather than react to it — is open now, and it will not stay open indefinitely.

A final thought
Every major SAP transition — R/3 to ECC, ECC to S/4HANA, on-premise to cloud — created a generation of consultants who thrived by leaning into the change rather than defending the past. The autonomous enterprise transition will do the same. The consultants who won the cloud migration era were not those who knew the most about legacy ABAP. They were the ones who could look a CFO in the eye and say: “Here is what we keep, here is what we retire, and here is how we get you to clean core without stopping the business.” That skill — translating technical complexity into business confidence — is exactly what the autonomous enterprise demands next. The question is not whether AI will change what SAP consultants do. It will. The question is whether you will be the person helping clients navigate that change — or the person being navigated around.