ChatGPT
Claude
PerplexitySalesforce Implementation Lifecycle: A Complete Guide
Two different things are called the Salesforce implementation lifecycle, and which one you mean changes every answer that follows.
The first is a project lifecycle: discovery, design, build, migrate, test, deploy, hypercare. It runs once and it finishes. The second is a development lifecycle: plan, build, test, deploy, monitor, repeat. It starts when the first one ends and it never finishes.
Most guidance describes one and titles it as the other. The handoff between them is where orgs quietly begin accumulating the debt that shows up two years later.
The project lifecycle ends; the development lifecycle does not
Project lifecycle | Development lifecycle | |
|---|---|---|
Shape | Linear, with a defined end | A loop, running indefinitely |
Triggered by | A funded programme | Every change request and every seasonal release |
Owned by | A project manager or delivery partner | An internal platform owner |
Measured by | Delivery to scope, date and budget | Change lead time, release stability, defect escape rate |
Ends when | Hypercare closes | It does not |
The commercial consequence is that a partner who delivers the first and never establishes the second has finished the engagement and left you without an operating model. That is the most common structural failure in Salesforce ownership, and it is invisible at go-live because everything works on the day.
The project lifecycle runs discovery through hypercare
Seven stages, and the value is in the exit condition of each rather than the name.
Mobilise establishes decision rights. Discover produces ranked requirements. Design fixes the object and security model. Migrate and integrate profiles and moves the data. Build produces deployable configuration. Validate obtains sign-off against acceptance criteria. Cut over and stabilise moves it to production and holds it steady.
Each of those has a completion test and a set of dependencies that decide what can safely overlap. Rather than repeat it here, the plan and template version sets out the entry and exit criteria per stage.
What matters at lifecycle level is the last stage, because hypercare is not the end of the project. It is the overlap period where the second lifecycle is supposed to be standing up.
The development lifecycle runs plan, build, test, deploy, monitor
The second loop is the one Salesforce itself documents, and it is worth reading in the platform’s own terms. Salesforce describes the software development lifecycle as planning, analysis, design, development, testing, deployment and maintenance, which maps closely to how a Salesforce org actually changes after go-live.
In practice on Salesforce it needs four things a project does not:
An environment strategy that persists. Which sandbox does what, refresh cadence, and which instances sit on a preview release. A project can improvise this. A permanent loop cannot.
A release cadence. Weekly, fortnightly or monthly, agreed and held. Without one, changes queue and arrive as an unmanaged batch.
A regression pack. The test suite that proves a change did not break something else. Most projects build test scripts and then discard them, which is the single most wasteful habit in Salesforce delivery.
A named owner. One person accountable for the backlog, the environments and the release calendar.
Salesforce publishes deployment best practices covering how changes move between environments, which is the mechanical half of this loop.
Go-live is the handoff between the two lifecycles
Treat it as a transfer of ownership rather than a date.
Five things must move across, and each one has a receiving owner rather than a delivery owner:
- The backlog, with the conditional sign-off items from validation already in it.
- The environment plan, including refresh dates and which sandboxes are on preview instances.
- The regression pack, seeded from the scripts that found defects during validation.
- The documentation, at whatever quality it reached, with its gaps named.
- The consumption position, meaning who watches metered agent and data usage and against what threshold.
A project that closes without transferring all five has not finished. It has stopped.
Seasonal releases force the loop three times a year
The development lifecycle is not optional even for an org with no roadmap, because Salesforce upgrades production on its own schedule three times a year and sandboxes on preview instances receive the release earlier.
That imposes a minimum cadence on any org: check release notes, test against your customisations in a preview sandbox, and act on any Release Updates due. An org with no development lifecycle still experiences this, it simply experiences it unprepared, which is why release weekends produce incidents in some organisations and nothing at all in others.
Agents added a third loop inside the development lifecycle
This is the change most lifecycle guidance has not caught up with. An org running Agentforce carries an agent lifecycle that behaves differently from configuration change.
Configuration is tested to a pass. Agent behaviour is scored against quality dimensions such as factuality and instruction adherence, so its release gate is a threshold rather than a signature. Configuration is stable until someone edits it. Agent behaviour can drift as knowledge sources and data change underneath it, which means it needs monitoring in production rather than only validation before release.
Practically, that adds two recurring activities to the loop: a regression run of agent test suites before each version commit, and ongoing observation of live agent quality. Neither existed in a Salesforce lifecycle three years ago. Both belong in the operating model you hand over at go-live.
The handoff between Salesforce lifecycles fails in six ways
Failure | What it looks like later | Prevention |
|---|---|---|
No named platform owner | Requests route to whoever answers | Name the owner before hypercare closes |
Regression pack discarded | Every release is a full manual retest | Keep the scripts that found defects |
Environment plan undocumented | Sandbox refreshes surprise the team | Hand over refresh dates and preview status |
No release cadence agreed | Changes arrive as an unmanaged batch | Set the cadence during hypercare, not after |
Consumption unwatched | Metered usage grows unnoticed | Assign a threshold and an owner |
Conditional sign-offs lost | Accepted gaps become disputed memories | Move them into the backlog with dates |
The pattern across all six is the same. Each is something the project team held informally and nobody formally received.
The two Salesforce lifecycles, condensed
Item | Detail |
|---|---|
Project lifecycle | Mobilise, discover, design, migrate, build, validate, cut over and stabilise |
Development lifecycle | Plan, build, test, deploy, monitor, repeat |
Relationship | The first terminates into the second at go-live |
Minimum cadence forced by the platform | Three seasonal releases a year |
Third loop, new since 2024 | Agent design, scoring and production monitoring |
Five handover items | Backlog, environment plan, regression pack, documentation, consumption position |
Most common structural failure | A project that ends without establishing the loop |
Release gate difference | Configuration passes; agent behaviour scores against a threshold |
One team carries both Salesforce lifecycles
The reason the handoff fails so often is that the two lifecycles are usually bought from different people. A delivery partner is measured on the project and leaves; an internal team inherits a loop it did not design.
GetGenerative.ai runs both through Forward Deployed Engineer pods, with the Metadata Agent maintaining the org picture, the Testing Agent maintaining the regression pack, and the Support Agent handling the change queue after go-live, so the operating model exists before the project closes rather than after. For how the delivery model behind that works, see the AI-led lifecycle pillar, or AI-first Salesforce implementation services for how engagements are structured.
Questions teams ask about the Salesforce implementation lifecycle
What is the Salesforce implementation lifecycle?
Two things share the name. A project lifecycle running discovery through hypercare, which ends, and a development lifecycle running plan through monitor, which does not. The first terminates into the second at go-live, and confusing them is why most published guidance answers the wrong question.
What are the phases of a Salesforce implementation?
Mobilise, discover, design, migrate and integrate, build, validate, then cut over and stabilise. Each has an exit condition rather than only a duration, and the order in which stages begin differs from the order in which they finish.
How is the Salesforce development lifecycle different?
It is a loop rather than a line. It needs a persistent environment strategy, an agreed release cadence, a regression pack and a named owner, none of which a one-off project requires. Salesforce forces a minimum cadence through three seasonal releases a year.
What should be handed over at go-live?
The backlog with conditional sign-offs in it, the environment plan with refresh dates and preview status, the regression pack, the documentation with its gaps named, and the consumption position with an owner and a threshold. A project that transfers fewer than five has stopped rather than finished.
Do AI agents change the lifecycle?
Yes, by adding a loop. Agent behaviour is scored rather than passed, and it can drift as underlying data and knowledge change, so it needs a regression suite before each version commit and monitoring in production rather than validation alone.
Who should own the lifecycle after implementation?
One named internal person, accountable for the backlog, the environments, the release calendar and the consumption trend. Distributing those four across a committee produces an org where each is technically covered and none is actually owned.
