What should a tech handover and a maintenance agreement cover?
A handover leaves you holding every account, repository, secret and renewal date. A maintenance agreement says what it covers, what it doesn't, and how it ends. Two checklists you can hold any vendor to.
- If your vendor's lead person left tomorrow, a good handover means you could still find, deploy and fix everything.
- Accounts and domains should be in your name from day one, not transferred at the end.
- A maintenance agreement without exclusions is a promise nobody can keep.
- Keep maintenance and new development in separate documents so you know what you're paying for.
Quick answer
A handover should leave you holding every account, repository, environment, secret, document and renewal date, with a named person for each. A maintenance agreement should say what it covers, what it excludes, how fast each severity gets an answer, and how it ends. Both should exist in writing before launch day, and maintenance should be a separate document from new development.
The short answer
The test for a handover is simple. If the vendor’s lead person left tomorrow, could you still find, deploy and fix everything? If the answer depends on one person’s memory, the handover isn’t done.
Why operations leaders ask this
A system your team depends on is now partly someone else’s work. The fear is a quiet failure on a Tuesday night with nobody who knows where anything lives, or a renewal that lapses because only the vendor had the login. Both are preventable on paper, before they happen.
What good looks like: the handover checklist
| Area | What you should hold | How to check |
|---|---|---|
| Accounts and domains | Registrar, DNS, hosting, app-store developer accounts, email and SMS providers, payment gateway. In your name. | Log in to each yourself |
| Code | Repositories in your organisation, with full history | Clone one on a fresh machine |
| Environments | Production and staging, config, and how a release goes out | Watch a release done from your side |
| Secrets | A list of every key and credential, who holds it, how it is rotated | Ask for the rotation steps |
| Data | Backups, and a restore that someone has actually tested | See a restore, not a promise |
| Documentation | Architecture, data model, deploy notes, a runbook for common faults | Ask a new person to follow it |
| Monitoring | What alerts exist and who gets them | Trigger a test alert |
| Third-party services | Each one, its cost, its owner and its renewal date | Ask for the renewal calendar |
| People | Who knows what, and a shadow period | A second person fixes something live |
| Exit | What it takes to move away, and how long | Ask for the steps in writing |
Two rules make most of this easier. Put accounts in your name from day one, because transferring them at the end is where handovers stall. And treat the checklist as a living document. It is only useful if it’s updated when something changes.
What good looks like: the maintenance agreement checklist
- What is covered, as a list, not a phrase like “ongoing support.”
- What is excluded, also as a list. This is the part that protects both sides.
- Response targets by severity. What counts as urgent, and how fast someone answers.
- A cap and a path. What happens when a request goes beyond the covered hours or scope, and how it turns into a change request.
- Security and dependency updates. Who applies them, how often, and how you’re told.
- Reporting. What you see each month, so you aren’t paying in the dark.
- Term and exit. How long it runs, and how either side ends it.
- A clean line between maintenance and new development.
How we’ve done it
For a marketplace client we produced a full handover checklist for their tech stack and scoped a monthly maintenance retainer with explicit limits on what it covers. The client’s details, fees and term stay private. No outcome has been measured.
For a marketplace client we produced a full handover checklist for their tech stack, covering the areas in the table above. We also scoped a monthly maintenance retainer with explicit limits on what is covered, so that the scope of support is written down and doesn’t rely on goodwill. Because that work is covered by an NDA, we can describe the structure here but not the client or the terms.
The one lesson that comes out of that work is the last item on the list above. When maintenance and new development get written into the same document, it becomes hard to tell what is being paid for. We now treat them as separate documents with a change request between them.
Where this doesn’t apply
A brochure site with no database and no logins doesn’t need a ten-row handover. A shorter list (domain, hosting, repository, content access) is enough. And a checklist doesn’t replace a person: if nobody on your side owns the items, the table is only a record of what nobody is looking after. We haven’t measured whether a handover checklist reduces incidents, so we don’t claim it does.
Questions to ask any vendor, including us
- Which accounts will be in my name from day one?
- Can I see a handover checklist from a past project, with client details removed?
- Who tests a restore, and when do I see it?
- What does the maintenance agreement exclude, and how are those requests handled?
- Are maintenance and new development in separate documents?
Next: how to vet a software vendor and will my team actually use the new system. Part of the guide Buying custom software and hiring a tech vendor.
The handover and retainer facts come from our project notes for a marketplace client under an NDA and are tracked in our claim ledger. The checklists are our method, not an industry standard. No figure on this page comes from a third party.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
