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.

---

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.

---

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

1. 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

1. 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

1. 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.

1. 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."

1. 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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: vigneshbarani24
• Source: vigneshbarani24/sap-superpowers
• License: MIT
• Homepage: https://sap-superpowers.vercel.app/

Install and usage instructions live in the source repository linked above.