On this page (6)
A Salesforce go-live has three parts. Before launch, you confirm written readiness criteria and hold a go/no-go meeting. During cutover, you freeze changes, load the final data, switch integrations, open access and tell people what changes on Monday. After launch, a hypercare team fixes problems fast for the first few weeks while you watch logins, data entry, errors and support requests. Most launch trouble comes from skipping one of those three, not from Salesforce itself.
Agree what "ready" means before the date arrives
Launch dates tend to become fixed long before anyone can say whether the system is finished. The way to keep that date honest is to write the readiness criteria early, attach an owner to each one, and review them at a go/no-go meeting a few days before cutover. If a criterion is not met, the meeting decides whether to launch with a known workaround, trim scope, or move the date. What it should never do is quietly lower the bar.
| Area | Ready when | Signed off by |
|---|---|---|
| User acceptance testing | Every priority test script has passed, and open defects are logged with a severity and a workaround | Business process owners |
| Data | A full rehearsal load in a sandbox reconciled against source counts, with owners and relationships intact | Data owner |
| Integrations | End-to-end tests passed with production-like volumes, and error alerts reach a named person | Integration lead |
| Security and access | Profiles, permission sets and sharing tested as real users in each role | Salesforce admin |
| Training | Each user group has completed role-based training and knows where to get help | Training lead or department managers |
| Support | Hypercare roster, request channel and escalation path published | Project sponsor |
| Rollback | A written plan for what happens if cutover fails partway through | Project manager |
Keep the list short enough to review in one meeting. If you need forty criteria to feel safe, the real issue is usually scope, and a phased launch will serve you better than a longer checklist.
Run the freeze and cutover as a script
Cutover is the window between the last day people work in the old system and the first day they work in Salesforce. Write it as a timed runbook, with each step, its owner, its expected duration and the check that proves it worked. Rehearse the runbook in a Full or Partial Copy sandbox at least once, time it, and use the real timings to choose the window.
- Announce a configuration freeze in Salesforce, typically a week or two before launch, so the version you tested is the version that ships.
- Set the legacy system to read-only, or agree a hard stop time after which new records go on a holding list.
- Run the final data load in the rehearsed order, then the delta of records created or changed since the rehearsal.
- Reconcile record counts and spot-check a sample of records against the source with a business user watching.
- Point integrations at production, confirm credentials and endpoints, and send one real transaction through each one.
- Activate automation that was held off during the load, such as Flows that send emails or create tasks.
- Check the email deliverability setting in production and the From addresses that customer-facing emails use.
- Record the go-live state: what was deployed, what was loaded, and which known defects shipped.
Automation order matters more than teams expect. If record-triggered Flows are active while you load historical data, customers can receive welcome emails for accounts they opened years ago. Loading with those Flows switched off, then turning them on once reconciliation passes, avoids a very public mistake. The same caution applies in sandboxes: Salesforce sets new and refreshed sandboxes to send system email only, so test emails often fail silently until someone changes that setting on purpose.
User access and launch communications
Create users ahead of time but hold their welcome emails until cutover is complete, so nobody logs in to half-loaded data. Salesforce lets you freeze a user account, which blocks login without removing the user; that is useful for staging accounts in advance, though frozen users still consume licenses. Assign permission sets by role rather than by person, and test a login for one real user in each role on launch morning before the rest are invited.
Communication should answer three questions for each group: what changes for me, when does it change, and where do I go when something looks wrong. Send it from the business leader who owns the process rather than from IT, and repeat it on launch day. Tell users which old tools are retired and on what date, because a spreadsheet left open as a backup quietly becomes the real system.
A marketing firm we worked with moved every sales cadence off another sales-engagement tool while its reps kept selling. The migration finished on time with zero disruption and 100% rep adoption, largely because the cutover was planned around the team's daily selling rather than around the project calendar.
Staff hypercare like a short, intense support desk
Hypercare is the period right after launch when the project team, not a general help desk, handles every issue. Two to four weeks is common for a single-cloud launch; complex programs with several integrations may need longer. What matters is a clear exit condition, such as a week with no new high-severity issues and request volume back to a level the ongoing support model can absorb.
- One intake channel for every request, so issues are not scattered across email, chat and hallway conversations.
- Severity definitions everyone understands: work stopped, work slowed, cosmetic or a question.
- A short daily triage meeting to review new issues, assign owners and decide what gets deployed that day.
- Floor-walkers or named super users in each team who can answer how-to questions on the spot.
- A small, tested deployment path for fixes, rather than edits made directly in production under pressure.
- A running list of enhancement requests, parked for a later release instead of built during hypercare.
What to measure in the first weeks
A launch is only successful if people use the system for the work it was built for. Pick a handful of measures before go-live, capture a baseline from the old process where you can, and review them weekly during hypercare and monthly afterward.
| Measure | Where to look | What it tells you |
|---|---|---|
| Logins by user and role | Login History in Setup, which shows the past six months | Who has not started using the system at all |
| Records created per user | Reports on the objects each role should be working | Whether people are doing their work in Salesforce or elsewhere |
| Required data completeness | Reports filtered for blank key fields | Whether page layouts and validation rules fit the real process |
| Support requests by type | The hypercare intake queue | Which areas need retraining, fixes or design changes |
| Integration and automation errors | Integration logs, error emails and failed Flow interviews | Hidden failures that users may not notice for days |
| Process outcome | The business metric the project was meant to move | Whether the investment is paying off |
Look at the measures by team, not only in total. An average can hide one region or department that never started, and that group is where the next round of coaching, or a missed requirement, is usually found.
Hand over deliberately when hypercare ends
Close hypercare with a short handover: open defects and their owners, the enhancement backlog ranked by the business, current documentation, and who supports the org from now on. That might be an internal admin, a managed services partner or both. Schedule a review about 60 to 90 days after launch to compare the measures against the baseline and decide what the next release should fix or add.
Questions people also ask
What problems are typical after a Salesforce go-live?
The typical problems are users who never start using the system, blank key fields, hidden integration and automation errors, and a flood of requests for things that were never in scope. Automation is a common culprit: if record-triggered Flows are active during the data load, customers can get emails for old accounts. Watch logins, records created per user, data completeness and failed Flow interviews by team, because an average can hide a group that never started.
Who owns production issues in the first 30 to 90 days after go-live?
The project team owns production issues during hypercare, not a general help desk. Two to four weeks of hypercare is common for a single-cloud launch, and complex programs with several integrations may need longer. Hypercare should end on a clear condition, such as a week with no new high-severity issues, followed by a handover to an internal admin, a managed services partner or both. Schedule a review about 60 to 90 days after launch.
What ongoing costs should we expect after go-live?
Your ongoing costs depend mainly on who supports the org after hypercare: an internal admin, a managed services partner or both. The other drivers are the enhancement requests parked during hypercare for later releases, the defects that shipped with known workarounds, and monitoring integrations and automation for errors. Licenses matter too, since frozen users still consume them. A review 60 to 90 days after launch is a good point to decide what the next release should fund.
