Most businesses learn the value of documentation the hard way: the day the one person who understood their system stops answering. We've written before about what happens when a developer leaves and how to recover from it. This article is the prevention—the document that turns that potential crisis into a non-event.

A proper handover document isn't a 200-page technical manual. It's a focused record of the things that, if lost, would leave you stranded. You don't need to write it yourself—but you do need to know what to demand. Use this as a checklist you can hand to any developer, current or departing.

1. System Overview (The Map)

Someone new should be able to understand what the system is and how its pieces fit together before touching anything. Include:

• Plain-language description of what the system does and which business processes it runs.
• The main components and how they connect (e.g. POS front-end, database, reporting module, payment integration).
• A simple architecture diagram—boxes and arrows are fine; it doesn't need to be beautiful.
• What technology it's built on: languages, frameworks, and versions (e.g. .NET Framework 4.5, SQL Server 2016).
• External services it depends on: payment gateways, SMS providers, e-invoice middleware, anything it talks to.

2. Access and Credentials (The Keys)

This is the section that causes the most pain when missing. If a developer disappears with the only copy of a password, you can be locked out of your own system. Document where every credential lives (in a secure password manager, not a plain file):

• Server access: how to log in to the server(s), with admin credentials.
• Database access: connection details and admin login.
• Source code location: where the code lives (repository URL, and who controls it).
• Hosting and domain accounts: cloud provider, domain registrar, DNS.
• Third-party service logins: payment gateway, email/SMS, e-invoice provider, any API keys.
• Software licenses: keys and the accounts they're registered under.

3. The Source Code and How to Build It

Having the code isn't enough—you need to be able to turn it into the running application. A surprising number of businesses have "the code" but no one who can actually build and deploy it. Document:

• Where the complete, current source code is—and confirmation that it matches what's actually running in production.
• How to set up a development environment: what to install, in what order.
• How to build the application from source, step by step.
• Any special tools, libraries, or licenses required to build it.
• Where configuration and secrets live and how they differ between test and live.

4. Deployment: How Changes Go Live

When something needs fixing, the next person has to know how to safely push a change to the live system. Capture:

• The exact deployment process: how a new version gets onto the production server.
• Any scripts or tools used in deployment, and where they are.
• How to roll back if a deployment goes wrong.
• Scheduled jobs and background tasks: what runs automatically, when, and what it does.
• Maintenance windows or timing constraints (e.g. "never deploy during business hours").

5. The Database

The database is usually where your real business value lives. Document enough that someone can understand, back up, and restore it:

• Database platform and version, and where it's hosted.
• A high-level description of the main tables and what they hold—not every column, but the important structures.
• The backup process: what's backed up, how often, where backups are stored, and—critically—how to restore.
• Any important stored procedures, jobs, or business logic that lives in the database itself.
• Known data quirks: legacy fields, things that look wrong but aren't, fields that mean something non-obvious.

6. Known Issues, Quirks, and Landmines

This is the section that lives only in the departing developer's head—and it's pure gold. Get it written down before they leave:

• Known bugs and their workarounds.
• "Don't touch this" areas—fragile code that breaks in non-obvious ways.
• Recurring problems and how they're usually resolved.
• Manual steps someone performs regularly that aren't automated (month-end routines, exports, reconciliations).
• Things that look broken but are intentional, so the next person doesn't "fix" them into a real problem.

7. Support Contacts and Routine Operations

Round it out with the operational knowledge that keeps day-to-day running smooth:

• Who to contact for each external service (payment gateway support, hosting provider, etc.).
• Routine maintenance tasks and how often they're done.
• How to monitor system health—what "normal" looks like and what warning signs to watch for.
• Common support requests from staff and how to handle them.
• Any service contracts, warranties, or license renewal dates and when they're due.

How to Actually Get This Document

Knowing what you want is half the battle. Getting it requires a little structure:

• Make it a deliverable, not a favour. Build documentation into the contract or scope of work from the start, or as a defined paid task.
• Request it now, not at exit. Ask your current developer to produce it while everything is fresh and working—frame it as protecting the business, which it is.
• If someone is leaving, make a complete handover document the final paid milestone before their last day.
• Verify it's usable by having someone else (another developer, or you) follow it to access the system and confirm nothing critical is missing.
• Keep it current. A document written once and never updated slowly drifts from reality. Review it whenever the system changes meaningfully.

The Bottom Line

A handover document is cheap insurance against one of the most common and most damaging risks a small business faces: all the critical knowledge of its core system living in a single person's head. It doesn't need to be elaborate—it needs to cover the map, the keys, the build, the deployment, the database, the landmines, and the contacts.

If you have a system you depend on and no document like this, you have a single point of failure walking around with the keys to your business. The fix costs far less than the crisis—and the best day to start was the day the system went live. The second-best day is today.