1. Draw the operating boundary
List the application or API, data stores, scheduled jobs, domains and external services in scope. Name the business owner and the people who approve changes. Identify the environment being handed over: a test environment is not automatically approved for production use.
For an existing platform, the work package may cover only a deployment pipeline or one service. Record which shared infrastructure, networking, security controls and support duties remain with the internal team.
2. Request evidence the operating team can use
| Area | Evidence to agree | Named owner |
|---|---|---|
| Accounts and access | Account and repository ownership; required roles; how access is granted and removed; the approved location for secrets. | [Account and access owner] |
| Runtime and dependencies | Environment inventory; application configuration; connected data stores; third-party dependencies and known limits. | [Technical owner] |
| Release process | Source revision; build and validation steps; environment promotion; production approval and release record. | [Release approver] |
| Rollback | The conditions for rollback, the version or state to return to and a recorded check of the procedure. | [Release operator] |
| Monitoring and incidents | Health signals; log location and retention choice; alert destination; who investigates and how escalation works. | [Operating owner] |
| Backup and recovery | What data and configuration are protected; recovery expectations; restore procedure and evidence from an agreed recovery exercise. | [Data and recovery owner] |
| Billing | Cost drivers; account payer; usage assumptions; budgets or alerts chosen by the account owner; review frequency. | [Budget owner] |
| Support and documentation | Runbook location; known limitations; contact and escalation route; agreed support hours and excluded responsibilities. | [Receiving team] |
3. Separate rollback from data recovery
Returning to an earlier application release may not undo a data change, restore a deleted record or recover a failed dependency. Review each of those situations explicitly. Define how much interruption and data loss the business can tolerate, then agree a design and verification exercise appropriate to those requirements.
A backup setting alone does not demonstrate a successful restore. Record the environment, steps, outcome and outstanding limitations of the agreed recovery exercise. If a check cannot be performed before handover, make the gap and its owner visible.
4. Make cloud cost ownership explicit
The account payer should understand which costs depend on traffic, stored data, background work, external APIs and model usage. An initial estimate needs stated assumptions; it is not a fixed operating bill. Decide who reviews usage after launch and who can approve changes that add consumption.
Keep delivery fees, cloud charges and other subscriptions separate in the scope. A budget alert is useful information for its owner; agree separately whether the application needs usage limits or other controls and how those controls affect users.
5. Walk through one release and one failure scenario
For a scientific application or API, ask the receiving operator to locate the deployed revision, explain a release approval, find a failed health check and follow the rollback procedure in the agreed environment. Review how the data store would be restored separately. Record what was demonstrated and what remains a documented procedure only.
| Check | Acceptance rule set before handover | Evidence and decision |
|---|---|---|
| Release or rollback | [Environment; authorised operator; expected outcome] | [Revision; procedure followed; observed result; reviewer] |
| Operational alert | [Condition; destination; person responsible] | [Signal observed; notification received; unresolved gap] |
| Recovery exercise | [Data and configuration scope; expected recovery; restrictions] | [Exercise record; restored state; limitations; next action] |
| Cost and support ownership | [Payer; review cadence; support scope and escalation] | [Owner acknowledgement; document location; open decisions] |
6. Choose a first engagement the team can accept
A first scope can cover one application deployment, an agreed improvement to an existing release process or a readiness review that identifies the work needed before launch. An internal team or delivery partner can retain platform ownership while Zeltar delivers a defined component. Agree the interfaces, evidence and handover responsibilities at the start.
Technical references
The AWS Well-Architected Framework provides a structured way to review architectural decisions and tradeoffs. AWS's operational preparation guidance covers observability, reversible changes, readiness checks and runbooks. The checklist above is a Zeltar planning resource and does not represent an AWS certification or formal audit.