The system works on launch day and nobody on your side can change it. Three months later a field needs adding, an integration stops, and the only person who knows why is billing another client. That is the normal outcome of a consulting engagement, and it is a failure. The launch is not the deliverable. The handover is. This note lists what a complete one contains, so you can ask for it in the contract and check for it at the end.
The handover is the deliverable
A rebuild your team cannot run is a rental. You pay again every time it needs to change, and the price goes up because the knowledge is scarce. The point of the work is to leave you with a system your own admin can read, change, deploy, and fix. Everything below is measured against one test: can a new admin, hired after we leave, make the next change without calling us.
So the handover starts on day one, not in the last week. The repository exists from the first commit. The data dictionary grows as fields are added. The runbook is written by the person doing the deploy, on the day they do it. A handover written in the last week is a summary of what someone remembers, and it is wrong in the places that matter.
What a complete handover contains
The repository
All metadata and code, in a repository your organization owns, with a history that explains why each change was made. The README is the test. A new admin follows it from a blank machine to a deployed sandbox without asking anyone a question. It names the tools and versions, how to authenticate, how to retrieve, how to deploy, and how to run the tests. If the README says “ask the consultant”, it is not finished.
The data dictionary
Every custom object and every custom field, with four facts each: what it means in plain words, what writes it, what reads it, and who owns the answer. “What writes it” names the flow, the trigger, the integration, or the screen. “What reads it” names the reports, the layouts, the formulas, and the external systems. This is the document that makes the next survey take a day instead of a week. Generate the list from the metadata. Write the meanings by hand. Nothing else can.
The automation map
Per object, in firing order: every record-triggered flow with its trigger order, every Apex trigger and its handler, every validation rule, and every remaining Workflow Rule or process. Next to each one, a sentence on what it does and a sentence on when it fires. Your admin reads this before touching the object. We read it the same way. If it is not accurate, the next change breaks something, and the map is the first thing to fix.
The runbook
The runbook answers the questions that come up at the worst time. How to deploy a change, step by step, with the commands. How to roll back the last deploy. How to pause an integration without breaking the records on either side, and how to resume it and catch up. How to rotate a credential. Who to call, by role, for each system on the other end of an integration. Each procedure has been run at least once by your admin, with us watching, before we leave.
The integration register
One row per external system. The endpoint, the direction of data, the schedule or trigger, the credential and who owns the account it lives in, the named person on each side, and the failure path: what happens when it fails, who is told, and how they are told. No integration goes live without a row. No row goes live without a failure path. See the handoff tax for why that rule exists.
The training
Recorded sessions, not a slide deck. Your admin shares their screen and does the task while we talk them through it: a deploy, a rollback, a new field through the dictionary and the map, an integration pause and resume. The recording is the training for the admin after them. Two hours of video that show the real system beat two days of generic certification prep.
The last cycle
The final build cycle is run by your team. Your admin makes the change, writes the tests, deploys to the sandbox, and deploys to production. We review, we answer questions, and we do not touch the keyboard. If that cycle fails, the handover is not done, and we stay until it passes. That cycle is the only honest proof that the handover worked.
Signs of a bad handover
You can spot a bad handover before the contract ends. Four signs are enough.
- Knowledge that lives in one head. One person, on either side, is the only one who can explain a part of the system. Ask them to write it down and watch how long it takes.
- Credentials in a personal account. An integration user that logs in with a consultant’s email. A named credential set up under a personal developer account. The day that account closes, the integration stops.
- A managed package nobody can see inside. A package built by the consultancy, installed in your org, with the code hidden. You cannot read it, change it, or leave it. The only way out is a rebuild.
- “We will document it later.” Later is after the invoice is paid. The documents are part of the work, and the work is not done without them.
The checklist
Fill this in before the last invoice. Every row needs a location and a name. “The consultant” is not a name.
| What | Where it lives | Who owns it |
|---|---|---|
| Repository with README | Your organization’s source control | Your admin |
| Data dictionary | Repository, docs/data-dictionary.md |
Your admin |
| Automation map | Repository, docs/automation.md |
Your admin |
| Runbook | Repository, docs/runbook.md |
Your admin and IT on-call |
| Integration register | Repository, docs/integrations.md |
IT director |
| Credentials | Your password manager, team vault | IT director |
| Integration users | Your org, named after the system, not a person | IT director |
| Sandbox refresh procedure | Runbook | Your admin |
| Test suite and how to run it | Repository, README | Your admin |
| Training recordings | Your shared drive, linked from the README | Your admin |
| Support contacts per external system | Integration register | IT director |
| The last cycle, shipped by your team | Release notes in the repository | Your admin |
When every row is filled and the last cycle has shipped, we leave. You keep the system. That is what hand over means on the method page, and it applies to every line of work we do, not only Salesforce rebuilds.