Taking Over a Web Project From Another Agency: The Checklist

Taking over a web project from another agency is a sequencing problem more than a technical one. Secure every account and asset in your own name first, spend one mapped week understanding what actually runs in production, then stabilise for thirty days before changing anything visible. Handovers rarely fail because the people involved were bad; they fail because this order was skipped. This checklist walks through it step by step.

What should you secure before anything else?

Before any code review, transfer ownership of every asset the product depends on: domain registrar, DNS, hosting and cloud accounts, source repository, CI/CD secrets, database backups, and third-party services. Ownership means accounts registered to your organisation, not seats granted to you inside the previous agency's accounts.

• Domain registrar: your account, your billing details, transfer lock enabled.
• DNS zone: exported, then hosted under an account you control.
• Hosting and cloud: owner role in your name; the outgoing agency keeps a temporary member seat at most.
• Repository: full ownership transferred to your organisation, not a fork or a zip archive.
• CI/CD secrets: inventoried now, rotated as soon as the transfer completes.
• Database: a fresh backup taken today and restored somewhere else to prove it restores.
• Third parties: payment provider, transactional email, analytics, error tracking.

A backup that has never been restored is a hope, not a backup. Verify it before you sign anything else off.

What does the takeover audit actually cover?

One mapped week, not a rewrite. The audit answers four questions: what runs where, on which versions, how a change reaches production, and what tells you when something breaks. The output is a one-page map of the system plus a ranked risk list, the same map-first logic we apply to zero-downtime migrations.

Versions matter early: check every runtime against the official Node.js release schedule, because an end-of-life runtime moves straight to the top of the risk list. Then walk the deploy path yourself: if nobody on your side can ship a change, you do not control the product yet. Finish by listing the quiet dependencies: cron jobs, manual steps, the one server nobody dares to reboot.

Which legal and practical items need settling?

Four things to check in the original contract: who owns the code, which licences were bought and in whose name, what documentation was contractually due, and whether open invoices block the transfer. Most handover friction is structural, produced by unclear clauses and unpaid balances rather than bad faith on either side.

In many jurisdictions, paying for development does not automatically transfer the copyright: the assignment clause has to say so explicitly, so read it before assuming the code is yours. List every paid licence (plugins, fonts, SaaS subscriptions) and confirm which ones are registered to the agency rather than to you. And settle open invoices early: an unpaid balance is the most common reason a cooperative handover turns silent.

How should the first thirty days go?

Stabilise before you evolve. The first month has three jobs: put monitoring in place so you can see the system, triage dependencies so you know which updates are urgent, and ship one small, reversible deploy to prove the pipeline works end to end. New features wait until all three are done.

Monitoring comes first because every later decision depends on it: error tracking, uptime checks and log access from day one. For the triage, a scan with OWASP Dependency-Check separates known vulnerabilities (urgent) from outdated majors (scheduled). The reversible deploy can be trivial, a copy change is enough: what it proves is that you can ship and, more importantly, roll back.

Which red flags change the plan?

Three findings force a slower takeover: no staging environment, secrets committed to the repository, and all knowledge concentrated in one person. None of them is rare and none is a moral failing; each one simply changes the order of work before the standard thirty-day pattern can apply.

No staging means you build one before touching production, full stop. Secrets in the repository mean every credential in git history is compromised by definition: rotate them all, then move to a proper vault following the OWASP Secrets Management Cheat Sheet and the Node.js security guidance. A single human point of failure means you book paid handover sessions with that person now, while goodwill still exists.

Hot takeover vs prepared takeover: what changes?

A hot takeover (the previous agency is gone or unresponsive) and a prepared takeover (a negotiated overlap period) follow the same checklist with very different safety margins. If an overlap is still possible, even two weeks of cooperation, take it: it converts several high risks into routine tasks.

How do we keep the next handover easy?

Reversibility is a setup decision, not a promise. On projects we take over, the repository lives in the client's organisation, the infrastructure runs on the client's accounts, and the handover documentation is written from day one. A takeover done properly should never need to be done twice for the same reason.

This is also why our backend modernisation engagements start with the same map described above: the audit that lets you take a project over safely is the audit that lets you evolve it safely afterwards.

The takeover checklist

1. Domain, DNS, hosting, repository, CI/CD and third-party accounts owned by your organisation.
2. Every secret rotated once the transfer is complete.
3. One backup restored and verified, not just downloaded.
4. Contract checked: code ownership, licences, documentation due, open invoices.
5. One-page system map produced, risks ranked.
6. Monitoring live before any change ships.
7. Dependencies triaged: vulnerabilities first, majors scheduled.
8. One small reversible deploy shipped, then rolled back on purpose.
9. Red flags logged, plan resequenced accordingly.
10. Handover documentation for the next team started on day one.