Salesforce Implementation Planner
A practical structure for planning a Salesforce or marketing technology implementation, with phases, workstreams, dependencies and example rows you can adapt.
A Salesforce implementation plan fails in predictable ways. Build starts before decisions are made, data arrives late, testing gets squeezed, and the people who will own the platform meet it for the first time at training. The implementation planner is a structure that makes those risks visible early.
This page describes what the planner contains and how to use it. It works for a core CRM rollout, a Marketing Cloud Engagement or Marketing Cloud Next implementation, an Account Engagement setup or a Data Cloud programme. The phases are the same; the workstreams and dependencies change.
What the planner contains
- Phases with exit criteria, so "design complete" means something specific.
- Workstreams that run in parallel, each with an owner.
- Dependencies, especially those outside the project team's control.
- Milestones and decision points where the sponsor confirms scope or approves the next phase.
- A RAID log: risks, assumptions, issues and decisions, kept alongside the plan rather than in a separate document nobody opens.
Phases the planner lays out
- 01
Discover
Confirm goals, users, current systems, data sources and constraints. Exit when scope, success measures and the first-release boundary are agreed.
- 02
Design
Produce the solution design, data model, integration design, consent model and security model. Exit when each design is reviewed and signed off by its owner.
- 03
Build
Configure and develop in sandboxes in short iterations, with demos to business users. Exit when all in-scope stories pass system testing.
- 04
Test
Run integration testing, data migration test loads and user acceptance testing. Exit when UAT is signed off and open defects are accepted or fixed.
- 05
Launch
Deploy, run cutover steps, migrate data, train users and switch on automation in a controlled order. Exit when go-live checks pass.
- 06
Hypercare and optimise
Support users closely for an agreed period, fix early issues and start measuring against the baseline. Exit when support moves to the normal run model.
Workstreams to plan in parallel
Solution and configuration
Objects, automation, user interface and security model, built iteratively in sandboxes.
→Data and migration
Profiling, cleansing, mapping, test loads and the final cutover load.
→Integration
Interfaces to ERP, ecommerce, data platforms and identity providers, including error handling.
Marketing setup
Sender authentication, data model, consent, templates and the first journeys.
→Testing and quality
Test strategy, test data, UAT scripts and defect triage.
Change and adoption
Communications, training and the post-launch ownership model.
Example plan rows
| Phase | Owner | Depends on | Exit evidence | |
|---|---|---|---|---|
| Agree success measures | Discover | Sponsor | Baseline data from current reports | Signed measures with baseline values |
| Choose primary customer identifier | Design | Data lead | Profiling of source systems | Decision recorded in RAID log |
| Approve consent model | Design | Compliance lead | Review of current policy and capture points | Signed consent matrix |
| Configure sending domain | Build | Marketing ops | DNS changes by IT | Authentication records verified |
| First full test data load | Test | Data lead | Mapping sign-off and sandbox refresh | Record counts reconciled to source |
| UAT of priority journeys | Test | Business lead | Test data and scripts ready | UAT sign-off with defect log |
| Production cutover | Launch | Release manager | Go/no-go approval | Cutover log completed |
Dependencies that usually sit on the critical path
The tasks inside the project team are rarely what delays a go-live. These are:
- Licence provisioning and sandbox access, including the right sandbox type for full data testing.
- Access to source systems and extracts, which often needs approvals from another team.
- DNS changes for email authentication (SPF, DKIM and DMARC), owned by IT or a hosting provider. See SPF, DKIM and DMARC for Marketing Cloud.
- Legal or compliance sign-off on consent wording and data use.
- Third-party APIs and environments, whose test systems may be unavailable or unlike production.
- Business users' time for UAT, which competes with their day jobs.
Put each of these on the plan with an owner outside the project team and a date by which it is needed, then track it weekly.
Keeping the plan honest
- Re-baseline openly when scope changes, rather than quietly compressing testing.
- Hold back contingency at phase level, not hidden in individual tasks.
- Review the RAID log in every status meeting and close decisions with a date and a name.
- Measure progress by exit evidence achieved, not by tasks marked complete.
For scoping before you plan, read how to scope a Salesforce marketing implementation.
Plan your implementation with us
GeekMidst can help shape a phased plan, test its assumptions against your org and data, and run delivery alongside your team.
