Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Go/no-go

12 min

Listen to this lesson

0:00 / 12:31

The go/no-go is not one meeting. It is a sequence of decisions, each with agreed criteria, evidence and a deadline that leaves time to fall back. On the weekend, the decision group, chaired by Grace, chooses between options it planned weeks before. If the team is inventing criteria at 2 a.m., the sequence was not designed.

The decision sequence

  1. About a week beforeFinal readiness reviewDress rehearsal passed, defects within limits, business readiness, communications approved
  2. Friday afternoonStart decisionProduction SI-Check clean, backups ready, people in place; the window starts at 18:00
  3. Saturday 18:00Go/no-go 1Technical checkpoint mid-SUM: on plan against Mock 2 timings, no blocking errors; ECC (EP1) still intact
  4. Sunday 14:00Go/no-go 2Post-processing done, finance reconciliations signed, core smoke tests passed; continue to business validation and ramp-up
  5. Monday 06:00Point of no returnUsers and interfaces live; fix forward from here
Contoso's go/no-go sequence for the conversion weekend.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-303

The deadlines come from the fallback time. A DMO-based conversion leaves the source database unchanged until the end, which makes fallback possible: restore the pre-cutover state, reopen ECC, re-point interfaces. Mock 2 measured that at nine hours. So the last decision that still allows a clean fallback before Monday 06:00 must come well before Sunday 21:00; with a three-hour margin, the latest fallback start is Sunday 18:00. Go/no-go 2 at Sunday 14:00 leaves four hours before it.

Work the timeline backward when you design the sequence. Contoso's point of no return is Monday 06:00, when interfaces to the carrier and the bank switch over and the first shipments leave. Fallback takes nine hours, and Luis adds a safety margin for the decision itself and the call to executives. That gives a latest fallback start on Sunday evening. Go/no-go 2 sits several hours earlier so that a failed reconciliation or smoke test can still be fixed and re-tested once before the deadline. Go/no-go 1 sits mid-SUM, so a conversion running behind its Mock 2 timings, or hitting blocking errors, is caught while ECC (EP1) is still intact and stopping is cheap.

The weekend worked backward from Monday 06:00: a nine-hour fallback must start by Sunday evening, so go/no-go 2 sits at 14:00 and go/no-go 1 at Saturday 18:00.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-303

Criteria and evidence

Decision pointCriteriaEvidence
Start decisionReadiness review actions closed; final SI-Check without blocking errors; team and backups readyChecklist signed by Luis and Sam
Go/no-go 1SUM on plan against Mock 2 timings; no blocking errors; contingency left; EP1 intact for fallbackSUM progress and log summary, runtime compared with Mock 2, from Sam
Go/no-go 2Post-processing and finance migration complete; reconciliations at zero; core smoke tests passed; no open critical defectsReconciliation file signed by Dan, smoke test results from Priya, open issue list

What each decision requires at Contoso.

  1. Are all criteria for this point met?Yes → go to the next stage · No → next question
  2. Can the gap be closed before the next decision deadline?Yes → fix, re-prove, continue · No → next question
  3. Is the remaining risk contained, with a workaround, owner and date?Yes → go with conditions, recorded · No → fall back while fallback is still possible
The decision logic at each go/no-go point.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-303

Fallback mechanics

With DMO, SUM copies data into the new SAP HANA database and leaves the application data in EP1's source database unconverted, so EP1 is the fallback. SAP describes SUM's RESET function as the way back; once downtime has started, follow the SUM guide for your version and Sam's tested procedure, and restore from the backup only if the source has changed. Fallback is more than a database step. Contoso's nine-hour fallback measured in Mock 2 covers all of this:

  1. Grace's decision group decides to fall back no later than Sunday 18:00; Luis sends the pre-written fallback message.
  2. Sam stops SUM and sets the target CMP aside, so no user or interface can reach it.
  3. Sam reopens ECC on EP1; Dan re-runs the before picture to prove balances and open items are unchanged.
  4. Theo re-enables the PO channels on XP1 toward EP1 and releases held messages in order.
  5. Sam releases the suspended jobs with BTCTRNS2 in the documented order; Nadia unlocks users.
  6. Orders from the manual order log are entered in ECC; customers and suppliers get the new plan.
Two ways out of go/no-go 2: continue to ramp-up and hypercare, or a fallback that must start by Sunday 18:00 to finish before Monday 06:00.
The Sign-Off Table · thesignofftable.com/academy/sap-s4t-303

Running the meeting

  • Show the criteria and the evidence against each, not opinions.
  • Show contingency used and remaining, and the time left before the latest fallback start.
  • Each process owner confirms their area aloud and in writing.
  • Record the decision, any conditions with owner and date, and who decided.
  • Send the pre-written message within minutes.

What would you do?

At go/no-go 2 on Sunday 14:00, all reconciliations are at zero except customer open items in company code 1810, which differ by 14 items. The team believes a report variant is wrong and needs two hours to confirm. Contingency remaining is three hours. What should the decision group do?

Handing over to hypercare

At Monday 06:00 the cutover ends but the risk does not. Luis hands over to hypercare with a short pack: the runbook log with actual times, every "go with conditions" item with its owner and due date, the open defects in SAP Cloud ALM, deviations from the runbook, and the contingency used. Contoso staffs the hypercare desk from 05:30 to 22:00 for the first two weeks to match the Detroit shifts and plans six weeks of hypercare, so it covers the first period-end close; exit is decided by criteria, not by the calendar.

Monitoring moves to SAP Cloud ALM for operations: Business Process Monitoring for the first orders, deliveries and invoices, Integration and Exception Monitoring for the interfaces and IDocs still running on PO, Job and Automation Monitoring for the restarted job schedule, and Health Monitoring for CMP. Luis stays on as release manager and runs the production imports for hypercare fixes.

Key points
  • Go/no-go is a sequence: readiness review, start decision, go/no-go 1, go/no-go 2, point of no return.
  • Deadlines come from measured fallback time; Contoso's is nine hours.
  • Each point has agreed criteria and evidence; owners confirm in writing.
  • Options at each point: go, fix and re-prove, go with recorded conditions, or fall back in time.
  • Fallback = stop SUM, set CMP aside, reopen EP1, re-enable interfaces and jobs; handover to hypercare with conditions, defects and the runbook log.

Check your understanding · not graded

Lesson check

  1. 1. Where do go/no-go deadlines come from?

  2. 2. What is decided at Contoso's go/no-go 2?

  3. 3. What is the point of no return on Contoso's weekend?

  4. 4. A criterion is unmet but can be proven within contingency. Best action?

  5. 5. Which item belongs in Luis's handover pack to hypercare on Monday morning?