SAP S/4HANA Migration Checklist — Printable, Role-Assigned

An SAP S/4HANA migration checklist is the structured pre-flight list of every prerequisite, decision, artifact, and approval that has to be in place before extraction begins, before transformation runs, before any FBDI hits Fusion ESS, and before cutover weekend starts. The reason it matters is the cost asymmetry: a missing HANA database user provisioning can be fixed in two hours during planning, or it can blow up a six-figure SI rate-card on cutover Saturday. Syntra ETL's SAP S/4HANA migration checklist is the consolidated playbook from every S/4HANA-to-Fusion conversion we've run — covering RISE-vs-on-prem authorisation differences, ABAP/CDS inventory artifacts, Fusion target-environment readiness, sign-off gates per workstream, and the rollback decision tree. It's printable, it's role-assigned, and every line item has a defined evidence artifact.

For on-prem S/4HANA: a read-only HANA database user with SELECT on schema SAPHANADB (or your custom schema), no DDL or DML privileges, no procedure execution privileges. Network access from the Syntra ETL extraction node to HANA port 30015 (or 315 for tenant database NN) — typically via a jump host or VPN. For RISE with SAP Cloud Private Edition: HANA DB access is normally not granted, so you provision CDS view authorisations and OData service consumer credentials instead — the SAP_BC_DWB_WBO_USER role or equivalent, plus communication-system + communication-arrangement setup for OData. The SAP S/4HANA migration checklist captures the exact authorisation objects, role names, and SAP Note references for each scenario so your Basis team has a single artifact to action.

Materially. On-premise S/4HANA gives you direct HANA database access, Basis team control over the system, full ABAP authorisation flexibility, and unrestricted batch-window scheduling — the checklist focuses on HANA SQL extraction performance tuning and managing the production batch window. RISE with SAP Cloud Private Edition restricts DB access and forces CDS/OData extraction, so the checklist is dominated by communication-system setup, OData service activation (TCODE /IWFND/MAINT_SERVICE), and SAP-managed change windows. S/4HANA Cloud Public Edition adds further restrictions: no batch window control at all, limited CDS view extensibility, and API call throttling — so the checklist front-loads API quota agreements with SAP and partitions extraction across multiple service users to maximise parallelism.

Before transformation design starts, you need a complete inventory of ABAP customisations in the source S/4HANA: every Z*/Y* program in TRDIR, every BAdI implementation in TFDIR, every CDS view extension in DDIC, every enhancement spot, every IDoc partner profile (EDPAR/EDP12), every ABAP CAP service on BTP, and every active SAP Cloud Integration tenant flow. Syntra ETL's discovery engine produces this automatically — it crawls the metadata catalogs, counts execution frequency over the last 12 months (from STAD or SM20 audit log), classifies by business purpose, and recommends Fusion equivalence (native, Page Composer, VBCS, OIC, BI Publisher, or retire). Output is a CSV the migration steering committee uses to make retire-vs-rebuild decisions. Typical S/4HANA installation reveals 35–55% of customisations are unused or duplicates.

Fusion environment readiness has its own block on the checklist: target Fusion pod identified and sized for steady-state plus migration overhead; FSM (Functional Setup Manager) tasks completed for enterprise structures, ledgers, BUs, value sets, and COA segments; user roles provisioned for the migration service account with FBDI/HDL submission privileges; ESS (Enterprise Scheduler Service) job throughput agreed with the Fusion administrator; UCM (Universal Content Manager) account configured for FBDI ZIP upload; SOAP/REST endpoint allow-listing for delta integration; and finally a baseline trial balance of zero confirmed in the target Fusion ledger. Skip any one of these and the first FBDI submission fails with cryptic ESS errors that consume days of triage. The checklist makes them explicit.

There are seven sign-off gates, each with a named owner and a defined evidence artifact: (1) Assessment gate — discovery output, scope agreed, sized estimate accepted; (2) Crosswalk gate — COA mapping signed by CFO/Controller, customer/vendor dedup rules signed by AP/AR leads, item normalisation signed by Materials Manager; (3) Build-complete gate — all FBDI/HDL templates generated and unit-tested; (4) UAT gate — UAT pass rate >98%, defect log triaged, conditional sign-off issued; (5) Pre-cutover gate — final reconciliation of dry-run load to S/4HANA trial balance, rollback procedure tested; (6) Cutover gate — go/no-go call with finance, IT, audit, and business; (7) Stabilisation gate — first close in Fusion completed within target days, sign-off pack to internal audit. The migration checklist embeds the gate criteria so nothing slips.

Yes — this is mandatory for European customers. The German section of the SAP S/4HANA migration checklist covers HGB/AO 10-year retention (Aufbewahrungspflicht §147 AO) including the GoBD-compliant evidence artifacts (machine-readable, immutable, audit-accessible) that must accompany every migrated period; the GDPdU/IDEA export for tax-audit access to the migrated dataset; the BMF audit-trail expectations for opening balances; and the data-protection (GDPR Art. 30) records-of-processing entry for the migration project itself. Additional regulatory blocks cover SOX (US), MiFID II (UK/EU financial services), FDA 21 CFR Part 11 (US life sciences), and BaFin (German financial supervision). Each block lists the evidence artifacts and the responsible role within the customer organisation.

The full checklist runs to 187 line items across 14 sections — but you only ever look at the section you're working on. Each line item has: a unique ID (e.g. CL-EXT-014), a one-sentence statement, an owner role (not name), an evidence artifact (the file/screenshot/sign-off that proves it's done), a status (Not Started / In Progress / Blocked / Complete), and a target date relative to cutover (T-90, T-30, T-7, T-0, T+7). The checklist is rendered as a printable PDF (for offline review during cutover weekend when systems may be unavailable), tracked in the migration steering committee's project tool of choice (Jira, MS Project, Smartsheet), and reviewed weekly with a fixed dashboard format. Done right, the checklist is the migration's single source of truth.