Go live readiness

SAP Go-Live Readiness Assessment

This skill enforces evidence-based go-live approval — blocking the "everything looks good" declaration and replacing it with a mandatory, dimension-by-dimension readiness checklist where every Green status requires attached evidence, not assertion.

---

Iron Laws

1. NEVER DECLARE "GO-LIVE READY" WITHOUT COMPLETING EVERY CHECKLIST ITEM. Partial readiness is not readiness. A system that is 95% ready is not ready. Missing items are documented risks, not excuses to proceed.
2. RED STATUS ITEMS BLOCK GO-LIVE — NO EXCEPTIONS, NO OVERRIDES. A Red item means the condition is unmet. No business pressure, no timeline argument, and no seniority overrides a Red status. Red = stop.
3. EVERY READINESS CLAIM MUST HAVE ATTACHED EVIDENCE, NOT ASSERTION. "Training is complete" is an assertion. A signed training attendance register is evidence. "Data is loaded" is an assertion. A business-approved reconciliation report is evidence.
4. NEVER SKIP BUSINESS SIGN-OFF ON DATA MIGRATION RECONCILIATION. Business owners — not technical teams — must confirm that migrated data is correct. A Basis consultant saying "data looks good" is not business sign-off.
5. GO/NO-GO DECISION REQUIRES NAMED DECISION-MAKERS, NOT CONSENSUS. The decision must be owned by identified individuals who are accountable for it. "The team agreed" is not a Go/No-Go decision.
6. AMBER STATUS REQUIRES FORMAL RISK ACCEPTANCE BEFORE PROCEEDING. An Amber item with no documented risk acceptance is a hidden Red. Every Amber must have a named risk owner, a mitigation action, and a written acceptance.

---

Rationalization Table

Agent Will Try To...	Why It Seems Reasonable	Why It Fails	Counter
Declare readiness based on gut feel	"The team has been working hard and things feel solid"	Go-live failures are not caused by team effort — they are caused by specific unmet conditions that feeling cannot detect.	Iron Law 1: Every dimension must be assessed on its checklist, not on team confidence.
Skip the security readiness dimension	"Security was handled during configuration; it's not a go-live item"	Role assignments frequently have errors discovered only at go-live. SoD conflicts undetected pre-go-live become audit findings post-go-live. Auth errors are the number one cause of day-one user escalations.	Checklist Step 6: Security readiness is a mandatory dimension with its own evidence requirements.
Accept "training is complete" without evidence	"The training team said it's done"	Training completion without attendance records means unknown users are untrained. Untrained users = day-one call volume spike and business process errors.	Iron Law 3: Training sign-off requires attendance register and assessment results.
Mark integration readiness Green without end-to-end test results	"The interfaces worked in the test system"	Test system interface configuration differs from production. DNS, RFC endpoints, credentials, and certificates change at cutover. Production integration must be tested post-cutover, not pre.	Checklist Step 5: Integration readiness requires production test results, not test-system results.
Allow Amber items to proceed without documentation	"We'll track them in the issues list"	An undocumented Amber is a concealed risk. If it materializes post-go-live, there is no record of the risk acceptance decision or who made it.	Iron Law 6: Every Amber requires written risk acceptance with named owner before proceeding.
Treat Go/No-Go as a project manager decision alone	"The PM owns the go-live decision"	Go-live decisions require functional sign-off (business), technical sign-off (Basis/architecture), and executive sign-off (sponsor). A PM cannot waive functional or technical readiness.	Iron Law 5: Named decision-makers across all three dimensions.
Skip performance verification because "SAP handles it"	"The system is SAP — it performs"	Custom Z-programs, background jobs, and reporting queries are not SAP standard. Volume testing results in ST05/ST12 must be confirmed against defined SLAs.	Checklist Step 1: Performance verification is evidence-based, with tcode-level monitoring data attached.
Rely on hypercare to catch what was missed	"If something breaks, hypercare will fix it"	Hypercare handles issues that arise from live use, not from unmet readiness conditions. Invoking hypercare as a substitute for readiness is a project governance failure.	Red Flag counter: Readiness gates exist precisely so hypercare is not used as a quality substitute.

---

Red Flags

Watch for these phrases in your own reasoning — each signals an Iron Law violation:

• "I believe we're ready..." → Belief is not evidence. Show the checklist with evidence attached. Stop.
• "Everything looks good..." → "Looks good" is not a readiness status. RAG status per dimension is a readiness status. Stop.
• "We can fix it after go-live..." → Post-go-live fixes under production pressure cost 10x more and create business disruption. Document it as a Red or formal risk — do not proceed silently. Stop.
• "It should work in production..." → Should is not evidence. Test it in production after cutover and confirm it does work. Stop.
• "The team is confident..." → Team confidence does not replace a signed checklist. Stop.
• "We're close enough..." → There is no "close enough" gate in this skill. Every item is met or it is not. Stop.
• "We'll track the outstanding items as hypercare tasks..." → Hypercare is for live issues, not for unmet go-live conditions. Stop.
• "Security roles were done months ago, they're fine..." → Role assignments and SoD checks must be re-verified on the production system post-transport, not assumed from configuration activity. Stop.

---

<HARD-GATE> Go/No-Go decision CANNOT be issued as GO until: 1. All six readiness dimensions (Technical, Functional, Organizational, Data, Integration, Security) have been assessed 2. Zero Red items remain across all dimensions 3. Every Amber item has documented risk acceptance with a named risk owner 4. Business sign-off on data migration reconciliation is in hand (signed document) 5. Named decision-makers across technical, functional, and executive dimensions have all individually confirmed Go 6. The signed Go/No-Go decision record is completed with names, roles, and timestamp If any condition is unmet, the status is NO-GO. Do not issue a Go recommendation. Escalate unresolved Reds immediately. </HARD-GATE>

---

Checklist

1. Technical Readiness — Verify system performance, monitoring, backup, and disaster recovery.

   • System performance verified via ST03N (workload monitor): response time within SLA for critical transactions
   • Background job schedule confirmed in SM36; all production batch jobs scheduled and tested in SM37
   • System monitoring configured: CCMS alerts (RZ20), system log monitoring (SM21), ABAP dump tracking (ST22)
   • Backup and recovery tested: last successful backup confirmed, restore test completed with documented RTO
   • Disaster recovery plan in place with documented RTO/RPO and named DR coordinator
   • Transport landscape locked: production client open only for authorized transports; no debug-and-change (S_DEVEL restriction in PFCG confirmed)
   • Evidence: ST03N screenshot, SM37 job list, RZ20 alert configuration screenshot, backup log, DR plan document
   • Gate: All technical items Green or Amber with documented risk acceptance

2. Functional Readiness — Verify all test scenarios passed, training complete, and user documentation available.

   • UAT sign-off document in hand (from testing-strategy skill output)
   • Zero open P1 defects; all P2 defects resolved or formally risk-accepted
   • End-user training completed: attendance register signed, assessment pass rates documented
   • User guides and job aids published and accessible to business users
   • Super-user network identified and briefed: key users per module named and available for day-one support
   • Evidence: Signed UAT sign-off, defect log showing zero P1, training attendance register, user guide publication confirmation
   • Gate: All functional items Green or Amber with documented risk acceptance

3. Organizational Readiness — Verify support model, hypercare plan, and escalation paths.

   • Support model documented: who handles P1/P2/P3/P4 issues post-go-live, with names and contact details
   • Hypercare plan ready: war room location/bridge, shift schedule, escalation matrix, exit criteria defined
   • Escalation path documented for each module area: functional consultant → solution architect → client IT manager
   • Business process owners briefed and available during go-live week (no planned leave on Day 1-5)
   • External support agreements confirmed: SAP Support (OSS) licence active, BASIS support contract active
   • Evidence: Hypercare plan document, support model org chart, escalation matrix, OSS access confirmation
   • Gate: All organizational items Green or Amber with documented risk acceptance

4. Data Readiness — Verify migration complete, reconciled, and formally accepted by business.

   • All data objects (master data and transactional data in scope) migrated to production
   • Reconciliation report produced comparing source system record counts to SAP load counts
   • Business data owners have reviewed and signed off on the reconciliation report — not the technical team
   • Data quality exceptions documented and formally accepted or remediated
   • Reference data (number ranges via SNRO, fiscal year settings via OB52, plant parameters) verified in production
   • Evidence: Migration load logs, reconciliation report with business signature, number range screenshot from production
   • Gate: Business-signed reconciliation report in hand. If unsigned, status is Red.

5. Integration Readiness — Verify all interfaces tested end-to-end in production and partner confirmations received.

   • All interface connections verified in production via SM59 (RFC), SXMB_MONI (PI/PO message monitor), or equivalent
   • End-to-end integration test executed in production post-cutover for all critical interfaces (not test system results)
   • EDI trading partner confirmations received in writing for all B2B interfaces
   • Error handling and alerting configured for each interface: SXMB_MONI alert rules, BTP integration monitoring
   • Idoc reprocessing procedure documented and tested (BD87 for inbound, WE19 for outbound reprocessing)
   • Evidence: SM59 connection test screenshots, SXMB_MONI clean message log, partner confirmation emails, error handling procedure
   • Gate: All interfaces showing Green in production. No interface left as "will test after go-live."

6. Security Readiness — Verify roles assigned, SoD clean, and audit logging enabled.

   • All production user accounts created and roles assigned in production system (SU01 / SU10)
   • Role assignments transported from quality to production and verified — not assumed from transport log
   • SoD conflict check run using GRC Access Control or manual SUIM analysis; all critical conflicts resolved or formally mitigated
   • Audit logging enabled (SM19 / RSAU_CONFIG): security audit log active with appropriate filter for critical events
   • Firefighter / emergency access IDs configured and tested (GRC EAM or manual procedure)
   • Default SAP* and DDIC passwords changed in all clients; production client locked for SAP* login
   • Evidence: SU01 user list with role assignments, SoD conflict report showing zero unmitigated critical conflicts, SM19 active audit log screenshot
   • Gate: All security items Green. SoD conflicts with no mitigation = Red. No exceptions.

---

Deliverable Template

Go-Live Readiness Assessment — RAG Decision Matrix

GO-LIVE READINESS ASSESSMENT
Project: [Name]  |  Assessment Date: [Date]  |  Planned Go-Live: [Date]
Assessed by: [Name, Role]

DIMENSION SUMMARY
-----------------
Dimension         | Status | Evidence Ref        | Risk Owner (if Amber) | Notes
------------------|--------|---------------------|----------------------|-------
Technical         | [R/A/G]| [Doc ref]           | [Name if Amber]      |
Functional        | [R/A/G]| [Doc ref]           | [Name if Amber]      |
Organizational    | [R/A/G]| [Doc ref]           | [Name if Amber]      |
Data              | [R/A/G]| [Doc ref]           | [Name if Amber]      |
Integration       | [R/A/G]| [Doc ref]           | [Name if Amber]      |
Security          | [R/A/G]| [Doc ref]           | [Name if Amber]      |

OVERALL STATUS: [RED — Do Not Proceed | AMBER — Conditional Proceed | GREEN — Proceed]

OUTSTANDING RED ITEMS
---------------------
[List each Red item with: Dimension | Item | Owner | Resolution Required By]

AMBER RISK ACCEPTANCES
----------------------
[List each Amber item with: Dimension | Item | Risk Owner | Acceptance Date | Mitigation]

GO/NO-GO DECISION RECORD
-------------------------
Functional Sign-Off:   [Name, Role] — [ ] GO  [ ] NO-GO — Date: ___
Technical Sign-Off:    [Name, Role] — [ ] GO  [ ] NO-GO — Date: ___
Executive Sign-Off:    [Name, Role] — [ ] GO  [ ] NO-GO — Date: ___

FINAL DECISION: [ ] GO   [ ] NO-GO   Decision Time: [Date/Time]
Conditions: [Any conditions attached to a conditional GO]

---

Verification

This skill is complete ONLY when ALL of the following are true:

• All six readiness dimensions assessed with evidence references documented
• Zero Red items remain (or go-live has been formally postponed)
• Every Amber item has documented risk acceptance with a named risk owner and date
• Business-signed data migration reconciliation report in hand
• Integration interfaces verified in the production system (not test system)
• Security: SoD report showing zero unmitigated critical conflicts; audit logging confirmed active
• Named decision-makers across functional, technical, and executive dimensions have individually signed
• Completed and signed Go/No-Go Decision Record exists with timestamp

Evidence required: Completed RAG Decision Matrix, all dimension evidence documents, Go/No-Go Decision Record with signatures.

If any item is unchecked, the Go/No-Go is NOT complete. Do not issue a Go recommendation. Do not allow go-live to proceed.

---

Next Skill

After completing this skill, invoke: hypercare Conditions for handoff: Go/No-Go decision is GO, system is live, and first users are logging in. Hypercare mobilization must begin the moment go-live is declared — not after the first issue appears.

---

Cross-References

• cutover-planning — Cutover execution is the prerequisite that enables this readiness assessment
• testing-strategy — UAT sign-off feeds directly into Functional Readiness dimension
• data-migration — Business-signed reconciliation report is a required input for Data Readiness
• hypercare — Hypercare plan is assessed under Organizational Readiness; must be ready before Go
• sap-security-auditor agent — Use to run automated SoD conflict analysis and role assignment verification