The Salesforce implementation checklist: what to confirm before you sign the SOW

Here’s an uncomfortable pattern anyone who inherits other firms’ Salesforce projects will recognize: by the time a buyer calls someone to rescue an implementation, the thing that killed it was almost always decided — or left undecided — before the statement of work was signed. The build phase gets the blame, but it was just executing ambiguity both sides signed off on. Nobody wrote down who owned data cleanup, nobody listed the integrations, nobody defined what “done” meant — so go-live became a negotiation instead of a milestone.

The fix is cheap: a few uncomfortable conversations before signing instead of a change-order war after. This is the checklist we’d want any mid-market buyer to walk through before engaging a partner — what must be pinned down in or before the SOW. None of it requires technical depth; all of it requires the willingness to keep asking until the answer is specific.

Scope: name the processes, name the objects, name what’s out

Every SOW says “implement Sales Cloud” or some variant. That sentence is not a scope; it’s a category. A real scope names the business processes being built — lead routing, quote approval, renewal management, case escalation — and the Salesforce objects that carry them. If the document can’t say whether your quoting process is in or out, you’ll find out at week nine, and it will cost extra.

Just as important is the explicit out-of-scope list. A good partner writes down what they are not doing — the ERP integration deferred to phase two, the territory model you agreed to postpone, the legacy reports nobody will rebuild. That list isn’t defensive lawyering; it’s the shared memory that prevents “I assumed that was included” six weeks in. A draft SOW with no out-of-scope section isn’t generosity — it’s a blank cheque that gets cashed as change orders, and it’s how orgs accumulate the half-built features that turn into technical debt. While you’re there, ask how much is standard configuration versus custom code — custom work should be justified per item, not the default.

Data migration: ownership, and who fixes the dirty data

Data migration is the most consistently underscoped line in Salesforce SOWs, for a structural reason: the effort depends on the state of your data, which the partner hasn’t seen in depth at drafting time. So it gets one optimistic line — “migrate accounts, contacts, and opportunities” — and the mess surfaces mid-project.

Pin down three things in writing. First, ownership per step: who extracts, who maps fields, who transforms, who loads, who validates. “Shared responsibility” means nobody is responsible. Second, data quality remediation: your legacy data has duplicates, dead records, and fields used three different ways over five years. Someone has to decide what’s kept, merged, and archived — usually you, because only your team knows which records matter. The SOW should say whether remediation is the partner’s scope, yours with their tooling, or explicitly deferred. Third, the validation gate: how you’ll confirm migrated data is correct before go-live, not after.

And everything AI-shaped on the platform now inherits your data quality — an agent grounded on a migrated mess gives confidently wrong answers. Data quality is the real AI prerequisite, and migration is the moment you either fix it or pour concrete over it.

Integration inventory: every system, every direction, before pricing

Ask for a table in or attached to the SOW: every system Salesforce will talk to, direction of data flow, rough frequency, and method — native connector, middleware, or custom API work. A partner who priced the project without building that table priced a guess.

Integrations are where budgets die quietly, because each one hides real questions: does the other system have a usable API? Who owns credentials? What happens when it’s down? Which system wins when records conflict? The architectural answers are well understood, but they have to be asked per system — and before signing is when you have leverage to insist.

Two platform constraints belong in this conversation. Salesforce meters inbound API calls — API limits vary by edition and license count, and a chatty middleware design that ignores this works in testing and throttles in production. And anything running on-platform lives inside governor limits that punish careless bulk processing. You don’t need to understand the limits yourself; you need a partner who brings them up unprompted in scoping.

Environments and sandboxes: where does the work actually happen

The SOW should say which environments the project uses and what each is for: where development happens, where integrated testing happens, where UAT runs. It sounds bureaucratic until you watch a project test integrations in a Developer sandbox with no production-shaped data, pass everything, and fall over at go-live.

What your edition includes shapes this plan, so confirm it early. Full sandboxes — a complete copy of production, data included — come with Unlimited and Performance Editions and are a paid add-on below that; Enterprise Edition includes a Partial Copy sandbox carrying a sample of production data. Refresh cadence is a real constraint too: a Full sandbox can be refreshed every 29 days, a Partial Copy every 5, so refreshes must be planned around the project calendar. We’ve laid out how to structure a sandbox plan properly; pre-SOW, the checklist item is simply that the partner has one, names where UAT happens and on what data, and surfaces any sandbox purchases now, not as a mid-project invoice.

Release approach: how changes move to production

Ask one deceptively simple question: how does a change travel from a developer’s sandbox to my production org? The answer reveals more engineering maturity than any certification count. You’re listening for a defined path — version control, a deployment tool, a review step — rather than “we deploy with change sets when things are ready,” which in practice means manual, unrepeatable releases and an org whose true state lives in someone’s memory.

You don’t need to referee tooling choices — we’ve compared DevOps Center to change sets in detail, and mature partners may bring their own pipeline. The checklist item is that the delivery plan names the mechanism, includes version control, and says who can deploy to production. That last clause matters after go-live too: if only the partner can deploy, you’ve signed up for a dependency, not a handover.

Licensing and edition: buy for the roadmap, not the demo

Edition problems are silent at signing and expensive at month eighteen. The classic mid-market trap: buying Professional Edition because it’s cheaper, then discovering that API access — the thing every real integration depends on — is included from Enterprise Edition up but a paid add-on on Professional. If your integration inventory has anything in it, that alone usually settles the edition question.

The AI roadmap settles it harder. Agentforce and the surrounding AI stack arrive through Salesforce Foundations, a free add-on — but only for Enterprise Edition and above. If agents or Data 360 work are anywhere on your two-year roadmap, an edition below Enterprise means re-buying licenses midway. (Already on Enterprise? Foundations is worth switching on early — it costs nothing and includes starter Agentforce credits.)

The checklist items: the SOW or its order form states the edition and license types by user group, and the partner has mapped the roadmap — features and limits like sandboxes, API allocation, and storage — to what that edition includes. A partner who helps you buy the right edition for year two, not the cheapest one for the demo, is advising; one who won’t discuss licensing is leaving you alone with the account executive.

Commercial structure: the change-order mechanics are the contract

Fixed fee versus time and materials is the debate everyone has; the change-order mechanics are the clause that actually decides how the project feels. Fixed fee puts scope risk on the partner — which works only when scope is genuinely nailed down, and quietly incentivises minimum-viable interpretation when it isn’t. Time and materials is honest about uncertainty but needs a cap and weekly burn visibility, or the meter becomes the project plan. Neither model is wrong; the wrong thing is a model mismatched to how well-defined your scope is.

Whatever the model, read the change-order process like it will be used, because it will. Who can raise a change? How fast is it estimated? What happens to the timeline while it’s negotiated? A partner with a lightweight, written change process has done this before; one with no defined process will improvise one mid-project, under pressure, in their favour. We’ve covered commercial models in our guide to choosing a firm — the pre-SOW version: make the mechanics explicit while everyone is still friendly.

Team: the names in the SOW are the team you get

The people who sold you the project are not necessarily the people who will build it — and that gap is one of the most reliable predictors of disappointment in this industry. Before signing, get the delivery team by name: who architects, who builds, who runs the project day to day. Ask what certifications those named people hold — not the firm’s all-time total — and whether they’ve shipped a project shaped like yours.

Then make the names stick. A key-person clause — the named lead can’t be swapped without your consent and a proper transition — is reasonable, common, and a useful tell: a firm that resists it is planning to reassign. Continuity matters too: decisions made in discovery need to travel to UAT in someone’s head, not just in documents. If your project includes agent or AI work, the bar is higher still — the questions worth asking an Agentforce partner start with “who writes the Apex, by name.”

Acceptance, UAT, and hypercare: define done before you start

“Go-live” is not a definition of done. The SOW should contain acceptance criteria specific enough that a neutral party could check them: these processes work end to end, this data is migrated and validated, these integrations run on schedule, these users can do their jobs. Vague acceptance language (“system delivered per requirements”) means done is whatever the partner says it is.

UAT needs the same treatment: who tests, against what scripts, on which environment and data, for how long — and, critically, what happens when UAT finds problems. Is a fix round included, or does every defect become a change order? Get severity definitions in writing — a showstopper blocks go-live, a cosmetic issue doesn’t — before you need them in a dispute.

Finally, hypercare — the supported period immediately after go-live when issues surface and users wobble. Confirm how long it lasts, what response times apply, and whether it’s included or billed. A SOW that ends at go-live means the week you most need the partner is the week the engagement is over.

Documentation and handover: you should own your org afterward

The last checklist item determines whether you’ve bought a capability or rented one. The SOW should commit to documentation deliverables by name — a data dictionary for custom objects and fields, integration documentation, an admin runbook — and to admin enablement: training your team, in your org, on what was built. Ask directly: the day after handover, what can my admin do without calling you? A good firm answers concretely; one that mumbles about “knowledge transfer sessions” is building a dependency. It’s also fair to make security hygiene part of handover — a partner should show you a clean Security Health Check rather than leaving hardening as your surprise.

Red flags that predict failure

Some signals are reliable enough to pause a signing over:

• No discovery before a fixed price. Quoting a fixed fee without examining your org and data means heavy padding or a plan to change-order the way to profitability.
• No out-of-scope section. Ambiguity always resolves in favour of whoever wrote the document.
• Data migration as one line. The single most underscoped item in the industry, priced as a footnote.
• No named delivery team. “We’ll assign resources” is a staffing model, not a project team.
• AI promises without prerequisites. Anyone promising agents on top of unexamined data hasn’t done this in production — the postmortems all rhyme.
• Acceptance criteria they’ll “define later.” Later is after your leverage is gone.
• Discomfort with this checklist. A capable partner has heard all these questions and answers them fluently. Defensiveness at diligence is data.

None of this requires a procurement department, and a good partner will respect you for asking — the firms worth hiring put most of it in the SOW unprompted. That’s the standard we hold our own consulting engagements to, and the one you should hold anyone to, including us.

Understanding the basics

What should a Salesforce implementation checklist cover before signing?

Eleven areas: named process and object scope with an explicit out-of-scope list; data migration ownership and remediation; the integration inventory; the environment and sandbox plan; the release approach; edition and licensing confirmed against the roadmap; the commercial model and change-order mechanics; the delivery team by name; acceptance criteria, UAT, and hypercare; documentation and admin handover; and a scan for red flags. All of it should be pinned down in or before the SOW, while you still have negotiating leverage.

Who should own data migration in a Salesforce implementation?

Ownership should be assigned per step in writing: extraction from legacy systems, field mapping, transformation, loading, and validation. In practice the partner typically owns the tooling and the load while the customer owns data quality decisions — which records to keep, merge, or archive — because only your team knows which records matter. The failure mode is a SOW that says “shared responsibility” — meaning nobody is responsible until the mess surfaces mid-project.

What is hypercare after a Salesforce go-live?

Hypercare is the elevated-support period immediately following go-live, when defects surface, users hit real-world edge cases, and adoption is most fragile. Before signing, confirm how long it lasts, what response times apply, whether it’s included or billed separately, and what happens to unresolved defects when it ends. A SOW with no hypercare provision means the engagement ends precisely when you need the partner most.

---

Holding a draft SOW and not sure what’s missing? Talk to us — we’ll tell you what we’d push back on before signing, even if the partner you’re evaluating isn’t us. For an honest read on whether your org is ready for an implementation at all, start with our Org Health Scorecard.