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.