If you're a partner whose customers run SAP, most of them are moving, or soon will be, to S/4HANA, SAP's current system, which runs only on SAP's own database, HANA. Here is the case for not worrying about how that database gets watched once they arrive. It is a good case, and we are going to make it properly before we say what it leaves out.
The case for leaving it alone
The deadline is real, but it bends. SAP ERP 6.0 leaves mainstream maintenance on 31 December 2027. Customers can pay two percentage points more on their maintenance to keep support until the end of 2030, and a narrower option for larger customers on SAP's own cloud runs to 2033. The UK & Ireland SAP User Group (UKISUG) found 31% of the 130 decision makers it asked in 2024 using S/4HANA and 63% planning to, so most of the UK and Irish migration is still ahead, spread over years rather than stacked against a single date.
SAP's own tools see HANA well. The HANA cockpit shows which statements are expensive, how often they ran and what they waited on, and SAP teaches it for exactly that job: finding the root cause. SAP Cloud ALM, its monitoring service, comes with SAP's main support contracts at no extra fee. Customers moving to RISE with SAP, the package in which SAP hosts and runs the system, hand SAP the database itself, including its patching, backups and technical monitoring.
And the database is not where these programmes go wrong. A 2025 survey of 200 executives by the consultancy Horváth found 65% of S/4HANA programmes over budget. The causes they named were scope, project management, testing, data migration and slow decisions. The database was not on the list.
We would make that case to a customer ourselves, and that is the awkward part. Distributors, us included, sell these migrations as an improvement. None of us can show the before and after that would prove it.
What all of that is about
Everything in the case above is about now.
The cockpit, the trace and Cloud ALM are each good at telling a team what HANA is doing today and how that compares with recent weeks. HANA's statistics server keeps most of its history for 42 days by default, which SAP chose so that a team can compare this month with last month. The trace that records expensive statements in detail is off until somebody turns it on.
Now put a migration through that. On the cutover weekend the old system stops, and with it the record of what normal looked like. For a customer coming from another database, HANA's history begins that weekend, because there was no HANA before it. For a customer already on HANA, six weeks of history doesn't reach back across a programme that runs for months.
Six weeks later the programme board meets to close the project. The closure report has a line for performance: does the new system run the business at least as well as the old one? Everyone in the room believes it does. Nobody can show it. The board is an illustration, but the gap in the history is real.
So the migration doesn't stop anyone seeing HANA. It removes the comparison.
Whose question it is
On RISE, that gap has an owner. SAP's published roles and responsibilities give SAP performance troubleshooting where the cause sits within its own service. Analysing problems with "application related root causes" falls to the customer, and one line, BASIC_1.7.08, lists "review and optimize customer code to improve system performance and stability" among the excluded tasks. The service level SAP commits to is 99.7% availability a month, which measures whether the system is up, not how it performs.
None of that is unreasonable, because SAP can't answer for code it didn't write. But it means that if a performance question does come up after go-live, the first thing anyone asks is where the cause sits. The evidence that settles it quickly is a measurement of the same work on the old system, and the customer is the only party placed to keep one.
Before the cutover
The advice is one thing: write down normal before you move.
That means at least one full month-end on the old system, recorded properly. Capture the heaviest statements, where the time goes and how long the jobs that matter take. Switch on what is already included to get it, the expensive-statement trace and longer history retention, and keep the record somewhere the migration won't touch. On RISE, agree with SAP before go-live how a performance question will be answered, and by whom.
There is one more reason to do it, and it is the best one. The record is not insurance against the migration going badly. Nobody has published how the first month-end on S/4HANA compares with the last one on the old system, for better or worse, and no peer-reviewed study has measured it. If the migration went well, the record is how anyone proves it. The programme board signs off its line with a number, and the customer has what this market has never published: a before and after.
The case for SAP's tools was right. It only ever needed something to be measured against.
CMS vendors in this area
- SolarWinds: database performance monitoring, including SAP HANA and HANA Cloud, alongside other database engines in one console.
- Red Hat: Red Hat Enterprise Linux for SAP Solutions, an operating system SAP HANA is supported on.
- SUSE: SUSE Linux Enterprise Server for SAP Applications, an operating system SAP HANA is supported on.
CMS Distribution distributes the vendors listed here. They appear alphabetically, and none paid for placement or reviewed this article.
Maintenance dates are from SAP's announcements of 4 February 2020 and 4 February 2025. Adoption figures are from UKISUG's SAP S/4HANA and RISE Report 2024 (130 UK and Irish decision makers, self-reported). The cockpit's role in root-cause analysis and the expensive-statement trace default are from SAP's HANA monitoring and performance tuning course, and the 42-day default from SAP Knowledge Base Article 2113228. Cloud ALM's inclusion is from SAP's application lifecycle management FAQ. RISE responsibilities, clause BASIC_1.7.08 and the 99.7% figure are from SAP's RISE with SAP S/4HANA Cloud, private edition Roles and Responsibilities (v7-2023) and its contract supplement (v10-2024). The Horváth survey covered 200 executives in six countries in early 2025 and was read through its press coverage. The programme board is an illustration. Figures circulating for ERP failure rates of 70% to 90%, and for performance before and after migration, have no published method and are deliberately absent.
