An integrator contract that fixes scope, price and a plan, and nothing else, leaves the delivery to goodwill. Before signing, settle seven points in writing: the named team and each person’s share of time, the rule when someone leaves, acceptance (who tests, who signs, what counts as done), the owner of the data migration, the date your team runs the org alone, documentation accepted like any other deliverable, and the exit clause. Any point left for the kickoff gets decided later, under deadline pressure, by whoever benefits from keeping it vague.
The most common gap is the team. The proposal shows a lead consultant who ran the discovery workshops and knows why each design choice was made. The contract names the firm, not the person. After the design phase, that lead moves to another account and the replacement is whoever is free. Nothing was breached, because nothing was promised, and you now pay a new person to relearn decisions the first one already made.
Decision rights and design authority belong in the selection itself, and the note on testing the operating model in a Salesforce RFP covers them. This note is about what the signed contract has to carry once you have chosen.
Who is on the team, and what happens when someone leaves?
The proposal presents a team, but the contract usually names only the firm. Close the gap by naming the people who carry the delivery: the delivery lead, the lead consultant who owns the design, and whoever runs the data work. For each, write the share of their time on your project and the phases they cover. Without an allocation, a name in the contract does not commit any of that person’s time to your project.
People do leave, and a clause that forbids it will not be honoured. What you can fix is the rule. Written notice. A replacement profile you can refuse. An overlap, paid by the integrator, while the new person takes over. No change of delivery lead during build or cutover without your agreement. Add one more name: the person above the delivery lead you call when the project slips.
Read the marketing for what it is. Salesforce’s partner page points buyers to a consulting partner directory and, separately, to Forward Deployed Engineering partners, with case studies that cite results from $15M in pipeline to 84% autonomous case resolution. Those results come from other clients and other teams, and the same goes for any firm’s own case studies, whatever its partner label. The people who will work on your project are the ones named in the team clause.
What counts as done, and who signs acceptance?
Acceptance is where integrator disputes end up, because it is where payment meets quality. Write it in the contract itself, which both sides sign, and answer three questions per deliverable.
Who tests. Your key users, on your own processes and on data that looks like production. The integrator is in the room to fix defects while your users test.
Who signs. One named person on the client side per deliverable, with a deputy for holidays. A steering committee is not a signature, and the integrator never signs its own acceptance.
What counts as done. Criteria written before build starts, a severity scale agreed in advance, and a closing rule such as: no open blocking defect, every other defect listed with a fix date. Watch for deemed acceptance, where a deliverable counts as accepted after a period without comment. If that clause stays, the period starts when your testers have both the build and the data, not when the integrator sends an email.
Then tie each payment milestone to a signed acceptance, not to a calendar date or to the integrator’s notice that a deliverable is ready.
Who owns the data migration?
Ask both sides separately and the answers often differ. The proposal says the integrator will “support” the migration; the client reads “perform”. Then the first trial load fails on duplicates nobody was asked to resolve, and each side points at the other.
The data and its meaning belong to the client, so one person on the client side, usually the business owner of the data, answers for the migration as an outcome: which records move, which duplicate wins, which history stays behind. The integrator owns the mechanics it is paid for: mapping documents, transformation, load scripts, rehearsals and the reconciliation reports. Write that split into the contract. Name the extraction from the legacy systems as well, because it often sits with a third party (the legacy vendor, an internal IT team) that has no contract on this project.
Two more lines avoid the usual argument: how many full rehearsals the price includes, and who pays for a rehearsal that fails because the source data was not ready. What to prove before cutover (an owner per object, counts the business signs, a rollback deadline) is in the note on Salesforce data migration.
When does your team run the org alone?
Set the handover date in the contract: the day your team runs the org alone and the integrator leaves the release path. Then plan backwards from it.
Before that date, your admins have worked beside the integrator through the build, not watched a demo in the final week, and the documentation (design decisions, configuration notes, runbooks for releases and incidents) has been tested and signed like any other deliverable. The training plan belongs here too: decided before acceptance testing, so key users test what they will later teach. The note on the training plan at launch sets the order.
Make the handover testable. Before the date, your team ships one release on its own while the integrator only watches. If it cannot, the date moves, and the contract already says who pays for the extra time. After the date comes a support period with a written scope and response times. Give it an end date too. Otherwise support runs on with no agreed limit, and you keep paying for it on terms you never negotiated.
How do you leave if it goes wrong?
Few clients sign expecting to leave, which is why the exit clause is the one most often left as boilerplate. It is also the clause that decides whether you hold your own work when things go wrong.
An exit clause you can use has four parts.
- A right to end the contract for convenience, with notice, not only for breach. Proving breach on a late project is slow and contested, and the project keeps losing time while you argue.
- Transfer of everything produced so far (metadata, code, scripts, data mappings, test cases, documentation), in a usable state and owned by you.
- An assisted handover to the next team, for a defined period and at rates agreed now.
- Access held by the client from day one: admin accounts, integration credentials, environments and the repository. Leaving should never turn into a negotiation over passwords.
Read the exit clause next to the team clause. If the named lead leaves and you refuse two replacement profiles in a row, that should open the exit as well, without having to prove a breach.