Salesforce Implementation Plan: 7 Phases, Template and Timeline

A plan made of seven boxes in a row is a picture of a project, not a plan. Anyone can draw it, nobody can defend it, and it answers none of the questions a sponsor actually asks: what has to be true before this phase starts, what proves it finished, and which single item will stop everything if it slips.

Seven phases follow, and they are conventional, which is fine. What makes a plan work is the criteria between them.

Twelve agents per organization change what a plan has to sequence

One thing has materially changed about Salesforce planning since the last generation of templates was written, and it is worth establishing before the phases.

Salesforce’s 11th Annual Connectivity Benchmark Report, published as its 2026 Connectivity Report and based on a survey of 1,050 enterprise IT leaders, found organizations running an average of twelve agents, with that number projected to climb 67 percent within two years. Its connectivity finding is stated flatly: 96 percent of IT leaders agree that AI agent success depends on data integration across all systems.

Read those two findings together. Agents are arriving at volume, and the thing they depend on is data integration. A plan that schedules integration as a mid-project build task and agents as a later feature has inverted its own dependency order, which is how an agent reaches user testing grounded on data that does not reach it yet.

So the classic seven-phase shape survives. What changes is which items are dependencies and which are deliverables, and that distinction is what the criteria below encode.

Seven phases carry a Salesforce plan from discovery to hypercare

Here is the sequence. Phase names are familiar; read the right-hand column, because that is where the planning content lives.

Two things about that table.

That third column is the plan. Everything else is a label. A phase with no stated precondition will start when the calendar says so rather than when it is ready, and a phase that starts unready produces rework that lands two phases later wearing a different name.

And the sequence is not strictly serial. Discovery for a later workstream can run while an earlier one builds, which is how programs phase by function or region. What cannot overlap is a dependency: nothing in column three bends because a date is tight.

Entry and exit criteria are what turn a phase into a gate

A phase boundary either tests something or it is a date in a calendar invite. Most plans have the second kind.

An entry criterion states what must be true to begin. An exit criterion states what proves the phase is done, in terms someone outside the project could verify. Both have to be falsifiable, which rules out most of what gets written.

Compare these two exit criteria for Design. “Design complete and approved” is unfalsifiable; it means whatever the person reading it wants. “Data model, sharing model and integration contracts documented and signed by the architect and sponsor, with no open decisions on the register” can be checked by someone who was not in the room.

Three properties make a criterion useful.

It names an artifact rather than a state of mind. Documents, signatures, test results and loaded record counts are checkable. Readiness, alignment and confidence are not.

It names who verifies it. A criterion with no verifier is a criterion nobody applies, which is most of them.

It is written before the phase starts, not during the argument about whether the phase finished.

What the first gate depends on is a sponsor with authority, which is also the output of a proper kickoff, covered in the kickoff that sets the first gate.

Integration is a dependency, not a phase

Most published Salesforce plans place integration somewhere in the build, between configuration and testing. That placement is the single most common structural error in the plans I have seen, and the Connectivity Report finding above explains why it matters more in 2026 than it did.

Integration is three separate things that belong in three different places.

The contract belongs in Design, before anything is built. Which system owns which field, which direction data flows, what the payload looks like, and what happens on failure. Agreeing that after the build has started means building twice.

The build belongs in Configure and build, where it is ordinary work.

The reconciliation belongs in Test, because an interface that moves data is not proven until both sides agree on what arrived.

Teams that treat integration as one block in the middle of the plan discover the contract problem during the build, which is the expensive moment to discover it. Where the data itself gets profiled, and why that belongs before kickoff rather than inside migration, is set out in what makes a date defensible.

Three gates decide whether the rest of the plan holds

Seven phases means six boundaries, and they are not equal. Three carry almost all the risk.

Design exit. The data model and sharing model leave this gate decided or they do not. Everything downstream assumes them, so a soft exit here propagates into every later phase. This is also where the configure-or-build decision per requirement should already be recorded, which is the output of how each requirement gets routed.

Test entry. Testing cannot start against an unstable build with unrepresentative data, and starting anyway produces defect reports that are really environment reports. Both halves of that precondition have their own discipline: what gets validated and by whom and the environment the test runs in.

Go-live entry. Acceptance signed, rollback rehearsed, support route published. Rehearsed is the operative word, since a rollback plan nobody has executed is a document rather than a capability. The full sequence sits in the cutover steps this gate approves.

Remaining boundaries matter and are recoverable. These three are not, which is the argument for spending review time unevenly rather than holding identical gate meetings six times.

Salesforce’s own phasing rule starts with one solved problem

Salesforce publishes a principle for phasing that is more useful than most methodology, and it is worth stating because it contradicts how scope usually gets set.

In its guidance on implementing projects with a phased approach, written for nonprofit implementations but general in its logic, Salesforce says the first phase should solve a real, tangible problem acknowledged by all key stakeholders, and should serve as a firm foundation for growth.

Two tests fall out of that, and most phase-one scopes fail at least one.

Does phase one solve something the business already agrees is a problem? Scope assembled from every department’s wish list solves nothing anyone was complaining about, and lands with users who were not waiting for it.

Is phase one a foundation the later phases build on? Accounts, contacts and the sharing model are foundational. A reporting suite is not, and shipping it first means rebuilding it when the data model underneath changes.

A phase one that passes both tests is usually smaller than the one originally proposed, which is the uncomfortable part.

The plan template carries nine fields per phase

A plan document that is a Gantt chart plus a paragraph cannot be used to run a project. Nine fields per phase can.

Two fields get skipped: verifier and client obligations, and both failures have the same shape. Without a verifier, exit criteria get self-assessed by the person motivated to move on. Without client obligations written as dated commitments, the project absorbs every delay the business causes and reports it as its own slippage.

Effort behind each phase is a separate calculation with its own discipline, set out in turning scope into a number you can defend.

GetGenerative.ai compresses three phases and leaves four alone

Any claim about AI and project plans should say which phases it touches. Most do not, which is why buyers discount them.

Looking at the seven phases, the effect lands on three. Discovery produces structured requirements and scope from workshop sessions rather than notes someone transcribes later. Design converts those into solution outlines, stories and acceptance criteria against a consistent format, and because the org itself gets read, a design reflects deployed configuration rather than remembered configuration. Test gets its case library generated from the same stories, which is what stops the test pack being written the week testing opens.

Four phases are substantially untouched, and saying so is the point. Data migration is bounded by source data quality and by client decisions about what the correct value is. Deploy and go-live is bounded by cutover windows and sign-off. Hypercare is bounded by real user behavior. Configure and build moves somewhat and remains real work.

So the honest read is that artifact-heavy phases compress and decision-heavy phases do not, and a plan that applies a uniform percentage across all seven is wrong in both directions. Teams who want a plan built this way can see how a delivery pod sequences the work.

Agents enter the plan twice and teams sequence only one

Given the adoption numbers above, most Salesforce plans written now contain agent work, and it enters at two separate points that get conflated.

Agents that help deliver the project are a tooling decision. They affect the three phases above and they belong in the resourcing section, not the scope.

Agents delivered as part of the solution are scope. An Agentforce deployment needs requirements, a design, grounding data, test cases and a consumption assumption, which means it touches every phase in the table. A planning error follows from treating that second category as a configuration task appended to the build, when its real dependency chain runs through integration and data readiness.

That dependency is what the 96 percent finding is about. An agent is only as useful as the systems it can reach, so agent scope inherits the integration contract agreed at Design exit. Sequencing an agent before that contract exists produces a demo rather than a deployment. The design artifact that carries both is covered in the document that records those decisions.

A plan fails at its gates rather than inside its phases

Worth being precise about where plans actually come apart, because it is not where post-mortems usually look.

Phases rarely fail. Work inside a phase takes longer or shorter than expected and the plan absorbs it. What fails is a boundary crossed without the criteria being met, because the cost of that appears two phases later and gets attributed to whatever was happening then.

Four gate failures recur.

Design exited with the sharing model unresolved, so build proceeds on an assumption and visibility defects surface in testing as functional bugs.

Test entered against a build that was still changing, so the defect log mixes real defects with version confusion and nobody trusts the count.

Go-live entered with acceptance signed by someone who had not used the system, which converts into hypercare tickets that are really unmet requirements.

Hypercare ended on a date rather than on a condition, handing an unstable org to a support team with no defect threshold agreed.

Each of those is prevented by one sentence written before the phase started, which is the entire argument for criteria over calendars.

When a gate fails, re-baseline rather than waive it

A gate that cannot be met leaves three options, and the one teams reach for first is the one that costs most.

Waiving it is the default. That phase proceeds, the criterion is marked as an exception, and the exposure moves downstream without a record. Occasionally correct for a minor criterion, and never correct for the three gates above.

Narrowing scope so the criterion is met is usually right. If the sharing model is unresolved for two of six objects, remove those two from the phase and let the other four exit cleanly. Scope stays honest and the unresolved items stay visible.

Re-baselining the plan is right when the criterion is unmeetable at current scope. Do it once, with new dates and new criteria, rather than through a run of small waivers that leaves nobody able to say what the plan now is.

Record which happened and who decided. A plan with a waiver history is a plan that can be audited after go-live, and the alternative is a project whose actual sequence exists only in people’s memories.

What sponsors ask about the plan

Which phases does a Salesforce implementation plan contain?

Seven: discovery, design, configure and build, data migration, test, deploy and go-live, and hypercare. The phase names matter less than the entry and exit criteria between them, since a boundary that tests nothing is a date rather than a gate.

What should a Salesforce implementation plan template include?

Nine fields per phase: objective, entry criteria, exit criteria, named deliverables, a single owner, a verifier, dependencies, client obligations with dates, and carried risks. Verifier and client obligations are the two most often omitted, and omitting them means exit criteria get self-assessed and client-caused delays get reported as project slippage.

Which phase boundaries matter most?

Three. Design exit, because the data model and sharing model are assumed by everything after it. Test entry, because testing an unstable build with unrepresentative data produces defect reports that are really environment reports. Go-live entry, because acceptance and a rehearsed rollback cannot be recovered after cutover.

Where does integration belong in the plan?

In three places, not one. The contract belongs in design before anything is built, the build belongs in configure and build, and reconciliation belongs in test. Salesforce’s 11th Annual Connectivity Benchmark Report found 96 percent of IT leaders agreeing that AI agent success depends on data integration across all systems, which makes the contract a design-phase dependency rather than a mid-build task.

How should agent work be sequenced in an implementation plan?

Separate agents used to deliver the project from agents delivered as part of the solution. The first is a resourcing decision. The second is scope that needs requirements, design, grounding data, test cases and a consumption assumption, and its dependency chain runs through the integration contract, so it cannot be appended to the build as a configuration task.

What should happen when a phase cannot meet its exit criteria?

Narrow the scope so the criterion is met, or re-baseline the plan once with new dates and criteria. Waiving the criterion moves the exposure downstream without a record, which is acceptable only for minor items and never for design exit, test entry or go-live entry. Record which option was taken and who decided it.