Django Project Handover Checklist

Problem statement

A freelancer finishes a client project, an agency hands a system to the client's in-house team, or a developer leaves the company. The Django app keeps running, until the first incident, certificate expiry, or deploy, when the new owners discover that the domain is registered to the previous developer's personal account, backups were never tested, the deploy process lives in someone's shell history, and nobody knows which email service sends password resets.

A handover is complete when the receiving team can deploy, roll back, restore, and respond to incidents without contacting the previous owner. This checklist covers what to transfer and verify so that is true.

1. Transfer ownership of every account (registrar, DNS, hosting, email, error tracking, payment, analytics) to the receiving organisation, not just access.
2. Provide an inventory: servers, services, environments, data stores, scheduled jobs, and external integrations.
3. Document deploy, rollback, backup, restore, and incident procedures as runbooks in the repository.
4. Rotate every secret the previous owner knew, after the receiving team controls the secret store.
5. Verify together: the new team deploys a change, rolls it back, and restores a backup to a test environment.
6. Remove the previous owner's access and record the date.

Checklist

1. Accounts and ownership

• Domain registrar account is owned by the client or organisation, with their contact details and two-factor authentication.
• DNS provider, hosting or cloud account, container registry, and CI/CD are owned by the organisation (billing and root or owner roles).
• Email delivery (SES, Postmark, SendGrid, or SMTP provider), error tracking, uptime monitoring, analytics, and payment provider accounts are transferred.
• Git hosting: repository transferred to the organisation; branch protection and required reviews configured.
• An owner list exists: for each account, who owns it, who has admin access, and where recovery codes are stored.

2. Inventory

• Architecture overview: a short document or diagram of components (proxy, app servers, workers, database, cache, storage, CDN) and how they connect.
• Environments: production, staging, and others, with URLs and differences.
• Servers or services: identifiers, regions, sizes, and how they were created (Terraform, console, scripts).
• Data stores: database engine and version, size, backup method, storage buckets and their purpose.
• Scheduled jobs: Celery Beat schedules, cron or systemd timers, and what each does.
• Integrations: every external API, webhook endpoint, and credential type.
• Certificates: how TLS is issued and renewed.

3. Code and configuration

• The repository builds from a clean checkout following the README.
• Dependencies are pinned in a lock file; the Python and Django versions are documented along with their support end dates.
• All configuration comes from environment variables or a secret store; a documented example file lists every variable without real values.
• Infrastructure code (if any) is in the repository and matches reality.
• Known issues, technical debt, and planned upgrades are listed.

4. Runbooks

• Deploy: exact steps or the CI pipeline, including migrations and static files.
• Rollback: how to return to the previous release, and what cannot be rolled back (migrations).
• Backup and restore: where backups are, how to restore the database and media, and how long it takes.
• Incidents: where logs and metrics are, common failures and their fixes, and who to contact at providers.
• Routine tasks: certificate renewal checks, dependency updates, and OS updates.

5. Secrets

• The receiving team controls the secret store (environment files, secrets manager, CI secrets).
• After control is transferred, rotate everything the previous owner knew: SECRET_KEY (with fallbacks), database passwords, API keys, SMTP credentials, cloud access keys, deploy keys, and admin passwords.
• Personal SSH keys of the previous owner are removed from servers and replaced with the new team's keys.

6. Verification with the new team

• The new team deploys a small change to staging and production using the documented process.
• They roll back that change.
• They restore the latest database backup to a scratch environment and start the app against it.
• They find a recent error in the error tracker and the related logs.
• They can explain which monitoring alerts exist and who receives them.

7. Monitoring and alerts

• Uptime checks, certificate expiry checks, and error alerts go to the receiving team's addresses or on-call tool.
• Alert rules are reviewed: nothing still points to the previous owner's email or phone.
• Billing alerts and quotas go to the new owner.

8. Offboarding

• The previous owner's accounts on every service are removed or downgraded.
• Shared passwords the previous owner knew have been rotated.
• A handover record lists what was transferred, when, and any open items with owners.

Explanation

Operational knowledge is the part of a project that is not in the code: where things run, who owns the accounts, how to deploy and recover. It is invisible while the original developer is around and becomes critical the moment they are not. The checklist makes that knowledge explicit, moves ownership to the organisation, closes security gaps created by people leaving, and proves the transfer worked through hands-on verification rather than a handover meeting.

Edge cases / notes

Client refuses to own accounts

Some clients want the developer to keep running everything. Document that arrangement explicitly, including what happens if the relationship ends, and keep the client as the legal owner of the domain and data at minimum.

Partial handovers

When a team takes over only the application while another team keeps infrastructure, define the boundary: who deploys, who responds to which alerts, and how changes to shared components are coordinated.

When to automate this

The more of the system is described as code (infrastructure definitions, CI pipelines, provisioning scripts, runbooks in the repository), the smaller the handover becomes. A project where a new environment can be created from the repository is largely handed over when the repository and accounts are.

Next steps

• Check the deployment itself with the Django Deployment Checklist for Production.
• Document recovery with Write a Disaster Recovery Plan for a Django App.
• Rotate the key without logging users out using Rotate the Django SECRET_KEY Safely.
• Decide what to automate before handing over with Manual vs Automated Django Deployment: When to Switch.

FAQ

What is the most commonly forgotten item in a Django handover?

Account ownership, especially the domain registrar and DNS, and third-party services like email delivery that were set up under a personal account.

Should secrets be rotated after a handover?

Yes. Rotate every credential the previous owner knew, once the receiving team controls where secrets are stored.

How do I know a handover is complete?

When the receiving team has deployed, rolled back, and restored a backup on their own, and every account is owned by their organisation.

What documentation should a Django project handover include?

An architecture overview, environment and service inventory, and runbooks for deploy, rollback, backup and restore, incidents, and routine maintenance.