The S/4HANA migration cutover orchestration that runs to plan — HANA quiesce window, ACDOCA delta capture, period close sync, freeze + delta-replay, signed reconciliation pack, four go/no-go gates, full rollback procedure tested in dress-rehearsal. 48–60 hour standard pattern.
Everything that was abstract becomes concrete: real journals, real balances, real users, real audit signatures. And the rollback window narrows by the hour.
The migration cutover is where months of design, build, and dry-run work meet production reality for the first time. Up until cutover Friday at 18:00, every load was a test load, every reconciliation was a dry-run reconciliation, and every variance could be fixed in a follow-up sprint. After cutover Friday at 18:00, every minute that S/4HANA stays quiesced is a minute of business impact, every error in Fusion is a real-money error, and the rollback window narrows toward irreversibility.
Syntra ETL's SAP S/4HANA migration cutover orchestration treats this 48-hour window as the operational climax of the project, not as 'just another load.' Every step is choreographed in an hour-by-hour cutover script with named role per task. Every decision is gated by an explicit go/no-go criterion. Every reversal scenario has a documented procedure that was tested in the T-7 dress rehearsal — never tested for the first time on cutover Saturday.
The orchestration covers the technical workstream (extract, transform, load, reconcile) and the organisational workstream (communications, user lockout, integration drain, war-room logistics) in a single integrated plan. The named war-room roles include the cutover director, finance lead, IT operations lead, Fusion administrator, audit observer, and the on-call escalation matrix to the CFO and CIO if a gate fails.
Friday 18:00 to Sunday 22:00. Four go/no-go gates. Named owner per task. Printable cutover script on the war-room wall.
SAP user lockout (SU01 mass-lock), batch jobs suspended (SM37), IDoc inbound queues paused, external interface inbound paused. In-flight integration drain begins. War room declared active. Communication plan to user community sent.
ACDOCA delta extract from last dry-run watermark to T+0 cutoff. CDPOS/CDHDR master-data deltas captured. Open AP/AR deltas captured. Asset transaction deltas captured. Manifests assembled and hashed.
FBDI/HDL submission to Fusion ESS. Suppliers, customers, items first; then COA balances; then open transactions; then assets. Each load monitored to completion with error capture per row.
First go/no-go: delta extract reconciled to last dry-run baseline. If pass → proceed to bulk reconciliation; if fail → extend quiesce or rollback decision.
Full reconciliation pack generated: trial balance per BUKRS-to-BU per period, AP/AR aging per vendor/customer, asset register per asset per book, multi-currency views, parallel ledger views. PDF + CSV bundle ready.
Second go/no-go: reconciliation pack reviewed and signed by finance lead + audit observer. Variance threshold: 0.00. If pass → proceed to UAT; if fail → variance investigation or rollback decision.
Critical-process smoke test in Fusion: post a journal, pay an invoice, run a depreciation, generate trial balance, run a Fiori-equivalent OTBI dashboard. Named business users execute against scripted scenarios.
Third go/no-go: UAT smoke test passed end-to-end, OTBI reports validated, integration re-points tested. If pass → traffic cut to Fusion, S/4HANA flipped to archive-only; if fail → soft rollback to S/4HANA.
Fourth go/no-go: 8-hour bake-in with live users on Fusion, no critical defects, monitoring stable. If pass → cutover formally complete, hypercare begins. If fail → discuss escalation path with CFO/CIO.
The cutover director coordinates six parallel work streams across the 48–60 hour window. Each stream has a named lead and a dedicated war-room channel.
Extract, transform, load, reconcile — the platform workstream led by the Syntra ETL migration engineer. Owns delta extract, FBDI/HDL submission, error triage, reconciliation pack generation.
Trial balance sign-off, AP/AR aging validation, asset register review, period-close synchronisation. Led by the controller. Owns the financial reconciliation acceptance.
IDoc partner re-point to OIC, REST endpoint switchover, file-feed redirection, EDI-trading-partner notification. Led by integration architect. Owns in-flight message handling.
User lockout management, communication cadence (Friday lockout, Saturday update, Sunday all-clear), training reinforcement, support-ticket triage. Led by change management.
OTBI dashboard validation, BIP report execution, FRS report verification, Smart View Excel-tethering test. Led by analytics lead. Owns business-user reporting acceptance.
Reconciliation pack review, evidence artifact archival to immutable storage, sign-off matrix completion, BMF/HGB/AO documentation. Led by audit observer. Owns regulatory sign-off.
Three rollback scenarios. Decision criteria explicit. Procedures documented. Tested before cutover Saturday — never first-attempted live.
Active until Gate 2 (reconciliation sign-off). Trigger: material variance can't be resolved within cutover window. Action: reverse user lockout in S/4HANA, resume batch jobs, release IDoc queues, restore production traffic. Hold Fusion in pre-prod state. Re-attempt cutover following weekend.
Active between Gate 2 and the end of stabilisation week 1. Trigger: material problem discovered after some Fusion transactions exist. Action: extract Fusion-side transactions back into S/4HANA via REST → IDoc bridge, restore S/4HANA production, decommission Fusion temporarily. Most painful path; rarely required.
Past Gate 4 + 24 hours of stable Fusion operation. Organisation commits to fix-forward in Fusion. Any defects resolved within Fusion, not by reverting. Audit and finance sign off on this commitment in advance during T-14 governance review.
Full cutover sequence executed end-to-end in non-prod: HANA quiesce simulation, delta extract, FBDI load, reconciliation, UAT smoke. Soft rollback procedure executed and timing measured. Hard rollback procedure validated on a subset. Findings logged and addressed before cutover.
SAP S/4HANA migration cutover is the orchestrated weekend (or extended weekend) sequence that takes the source S/4HANA from full-production state to archive-only state, captures the final delta of activity since the last dry run, replays it into Oracle Fusion, runs the final reconciliation, and flips production traffic to Fusion. The work is heavily choreographed: HANA quiesce window, BSEG/ACDOCA capture, period close synchronisation, freeze + delta-replay, final reconciliation pack generation, sign-off, traffic cut, and the rollback decision tree at every checkpoint. A typical mid-to-large S/4HANA cutover runs Friday 18:00 to Sunday 22:00 — about 52 hours — with go/no-go decision points every 6–8 hours and a documented rollback to S/4HANA if any gate fails.
The HANA quiesce window is the period where S/4HANA stops accepting new transactional postings so the delta capture and final reconciliation can run against a stable database state. Mechanically: at T-0 hour, SAP user lockout is applied (SU01 mass user-lock or session termination via SM04), batch jobs are suspended (SM37 hold), inbound IDoc processing is paused (WE05 status updates), and external interface inbound queues are paused. The application is now in maintenance mode. The HANA database itself stays online — quiesce means application-layer stop, not database stop. Inside the quiesce window the delta-capture extract runs against ACDOCA and any change-driven tables, the final reconciliation pack is assembled, and the go/no-go call happens. Typical quiesce window: 6–10 hours for a mid-size company-code list.
Between the last dry-run extract (typically T-7 days before cutover) and the final cutover extract, new postings accumulate in S/4HANA — typically 5–15% of average daily volume per day depending on month-end timing. Delta capture uses three mechanisms in order of preference. First: CDPOS/CDHDR change documents that S/4HANA maintains automatically for master-data changes. Second: ACDOCA timestamp watermarks — every universal-journal row carries CPUDT (entry date) and CPUTM (entry time), allowing high-water-mark extraction since the last run. Third: SLT (SAP Landscape Transformation) replication if it's already deployed in the landscape — this captures every changed row in near-real-time. Syntra ETL picks the best mechanism per table based on what's available, runs the delta extract, transforms via the established crosswalks, and replays into Fusion via REST APIs (faster than re-running full FBDI for incremental volumes).
The period close synchronisation issue arises because S/4HANA and Fusion both have period-close mechanics that can lock postings if a period is closed. The cutover plan has to ensure the right periods are open and closed in both systems at the right moments. Best practice: schedule cutover for the first weekend of a new fiscal period so the prior period is fully closed in S/4HANA (CL_PERIOD CO and FI both closed via OB52 / KP90) before cutover begins; the current period is open in S/4HANA only during the quiesce window for unavoidable accruals; and Fusion's current period is open ready for the final load. The opening trial balance loaded into Fusion is the closing balance of the prior period in S/4HANA — so the reconciliation is against a fixed, signed, closed period. This is the cleanest pattern; mid-period cutovers are possible but add reconciliation complexity around in-flight transactions.
The rollback plan is the documented procedure that reverts back to S/4HANA-only operation if a cutover gate fails. There are three rollback scenarios. Soft rollback (T+0 to T+24h): final reconciliation shows a material variance that can't be resolved within the cutover window, so traffic is restored to S/4HANA (user lockout reversed, batch jobs resumed, IDoc inbound queues released), Fusion is held in pre-production state, and the variance is investigated for a re-attempted cutover the following weekend. Hard rollback (T+24h to T+72h): material problem discovered after some Fusion transactions have been entered post-cutover, requiring extraction of those Fusion transactions back to S/4HANA — most painful, rarely required. No rollback (T+72h+): past the no-return point, organisation commits to fix-forward in Fusion. The rollback plan is tested in dress-rehearsal during T-7 dry run — never test rollback for the first time on cutover Saturday.
Go/no-go decisions happen at four checkpoints. Checkpoint 1 (end of HANA quiesce, T+6h): is the final delta extract complete and reconciled to the last dry-run baseline? If yes, proceed to load; if no, extend quiesce or rollback. Checkpoint 2 (end of bulk load, T+18h): are all FBDI/HDL submissions complete with error count below threshold? If yes, proceed to reconciliation; if no, triage errors. Checkpoint 3 (end of reconciliation, T+30h): does the reconciliation pack show zero unexplained variance per BU per period? If yes, proceed to UAT smoke test; if no, escalate variance or rollback. Checkpoint 4 (end of UAT smoke test, T+42h): do critical business processes work end-to-end in Fusion (post a journal, pay an invoice, run a depreciation, generate trial balance)? If yes, traffic cut to Fusion; if no, soft rollback to S/4HANA. Each checkpoint has named decision-makers from Finance, IT, and Programme.
In-flight integration messages are messages already in motion between S/4HANA and upstream/downstream systems at the moment of cutover. Examples: an IDoc emitted by S/4HANA at T-1h but still being processed downstream; a payment file generated by F110 but not yet acknowledged by the bank; an EDI 850 inbound from a customer that hasn't been processed into a sales order; a goods receipt posted into MIGO but not yet released for invoicing. The cutover plan handles each integration category with an explicit pattern: drain (complete in-flight before quiesce), bridge (capture in-flight in a staging area and replay into Fusion post-cutover), or freeze (hold inbound externally with upstream-system notice). The integration inventory captured during T-90 planning lists every integration with its category. No integration is left unaddressed.
Typical S/4HANA migration cutover runs 48–60 hours for a mid-to-large customer. The standard sequence: Friday 18:00 — HANA quiesce begins, user lockout applied, in-flight integrations drained. Friday 22:00 — final delta extract complete. Saturday 02:00 — bulk FBDI/HDL loads underway. Saturday 14:00 — reconciliation pack generation. Saturday 18:00 — first go/no-go checkpoint passed, UAT smoke testing begins. Sunday 06:00 — reporting layer validation (OTBI dashboards, BIP reports). Sunday 14:00 — final go/no-go, traffic cut to Fusion. Sunday 18:00 — S/4HANA flipped to archive-only mode, monitoring transitions to Fusion-primary. Sunday 22:00 — formal cutover declared complete, hypercare begins. Smaller customers (single BU, single ledger) can complete in 24–36 hours; multi-pillar global rollouts can extend to 72 hours.
Book a 30-minute call. We'll walk through the hour-by-hour cutover script, the four go/no-go gates, the rollback decision tree, and the war-room logistics — and adapt it to your S/4HANA topology and Fusion target.