Table of Contents
SAP S/4HANA migration in 2026 looks different from the projects run two years ago. AI now does real work inside the programme: custom code remediation, process discovery, data profiling and test generation. SAP made its S/4HANA Custom Code Migration Agent generally available this year, applying ABAP AI to the ECC to S/4HANA migration.
What has not changed is the failure rate. Horváth surveyed 200 SAP customers with revenue above €200 million and found 65% exceeded budget significantly, projects ran on average 30% longer than planned, and 65% reported strong quality deficits. Fewer than one in ten finished on schedule.
Those two facts belong together. AI compresses the mechanical work in a migration. It does not touch the decisions that cause overruns. This article sets out where the gain is real, where it is not, and how to sequence an SAP S/4HANA migration that still has to land before mainstream ECC maintenance ends on 31 December 2027.
What changed in SAP S/4HANA migration in 2026
Three shifts matter for anyone scoping an SAP S/4HANA migration in 2026.
- Custom code remediation stopped being purely manual. The S/4HANA Custom Code Migration Agent works from static analysis findings and proposes remediations for developers to review inside ABAP development tools. On a landscape with tens of thousands of findings, triage that used to consume weeks now runs as a first pass in days. Developers still own every accepted change.
- Clean core moved from advice to prerequisite. SAP’s AI capabilities call standard extension points. Heavy classic modifications block them. Custom code work now decides whether you get the SAP AI agents and AI functionality you are paying for after go-live, which changes the business case for doing it properly.
- The cloud question got a date attached. Customers who want the 1:1 pricing lock for the 2031 to 2033 private edition transition option have to commit before the end of 2026. That turns a technical debate into a commercial deadline inside this financial year.
The failure pattern AI does not fix
Look at where migrations actually lose time. In our experience and in the Horváth data, the recurring causes are scope that keeps moving, data nobody owns, testing that starts late, and a business that is not ready to run the process differently.
None of those are throughput problems. They are decision problems. A code assistant that proposes 3,000 remediations does not tell you whether the 700 custom reports behind them should exist at all. A data profiler that flags 40,000 duplicate vendors does not decide which record survives, or who signs that off.
Automating execution inside an undecided scope produces a faster route to the same overrun. Decide first, then automate what is left. That sequencing is what our SAP advisory team settles before a single object is touched.
Where AI genuinely reduces SAP S/4HANA migration effort
Four areas repay the effort when you apply AI in SAP S/4HANA migration work, in roughly this order of value.
- Custom code analysis and remediation. The largest single pool of manual effort in a brownfield move. AI handles pattern-based remediation and classification at volume, leaving architects to judge the exceptions.
- Process discovery and fit-gap. Process mining on your own execution data shows which variants people actually run, rather than which variants the documentation claims. It shortens design workshops and kills the argument about how the process works today.
- Data profiling and cleansing. Duplicate detection, anomaly flagging and mapping proposals across legacy master data. This is where AI pays twice, once in migration effort and once in the quality of the data your AI agents read after go-live.
- Test generation and regression. Testing is the phase most often compressed when a project slips, and the one that decides how go-live week feels. Generated test cases and regression scripts give you coverage you would otherwise trade away under time pressure.
Documentation is a quiet fifth. Generated configuration and code documentation is usually better than what a delayed project produces by hand, and it is what your support team inherits.
What AI cannot decide for you
Five decisions carry most of the risk in an SAP S/4HANA migration, and all five sit with people.
- Transformation approach. Brownfield, greenfield or selective is a business decision about how much process change the organization can absorb, not an output of a readiness scan.
- Retention and deletion rules. What history moves, what is archived and what is destroyed under DPDP and tax rules is a governance exercise that SAP ILM is built to enforce. Archiving and deletion are different decisions, and getting them wrong is expensive in both directions.
- Master data ownership. Somebody has to own the surviving record and the rules that keep it clean afterwards.
- Cutover risk appetite. Big bang against phased, and what the business will tolerate in the first month.
- Change management. Adoption is the difference between a technically complete migration and a useful one.
AI and human work by SAP S/4HANA migration phase
A simple way to brief a steering committee on where automation applies across an SAP S/4HANA migration:
| Phase | What AI does well in 2026 | What stays human |
|---|---|---|
| Assessment | Custom code scans, usage analysis, readiness findings at scale | Scope decisions and the business case |
| Process design | Process mining, variant discovery, fit-gap candidates | Which variants the business keeps |
| Data | Duplicate detection, anomaly flags, mapping proposals | Retention rules, ownership, sign-off |
| Build | ABAP remediation proposals, code and config documentation | Design authority and review of every change |
| Test | Test case generation, regression scripts, defect triage | Acceptance criteria and business validation |
| Cutover | Reconciliation checks, load monitoring, exception lists | The go or no-go decision |
Data volume is still the lever nothing else replaces
Most of the SAP S/4HANA migration cost nobody budgets for sits in data volume. Every terabyte you carry across costs money three times: in SAP HANA sizing, in the time the conversion and testing cycles take, and in the cutover window. SAP HANA is licensed in step increments, so a system sitting just above a threshold pays for the whole next tier.
AI does not change that arithmetic. Archiving closed history before the move does. On document-heavy landscapes, with years of deliveries, billing documents, change documents and IDocs, the reduction is usually the single largest cost lever available before the project starts.
There is a second benefit that matters more in 2026 than it did in 2024. The data you migrate becomes the data your AI agents reason over. A smaller, governed dataset produces better answers than a large one carrying fifteen years of unowned records.
Brownfield, greenfield or selective: how the 2026 choice differs
The Horváth study found the market split almost evenly: 37% greenfield, 33% brownfield, 31% selective. The useful question is not which is best, but which one your constraints allow.
- Brownfield suits landscapes where the process model is sound and the priority is the deadline. AI-assisted custom code remediation has made this route meaningfully cheaper in 2026, which is its main change this year.
- Greenfield suits organizations that need the process redesign anyway, and mid-market companies that can adopt standard processes on GROW with SAP. This is where three to five month S/4HANA go-lives are realistic.
- Selective transition suits groups carrying a carve-out, a divestment or several company codes on different clocks. It is the most technically demanding route and the one most often underestimated.
DSAG’s 2026 data shows 37% of ECC users planning migration by the end of 2027 and 50% by the end of 2030. The second group is planning to pay the extended maintenance premium, whether or not that has been stated as a decision.
A realistic timeline from here to 2027
An SAP S/4HANA migration of this kind takes 18 to 36 months. Counting back from 31 December 2027, a large enterprise starting assessment after the middle of 2026 is committing to a compressed schedule. The sequence that holds:
- Weeks 1 to 6, assessment. Readiness checks, custom code analysis, data volume and quality profile, and a decision on approach. AI does the scanning. The output is a scope you can cost.
- Months 2 to 4, data preparation. Archiving, retention rules, master data cleansing and ownership assigned. This runs in parallel with design and is the phase most often skipped.
- Months 3 to 12, build and remediation. Configuration, AI-assisted code remediation with developer review, integration and extension work on clean core principles.
- Months 9 to 15, test. Generated regression coverage plus business validation against agreed acceptance criteria. Do not let this phase absorb the slippage