Project Closure Checklist

Project Documentation

    Walk the repo and confirm the README setup steps still work on a clean checkout, the ADRs (architecture decision records) reflect what actually shipped, and the runbooks point at the current dashboards and alerts. Stale runbooks are the single biggest reason on-call handovers fail six months after closure.

    Mark the GitHub/GitLab repo as archived (read-only) once final tag is pushed. Move Figma files, architecture diagrams, and Confluence/Notion pages into the long-term archive space with the engagement code in the title so they're searchable later.

    Cover scope delivered vs. originally contracted, known defects open at closure with severity, performance numbers against SLO targets, and outstanding tech debt with ticket links. Distribute to the client sponsor, internal sponsor, and engineering leadership.

Client Acceptance and Feedback

    Open the SOW or contract acceptance criteria line by line in a working session with the client sponsor. Flag any items the client wants to defer, contest, or roll into a follow-on engagement before requesting sign-off — surprises at the signature stage delay invoicing.

    Use the standard acceptance form referencing the SOW number. A countersigned PDF or DocuSign envelope is required before final invoicing — email approvals get challenged later by AP.

    File each punch-list item as a Jira/Linear ticket linked to the engagement, with a named owner and a target date inside the warranty window. Don't close out the engagement until each is shipped or formally waived in writing by the client sponsor.

    Standard NPS plus three open questions (what worked, what didn't, would you re-engage). Send to the sponsor and at least two day-to-day stakeholders — sponsor-only responses skew positive.

    90-minute session with engineering, design, PM, and account lead. Capture lessons learned in the team wiki under the engagement code so future bid teams can find them. Action items get owners and dates, not just bullet points.

Code, Infra, and Access Wind-Down

    Resolve or close any open PRs against main, then cut the final semver tag (e.g., v1.0.0-final) and push the matching container image to the registry with an immutable tag. Document the deployed sha in the closure report so a future restore knows exactly what was running.

    Snapshot RDS / managed Postgres with a retention tag matching the contract's data-retention clause. Then actually restore it into a scratch instance and run a smoke query — backup-success-but-restore-fails is the classic gotcha. Record the snapshot ARN and verification timestamp.

    Per the SOW, the AWS / GCP account, domain, and SaaS subscriptions either transfer to the client's org or get decommissioned. Get this in writing before doing anything destructive — recovering a deleted Route53 zone is painful.

    Use AWS Organizations account move or GCP project transfer; never share root credentials. Hand over Route53 zones, ACM certs, and any third-party SaaS subscriptions (Datadog, Sentry, PagerDuty) on the client's billing. Confirm the client's IAM admin can log in before you remove yours.

    Run terraform destroy against the project workspace, release Elastic IPs, delete S3 buckets only after the retention-window snapshots are confirmed in the archive account, and cancel SaaS seats (Datadog, Sentry, PagerDuty schedules). Save the final cost report so finance can true up the run-rate.

    Walk Okta/SSO groups, GitHub org teams, AWS IAM roles, k8s RBAC bindings, and any vendor SaaS (Jira, Datadog, Sentry) one by one. SCIM helps but doesn't catch break-glass IAM users created during incident response. SOC 2 auditors will sample this list — keep the revocation log.

Financial and Contractual Closure

    Pull the final time entries from Harvest / Tempo / internal time-tracking, reconcile against the SOW cap, and issue the closing invoice referencing the signed acceptance form. Flag any over-cap hours that need a change order before billing.

    Mark the SOW as closed in the contracts system. Confirm the MSA stays active if the client is likely to engage again — closing the MSA forces a full re-sign next time. Any change orders left open need either invoicing or formal cancellation.

    Mark the engagement Closed in the resourcing tool (Float, Runn, Mosaic) so the team's capacity returns to the forecast. Update the win/loss CRM entry with the final margin and engagement length for future bid calibration.

Team Release and Knowledge Transfer

    Acknowledge the team's work, walk the closure timeline, and surface any handover gaps before people roll off. This is also where individual feedback for the engagement gets captured for performance reviews.

    Coordinate with resourcing to confirm next-engagement start dates, bench periods, and any PTO scheduled between. Engineers without a confirmed next assignment by rolloff date are a billing-utilization risk — escalate to the practice lead.

    Walk the support / SRE team through the top five runbooks, the Datadog/Grafana dashboards, the Sentry project, and the PagerDuty escalation policy. Pair on a synthetic incident before handing off the pager — read-only handover always misses something.

    If the client wants ongoing maintenance, get the support SOW signed before the warranty window expires — gaps create awkward conversations when something breaks on day 31. Define response-time SLAs, monthly hour caps, and the escalation path explicitly.

Use this template in Manifestly

Start a Free 14 Day Trial
Use Slack? Start your trial with one click

Related Software Development Checklists

Ready to take control of your recurring tasks?

Start Free 14-Day Trial


Use Slack? Sign up with one click

With Slack