Most S/4HANA go-live checklists are project management artifacts: task owners, completion dates, sign-off columns. They track whether things were done. They do not verify whether the system is actually healthy at each stage of the migration.
This checklist is different. Each of the 20 points below is a monitoring-specific validation: something you confirm by looking at actual system data, not by marking a task as complete. Ten points apply before the technical cutover. Ten apply in the hours and days after go-live. Together they cover the conditions that cause the most common post-migration incidents.
The points are ordered within each phase by risk, not by effort. The ones at the top are the ones where the cost of missing them is highest.
Before go-live: 10 monitoring validations to complete before the cutover window opens
These 10 points should be signed off during the project phase, not during cutover weekend. Several of them require weeks of lead time to execute properly.
01 Source system baseline captured over at least 6 weeks
Connect your monitoring platform to the ECC or legacy S/4HANA system no later than 8 weeks before the planned go-live. Collect dialog response times by transaction code, background job runtimes, HANA or database performance metrics, and interface throughput volumes.
Six weeks is the minimum because you need at least one complete month-end cycle in the baseline data. Month-end workload in ECC is often 30 to 50% heavier than daily operations. If your baseline only covers normal days, your post-migration comparison will flag month-end performance as a regression when it is actually expected behavior.
Why it matters: Without a source system baseline, post-migration performance discussions are subjective. Every conversation becomes an opinion. With baseline data, every conversation has numbers.
02 HANA sizing validated under UAT load, not just initial sizing estimate
The initial HANA sizing for S/4HANA is based on ECC data volume and estimated user load. UAT is the only environment where actual S/4HANA workload runs before go-live. Run a load test during UAT that reflects peak production conditions and capture HANA memory utilization at peak.
If HANA memory during UAT load testing exceeds 75% of the allocation limit, the production system is undersized relative to the workload it will receive. Undersizing discovered during UAT can be corrected before go-live. Discovered during the first production month-end, it cannot.
Why it matters: HANA is an in-memory database. Undersizing does not produce gradual degradation. It produces an emergency stop when the allocation limit is reached.
03 Background job schedule documented and independently verified in S/4HANA
Export the complete production job schedule from SM36 in the source system. For every Tier 1 job (business-critical with a hard deadline), verify that the equivalent job in S/4HANA has the correct: schedule variant, server group assignment, predecessor-successor dependency, and output variant.
Verification means opening the job in SM36 on S/4HANA and comparing it line by line against the source documentation. Not asking the person who recreated the jobs whether they did it correctly.
Why it matters: Job recreation errors are the most common source of silent failures in the first weeks after go-live. A job recreated with the wrong server group starts on the wrong instance. A missing predecessor dependency causes two jobs to run simultaneously when they should be sequential.
| Watch out: Jobs with user-specific variants (variants named after a specific SAP user) may not transfer correctly when recreated. If the user account in the target system has a different client or authorization setup, the variant reference will fail silently on first execution. |
04 Interface inventory completed with volume baseline and error rates per interface
Document every production interface that sends or receives data from the SAP system: message type (IDoc, RFC, REST, SOAP), average daily volume, normal error rate, and the business process it supports. For high-criticality interfaces, capture hourly volume patterns across the baseline period.
This documentation has two uses. First, it defines what reconnecting the interfaces after cutover looks like: which ones need to be re-enabled, in what order, and what a successful first message flow confirms. Second, it sets the baseline against which post-go-live interface health is evaluated.
Why it matters: An interface with zero volume after cutover may be working correctly (no messages yet) or may have failed to reconnect. Without a volume baseline for that interface, you cannot tell which one it is.
05 Alert thresholds configured per instance profile, not copied from defaults
Default alert thresholds in any SAP monitoring tool are calibrated for a generic environment. Your S/4HANA environment has a specific HANA memory allocation limit, a specific number of dialog work processes per instance, a specific batch window, and specific interface volumes. Default thresholds will generate false positives in some areas and miss real problems in others.
At minimum, configure thresholds for HANA memory utilization (relative to allocation limit, not total RAM), dialog work process utilization per instance, HANA log volume utilization, background job duration per Tier 1 job, and interface error rates per interface.
Why it matters: Threshold calibration takes half a day. Dealing with alert fatigue from misconfigured thresholds in a go-live week takes considerably longer and often results in real alerts being ignored.
06 ITSM integration tested end-to-end with a real alert, not just configured
Most monitoring-to-ITSM integrations are configured in a test environment and assumed to work in production. The assumptions that typically fail: the production ITSM instance has different API endpoints or authentication than the test instance, the user account configured for the integration lacks permissions in production, or the incident category and priority mappings produce incorrectly classified tickets.
Trigger a real test alert from the production monitoring connection to S/4HANA and verify that a correctly formed incident ticket appears in the ITSM system, with the right category, priority, and assigned team. Then resolve the test incident and confirm the monitoring system reflects the resolution.
Why it matters: Discovering that the ITSM integration is broken during the first production incident adds confusion and delay to an already pressured situation.
07 HANA log volume sized and log backup configuration verified under load
The HANA log volume holds all uncommitted transaction data. When it reaches 100% utilization, the database performs an immediate stop. Log backups free used log segments and keep the volume from filling. The log backup interval must be calibrated to the write throughput of the production workload.
During UAT load testing, monitor the log volume fill rate under peak transaction load. Calculate how quickly the log volume would fill if log backups stopped running for 2 hours. If the log volume would reach 100% in that window, either the log volume needs to be larger or the backup interval needs to be shorter.
Why it matters: Log volume sizing is often copied from ECC sizing documents without accounting for HANA-specific write patterns. It is one of the most common causes of unplanned HANA stops in the first months after go-live.
08 Enqueue Replication Server configuration verified with a simulated failure
If the production S/4HANA landscape has high availability configured, the Enqueue Replication Server (ERS) maintains a copy of the lock table on a secondary instance. The ERS is often configured but not verified: the instance exists, it replicates the lock table, but the Pacemaker integration that promotes it automatically on primary failure has never been tested.
Before go-live, simulate a primary enqueue server failure in the QA or pre-production landscape and confirm that the ERS promotes cleanly, that active user sessions can continue their transactions, and that the promotion completes within the expected time window.
Why it matters: An ERS configuration that has never been tested is an assumption, not a capability. The promotion test takes 30 minutes. An undetected ERS misconfiguration during a production failover event takes considerably longer to recover from.
09 Business process owners have defined and signed off on monitoring acceptance criteria
The SAP Basis team can confirm that HANA is healthy and that dialog response times are within technical norms. That is not the same as confirming that the order-to-cash process is running correctly, that financial postings are completing within the expected window, or that the EDI partner is receiving correctly formed messages.
Before go-live, every Tier 1 business process should have a named process owner, a defined acceptance criterion (“all ORDERS05 IDocs processed within 10 minutes of receipt”), and a confirmation step in the post-go-live runbook where that owner signs off based on actual monitoring data.
Why it matters: Without business-defined acceptance criteria, go-live sign-off is based on technical health metrics that may not reflect whether the business can actually operate on the new system.
10 Cutover runbook includes monitoring checkpoints with named responsible person and pass/fail criteria
A cutover runbook that lists tasks without monitoring checkpoints assumes everything is working unless someone raises a problem. A runbook with monitoring checkpoints builds visibility into the process: at specific milestones, a named person checks a specific metric and confirms it is within the expected range before the next step proceeds.
Monitoring checkpoints to embed in the cutover runbook: HANA memory utilization after data migration completes, log volume utilization at T+2h during cutover, dialog WP availability before opening the system to users, and interface queue depth after reconnection.
Why it matters: Monitoring checkpoints in the cutover runbook are the difference between a cutover where the team is confident the system is ready, and one where it is opened to users and hope becomes the strategy.
After go-live: 10 monitoring validations for the first 72 hours
These 10 points apply from the moment the first business user logs in to the end of the first 72 hours of production operation. Several of them require action within the first hour. None of them should be deferred to the following business day.
11 HANA memory cold-start profile captured and compared against UAT baseline
When the first business users log into S/4HANA after go-live, the system starts loading column store data from disk into memory as queries access it for the first time. This cold-start phase produces a memory consumption trajectory that differs from steady-state operation and from UAT load tests where some data was already warm.
Capture HANA memory utilization at 15-minute intervals for the first 2 hours. If the trajectory suggests memory will exceed 85% of the allocation limit before the working dataset is fully loaded, escalate to the infrastructure team immediately. Do not wait for the 85% threshold to be crossed.
Why it matters: Cold-start memory behavior is the one data point that UAT cannot fully replicate. The first hours of production provide the only opportunity to observe it under real conditions, at a time when you still have infrastructure flexibility to respond.
12 All Tier 1 background jobs verified as having run and completed correctly on day 1
A job that was correctly recreated in SM36 but never ran is not a verified job. On the first business day after go-live, every Tier 1 background job that was scheduled to run should be checked in SM37: status, start time, completion time, and for critical jobs, spool output reviewed for application-level errors.
Pay particular attention to jobs with start-time-based scheduling that were set up before the go-live date. A job configured to run at 06:00 daily starting from a date before go-live may have a missed execution in its history, which some scheduling configurations handle by running immediately on next system start and others ignore entirely.
Why it matters: A Tier 1 job that did not run on day 1 creates a data deficit that compounds. Discovering it on day 3 means three days of data need to be reconciled, not one.
13 Interface reconnection confirmed with first actual message flows, not just connection tests
Interface reconnection after cutover typically involves re-enabling connections that were frozen during the migration window. An SM59 connection test confirms the network path exists. It does not confirm that messages are flowing, that the receiving system is processing them, or that the payloads are being generated correctly under S/4HANA message types.
For each Tier 1 interface, wait for the first real message to be generated after go-live, verify it was dispatched without error (BD87 for IDocs, SM58 for tRFC, integration suite monitor for BTP flows), and confirm the receiving system acknowledged receipt. That first successful end-to-end message is the actual proof of interface health.
Why it matters: Connection tests pass. Message flows fail. The two are not the same confirmation.
| In practice: Interfaces that relied on fixed IP-based routing may route to the ECC IP address after cutover if DNS records or RFC destination configurations were not updated. This produces a successful connection test (the old ECC system still responds) while messages go to the wrong destination. Verify that each RFC destination points to the S/4HANA system, not the legacy one. |
14 Alert routing verified: test alert triggered and received by on-call team within SLA window
Alert configurations that were tested in non-production may route to different teams or channels than intended in production. The on-call contact list may have changed between configuration and go-live. The monitoring system’s outbound email or webhook may behave differently under production network policies.
Within the first 2 hours after go-live, trigger a test alert deliberately: temporarily lower a threshold below current values, confirm the alert fires, confirm it routes to the correct on-call contact via the expected channel (email, SMS, ITSM ticket), and confirm the alert clears when the threshold is restored.
Why it matters: Discovering broken alert routing during the first real incident is not the time to discover it.
15 Dialog response times compared against ECC baseline by transaction code within the first 2 hours
Dialog response times on S/4HANA are often faster than ECC for the same transaction codes, because HANA’s in-memory processing eliminates many of the database read operations that drove ECC response times. When they are not faster, or when specific transactions regress significantly, the cause is almost always one of three things: a missing database statistic on HANA (run UPDATE STATISTICS for the affected tables), a custom ABAP program that was not adapted for S/4HANA data model changes, or a configuration issue in the application layer.
Compare the top 20 transaction codes by usage frequency in the ECC baseline against their response times in the first two hours of S/4HANA production. A regression of more than 50% on a frequently used transaction warrants same-day investigation.
Why it matters: Response time regressions that are not investigated on day 1 become established user complaints by day 3 and escalations by day 5.
16 SM13 update queue checked for failed updates within the first hour of business transactions
Failed update requests in SM13 represent saved transactions whose database writes did not complete. Users received a save confirmation. The data is not in the database. This is a data integrity issue, not a performance issue.
Open SM13 on S/4HANA within the first hour of user activity and filter for error status entries. Any entry requires immediate investigation before the affected user takes further action based on the assumption that their data was saved. Update failures in the first hour of production are often caused by missing authorization in the update user, a configuration difference between the test environment and production, or a custom enhancement that was not tested in the update context.
Why it matters: Update errors discovered 4 hours after they occurred require reconciliation against subsequent transactions that built on the assumption that the save succeeded. Discovered within 30 minutes, they can usually be corrected by simply retrying the update after fixing the root cause.
17 First batch job completion times compared against ECC baseline durations
The first overnight batch run on S/4HANA is the first real test of the batch schedule under production data volumes. Record the actual completion time for every Tier 1 job and compare it against the ECC baseline.
Expect HANA-native jobs to run faster than in ECC, sometimes significantly. Jobs that were designed for ECC but not adapted for S/4HANA may run slower due to compatibility view overhead or data model changes. A job that took 40 minutes in ECC and takes 2 hours in S/4HANA is not a performance regression to accept. It is a technical issue to investigate before the next run.
Why it matters: First-night batch run duration establishes the S/4HANA baseline for future comparisons. If the first run is not measured precisely, any subsequent deviation has no reference point.
18 HANA delta merge backlog checked after the first 48 hours of write activity
The first 48 hours of S/4HANA production generate a wave of INSERT activity: new sales orders, new production orders, new financial postings, all going into tables that were empty or near-empty at go-live. This bulk INSERT activity fills HANA’s delta store faster than in steady-state operation, and if delta merges fall behind, query performance on the affected tables begins to degrade.
After 48 hours, check M_DELTA_MERGE_STATISTICS for a pending merge count and for any merge failures. A delta merge failure count above zero warrants investigation. A growing pending merge queue that is not clearing between merge cycles indicates that the auto-merge configuration is not keeping up with the post-go-live write volume.
Why it matters: Delta merge backlog produces no error, no alert, and no obvious symptom until query plans start choosing suboptimal paths. It is invisible to everyone except the person who knows to look for it.
| Note: HANA database statistics on newly populated tables may also need to be updated after the first 48 hours of data loading. Newly created tables with significant data but outdated statistics produce poor query plans. Running UPDATE STATISTICS on the most-queried tables after the initial go-live data load is standard maintenance that often gets skipped in the cutover checklist. |
19 Business process owners confirm first transactions processed correctly, with data
Technical health metrics confirm the system is running. They do not confirm the system is producing correct business outcomes. By end of business day 1, every Tier 1 business process owner should have reviewed the actual output of their process and confirmed it is correct.
This confirmation is based on data, not on the absence of complaints. The finance team confirms that the first financial postings from the production run show the correct accounts and amounts. The logistics team confirms that the first goods movements posted to the correct storage locations. The procurement team confirms that the first purchase orders created via the EDI interface have the correct vendor and pricing data.
Why it matters: A business process that is running but producing incorrect output is not a healthy go-live. It is a data quality incident that is accumulating damage with every subsequent transaction that builds on incorrect prior data.
20 Monitoring handover document delivered to the operations team before the project team demobilizes
The project team that built the monitoring configuration knows why each threshold was set where it was, which alerts are expected to generate noise during the stabilization period, and which ones require immediate escalation. The operations team that will run the system from month 2 onward does not have that knowledge unless it is documented and transferred.
The handover document should cover: the rationale for each non-default threshold, the list of stabilization-period alerts that should be reviewed and potentially adjusted at day 30, the escalation path for each alert category, and the process for updating baselines when the workload evolves. It does not need to be long. It needs to exist before the project team closes the engagement.
Why it matters: Project teams demobilize. When they do, the institutional knowledge about why the monitoring is configured the way it is leaves with them unless it was written down.
Using this checklist in a real project
Twenty validation points across two phases represent a complete monitoring readiness picture for a S/4HANA migration. In practice, not all of them receive equal attention, and the ones that are most often skipped are the ones that require early action: source system baseline (point 1), HANA sizing under real UAT load (point 2), and alert threshold calibration (point 5).
Those three are worth protecting in the project timeline specifically because their lead time cannot be compressed. A baseline requires weeks of data collection. HANA sizing validation requires a proper UAT load test. Threshold calibration requires the baseline data to be meaningful. Starting all three late produces the situation most S/4HANA teams have experienced: go-live with a monitoring platform that is technically connected but operationally uncalibrated, producing alerts nobody has confidence in.
The 10 post-go-live points are time-sensitive in the opposite direction. Points 11 through 16 need to happen within the first few hours of production operation. Deferring them to “after the rush” means deferring them to after the window where early detection is still preventive. A HANA memory trajectory that is visible at hour 2 is actionable. The same trajectory at hour 8, when it has already produced performance degradation, is reactive.
Both phases, before and after, share the same underlying principle: monitoring that is in place before the event it is meant to detect is monitoring. Everything else is investigation.
Redpeaks supports S/4HANA migrations with agentless monitoring of both source and target systems, pre-migration baseline capture, and post-go-live stabilization dashboards. No transports, no agents, no change management overhead. See how Redpeaks covers S/4HANA migrations.
