SAP Go-Live Readiness Checklist by Owner

Decision context

Go-live readiness is a decision with consequences, so it should be made against criteria written down before anyone knew the answer. A checklist assembled in the week of go-live tends to describe the state the program is already in.

The useful structure is by owner. Each workstream lead confirms their own criteria and states any exception as a named risk with a mitigation, and the sponsor decides on the aggregate. A criterion nobody owns will not be checked.

Adranum's role is to make the technical criteria evidence-backed: which objects changed, what depends on them, which tests covered them, what those tests returned against the exact package, and what a rollback would restore.

Basis and technical readiness

Owned by the Basis lead. Every item is a yes, a no, or an accepted exception with a named risk owner.

• Production system sized, patched, and at the agreed kernel and support package level, with the levels recorded.
• Transport route and import sequence frozen, with the go-live transport list reviewed for order and completeness.
• Backup taken and a restore verified, not just a backup job that reported success.
• Background job schedule prepared, with jobs held rather than deleted so nothing starts before the business gate.
• Printers, spool, output management, and archiving configured and tested in the target.
• Monitoring, alerting, and the on-call rotation live before the window opens rather than after.
• Performance baseline captured, so post go-live degradation can be recognised rather than debated.

Data readiness

Owned by the data lead. The reconciliation criteria matter most and are most often left qualitative.

• Final delta scope agreed and the extraction sequence proven at production volume.
• Reconciliation rules defined per object: record counts, control totals, and open item balances, with the tolerance stated in advance.
• Data quality exceptions triaged, with each remaining defect fixed, accepted with an owner, or scheduled for post go-live correction.
• Number ranges, document numbering, and period status set correctly in the target.
• Legacy read access and retention arrangement agreed, because somebody will need the old value in month two.

Interfaces and integration readiness

Owned by the integration lead. This is where a green internal checklist most often meets a partner who was never consulted.

• Complete interface inventory with direction, protocol, partner, and business owner for each entry.
• Each partner notified of the freeze window and the restart time, with confirmation received rather than sent.
• Queue drain and restart sequence proven, including duplicate protection on restart.
• Error handling and monitoring in place for the first business day, with a named person watching the queues.
• Fallback agreed with the business owner for any interface that cannot be restarted on time.

Security, testing, business, and support readiness

Owned by the security lead, test manager, business process leads, and support lead respectively.

• Roles built, tested with real users on real transactions, and transported. Emergency access procedure tested, not only documented.
• Segregation of duties conflicts reviewed and either resolved or formally accepted before go-live, not after the first audit.
• Test exit criteria met, with the open defect list reviewed item by item including severity and workaround.
• Regression run against the final go-live package rather than an earlier build.
• Business users trained, with completion recorded per role rather than per invitation.
• Hypercare staffing, hours, escalation path, and triage process agreed and communicated before the window.
• Explicit no-go criteria and an abort decision time, agreed before the window opens.

What the workflow must cover

• Owned criteria. Every item carries a single accountable owner, so readiness is a set of confirmations rather than an aggregate opinion.
• Evidence-backed technical items. Technical criteria resolve to observable artifacts: transport lists, test results bound to the package, coverage gaps, and restore verification.
• Explicit exceptions. An unmet criterion becomes a named risk with an owner and a mitigation rather than disappearing into an aggregated status.
• Stated no-go conditions. The conditions that stop the window are written before the window, while they can still be argued on their merits.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Agree the criteria and their owners at least four weeks before the window.
2. Collect evidence per criterion during the final rehearsal.
3. Hold the workstream readiness reviews with the evidence in front of you.
4. Record exceptions as risks with owners and mitigations.
5. Hold the sponsor go and no-go against the written criteria and the abort time.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Kernel and support package levels
• Verified restore
• Go-live transport list
• Reconciliation rules and tolerances
• Interface inventory and partner confirmations
• Role test results
• Test exit report against the final package
• Hypercare staffing plan

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A checklist does not make the decision. It makes the decision arguable on evidence.
• Business tolerance for a delayed go-live is a customer decision shaped by contracts, reporting dates, and season.
• Criteria written in the same week as the decision tend to describe the current state rather than test it.

Buyer checklist

• Was a restore verified, or only a backup?
• Which criteria are unmet, and who owns each exception?
• Was the regression run against the final package?
• Have interface partners confirmed the restart window?
• What is the abort time, and who calls it?