Cloud kickoff and operations handover checklist

Start with a list of what is being operated. Cloud accounts and projects, servers and databases, domains and certificates, where DNS is managed, external integrations and who holds each contract — one line each. Separate development, staging and production so that later nobody is unsure which environment a task touches. Account ownership, payment method and billing path go into the same table. Take one copy of last month's invoice per account and there is something to compare against when costs rise.

Any row with no owner is the first week's work. Certificates issued under a departed employee's personal account, or an external service only one person knows about, surface here. A resource that turns up after the list is closed is no longer onboarding; it is incident response.

Write one line on why each resource exists. Without knowing whether something is for testing or disaster recovery, and which business cycle keeps it running, nobody can judge later what is safe to switch off when costs need cutting.

Do not hand over the account whole. Split read access, operational access and the right to create and delete resources, and name who sits in each role. The top-level administrator account stays with the customer, with sign-in records kept. A break-glass role that opens only during an incident keeps everyday rights narrow without slowing recovery.

Server keys and database passwords move only after their storage location is agreed. Once handover completes, revoke the previous holder's access and record the date in the table. Where a shared account was passed around, this is the point at which it splits into individual accounts.

Confirm that audit logs accumulate in the customer's account and set the retention period. Only a record of who did what and when will find the last change during the first incident.

Agree who notifies whom, by what route, when something breaks. Write down the night and holiday channel, who is notified at each severity, how often progress is shared, and who can raise a severity. A path that runs through one person's mobile number ends the moment that person steps away. Define severities by what has stopped in your own service: a healthy server with payments or sign-in failing is still top severity.

Test the path once in the first week. Send a real notification and confirm it reaches someone; otherwise the first test happens at 3 a.m.

Knowing that backups run is not enough. Restore one of them for real in the first week and record how long it took. How far back you can go, whether the restored data is intact, and who performs a recovery all come out of that test. Check at the same time that the retention period and storage location meet the contractual requirements.

Put the standard change window and the immovable dates on the calendar together. Financial closes, settlement runs and external filing dates come out of the change window. Agreeing rollback conditions and the acceptable outage window once here saves settling them again for every task.

Settle the exit terms in the kickoff meeting and there is nothing to negotiate later. Record the format in which runbooks, change history, dashboards and alert rules, metric history and scripts will be handed over. If monitoring runs on the delivery team's subscription, observability switches off the day the contract does, so decide now who owns that account. Who transfers account permissions and when, and how long parallel running lasts, are settled in the same place.

When the first week closes, these five groups should exist as documents. The asset inventory, the access table, the escalation path, the recovery record and the exit terms become the ground for every operational decision that follows.