Salesforce Go-Live Checklist: Cutover, Rollback and Hypercare

Nearly every go-live checklist contains the line “prepare a rollback plan” and then moves on. It is the least useful instruction in delivery, because on Salesforce the answer depends entirely on what you changed, and some of what you changed cannot be undone at all.

A rollback plan that does not say which parts are unrecoverable is not a plan. It is reassurance.

Three classes of change sit behind any Salesforce rollback plan

Before a runbook, a go-live needs this classification applied to its own change list. Every item belongs in one of three categories, and the categories behave completely differently under pressure.

The middle row is the one that catches experienced teams, because the change appears in Setup like any other and therefore looks safe.

Note what is not in row one. Metadata is reversible as a category and field changes are the exception inside it, which matters because field changes are among the commonest things a cutover carries.

Work through the change list and assign a class to each item before the cutover weekend, not during it. Anything landing in row three stops being a technical decision and becomes a business decision, because the question is no longer how to undo it but whether to proceed at all.

Multi-currency is permanent, and Salesforce says so plainly

The cleanest example of row three, and worth quoting because teams enable it on a Friday assuming it behaves like any other setting.

Salesforce’s own guidance on enabling multiple currencies opens by stating that enabling multiple currencies introduces permanent changes in the org, and then says it directly: after you turn on multiple currencies for your Salesforce org, you can’t turn it off.

There is a second clause with its own trap. Once a currency is added to the org’s list of supported currencies, it cannot be deleted from the administrator’s list, even after it is deactivated. A deactivated currency stops being visible to end users and stays visible to administrators, which Salesforce describes as cosmetic, and which in practice means a test currency enabled during a rushed cutover is in that list permanently.

So the practical rule for any feature in this class is that the sandbox is the only place to find out. Salesforce makes that recommendation itself for multi-currency, and the environment question behind it sits in choosing the sandbox to prove it in.

Converting a field type can delete the data and the list views with it

Salesforce documents eleven conversions that risk data, and its own advice is blunt: only convert custom fields that have no data.

The pattern across that list is worth knowing rather than learning. Conversions to or from Date and Date/Time risk data. So does converting to Number, Percent or Currency from anything else. So does moving away from Checkbox, in either direction with Multi-Select Picklist, and in either direction with Auto Number. Text to Picklist is on the list, as is Text Area (Long) to most types.

Two consequences make this a row-two item rather than a row-one item.

Changing the type back does not bring the values back. The metadata reverts and the data does not, which is the definition of reversible with damage.

And the damage spreads past the field. Salesforce states that if data is lost, any list view based on that custom field is deleted, and assignment and escalation rules can be affected. So a field conversion during cutover can remove a report-adjacent artifact nobody put on the change list.

There is a narrower version of the same trap in picklists. Converting a picklist to multi-select keeps the defined values, but record values that were never in the picklist definition are deleted from those records at conversion.

Disabling state and country picklists reverts only the untouched records

This is the row-two example, and the detail matters because the feature does have a disable path, which is exactly what makes it dangerous.

Salesforce documents that state and country/territory picklists can be turned off by clicking Disable on their setup page. The reversal is partial, and the condition is precise: for records that you have not saved since enabling picklists, state and country values revert to their original text values.

Read the condition carefully. Records nobody has touched since the switch come back. Records that have been saved since enabling do not, so a week of normal user activity converts a reversible change into a data reconciliation exercise. Customizations referencing the picklists are affected too.

So a change in this class has a shelf life on its reversibility, measured in user activity rather than in days. That is a different kind of risk from the metadata in row one, and it belongs in the rollback plan as a stated window rather than as an assumption that Disable restores the prior state.

Migrated data stops being reversible the moment a user transacts on it

The largest row-three item on most go-lives is not a feature. It is the data.

Loading records into production is reversible in the trivial sense that records can be deleted. It stops being reversible the moment users begin working on them, because what has to come back is not the data you loaded but the data plus everything that happened to it: new opportunities on migrated accounts, cases logged against migrated contacts, activity history, field updates, approvals in flight.

So the reversibility question for data has a specific trigger, and it is user access rather than the load itself. That has two consequences for sequencing.

Validate the load before any user is let in, because the window where a bad migration can still be cleanly removed closes when the first user logs in rather than when the load finishes.

And define what a failed migration means numerically before the window opens. Record counts by object, a reconciliation of totals for anything financial, and a spot check of relationships. “The data looks right” is not a cutover decision.

The cutover sequence has a fixed order and three freeze points

Before the runbook format, the order. Cutover steps are not interchangeable, and the sequence below is driven by what each step makes irreversible.

Three freezes carry the sequence, and each is a commitment someone has to make rather than a task. Configuration freeze protects the rehearsal’s validity. Data freeze decides whether a delta load is needed, which is the single largest variable in window length. And access freeze, meaning nobody gets in before reconciliation passes, is the one that preserves the abort option.

Rehearsal is the step most often dropped for time, and it is the only one that tells you how long the window actually takes. A rehearsal that runs four hours longer than planned has given you the most useful number in the plan.

A cutover runbook holds eight columns per step

A runbook written as a list of tasks produces a cutover where nobody knows whether step eleven is late. Eight columns make the window governable.

Verification and the reversible flag are the two that get dropped, and they are the two that make the runbook useful at 2am. A step marked done because the script ran is not evidence. A step whose reversible flag reads no tells the person running the window that the decision point has already passed.

What authorizes the window in the first place is the signed acceptance from testing, covered in the sign-off this window depends on.

Sequence the irreversible steps as late as the dependencies allow. If multi-currency has to be enabled, it goes after everything that could still cause an abort, because once it is on, the abort option is gone. Where this runbook sits relative to the phase gates is set out in the plan that authorizes this window.

GetGenerative.ai reads the org so the classification is not from memory

The classification above only works if the change list is accurate and complete, and that is where go-live preparation usually fails rather than in the runbook format.

The reason is ordinary. A project of any length accumulates configuration beyond what the design document describes. Somebody added a validation rule during UAT to unblock a tester. A field got renamed. A permission set grew. By cutover weekend, the authoritative statement of what is being deployed exists in the metadata rather than in any document, and the team is working from the document.

GetGenerative.ai closes that gap by inspecting the org itself, so a cutover change list gets assembled from what is deployed rather than from recollection and a design three sprints old. For a go-live that matters more than on other artifacts, because an item missing from the change list is an item with no reversibility class, no verification step and no owner at 2am.

What no tool decides is the business question underneath. Whether to proceed when a required step is permanent, how much reconciliation variance is acceptable, and who is authorized to call an abort at 3am: those belong to named humans and should be settled in daylight. Teams wanting that run by people who do it repeatedly can talk to us about post-go-live support.

A rollback decision needs a trigger, an owner and a deadline

Most rollback plans fail not because reversal was impossible but because nobody decided in time.

Three elements prevent that, and all three are written before the window opens.

A trigger expressed as a condition, not a feeling. Data reconciliation variance above an agreed threshold. A blocking defect in a critical path with no workaround. Integration failure that cannot be cleared within a stated number of hours. Written triggers turn an argument into an observation.

A named decision owner with authority to abort, available for the whole window and not on a plane. One name. A decision needing three people to agree at 3am is a decision that will be deferred until reversal is no longer possible.

A deadline, because reversibility decays. The point of no return is a specific hour in the runbook, usually the moment users are admitted or the first irreversible step completes, whichever is earlier. After that the only options are forward.

Whether a deployment can be reversed at all depends on the tooling that moved it, and what each option does and does not give you is compared in deployment tooling and its limits.

Partial rollback deserves naming as the realistic middle path. Reverting one integration while leaving the rest live, or restricting a feature to a pilot group rather than withdrawing it, is usually available when full reversal is not. It needs planning in advance to be executable under pressure. Which failures justify any of this is a triage question, covered in how defects get classified and ranked.

Hypercare needs severity routing and a numeric exit, not a duration

Hypercare is commonly specified as two weeks of heightened attention, which gives it no entry condition, no routing and no way to end.

Three mechanics make it function.

A severity scale agreed with the business before go-live, with a response commitment against each level and a named route for each. The scale matters less than the fact that the business agreed it when calm, because every ticket in week one arrives described as urgent.

A single intake route that users actually know. Hypercare tickets arriving through four channels cannot be counted, and a hypercare period whose volume is unknown cannot be assessed. Publishing one route, and telling users what it is during training, is most of the work.

A numeric exit measure. Open severity-one defects at zero, severity-two below an agreed count, and ticket volume trending down across a stated number of days. That converts the end of hypercare into an observation rather than a negotiation, and it gives the receiving support team something to accept.

The handover itself is a deliverable rather than a meeting. Known issues with owners, the defect log at its current state, the configuration changes made during hypercare, and whatever was learned about the data. Who then owns the org, and under what cadence, is a governance question rather than a cutover one.

Agents add a monitoring obligation that hypercare has not carried before

Where an agent went live, hypercare acquires something it has not previously had to watch, and the usual metrics do not surface it.

Ticket volume and defect counts catch broken things. An agent that is working but reasoning poorly produces neither, because the user receives a plausible answer and does not report it. The failure is silent and compounding, and it surfaces weeks later as a pattern rather than as an incident.

Two additions to a hypercare plan where agents are in scope.

Sample agent conversations deliberately during the window rather than waiting for complaints, and review the basis of the decision rather than only the outcome. A small daily sample read properly beats a dashboard of volumes.

Watch consumption as a behavioral signal, not only as a cost line. An agent taking more actions per conversation than the design assumed is telling you something about its instructions before it tells you something about the bill.

Who owns the agent after the project team leaves is the part most often unassigned, and it is set out in who holds the agents after launch.

Six questions decide whether a go-live is ready

What should a Salesforce go-live checklist cover?

The cutover window specifically: a step-by-step runbook with owners, dependencies and verification, a reversibility class for every change, a rollback decision with a trigger and a named owner, and hypercare with severity routing and a numeric exit. Whole-project readiness is a different document.

What cannot be rolled back in Salesforce?

Some changes have no supported reversal. Salesforce states that enabling multiple currencies introduces permanent changes and that once turned on it cannot be turned off, and that a currency added to the supported list cannot be deleted even once deactivated. Migrated data becomes effectively irreversible once users transact on it, because restoring it would mean discarding their work.

Can state and country picklists be disabled after enabling?

Yes, by clicking Disable on their setup page, but the reversal is partial. Salesforce documents that values revert to their original text only for records not saved since the picklists were enabled. Records saved since then keep picklist values, and customizations referencing the picklists are affected, so reversibility decays with user activity.

When is the point of no return in a Salesforce cutover?

Whichever comes first: the moment users are admitted to production, or the completion of the first irreversible step. Both should be marked as a specific hour in the runbook, because a rollback decision taken after that point is not available regardless of what the plan says.

How long should Salesforce hypercare last?

Specify it as a condition rather than a duration. Open severity-one defects at zero, severity-two below an agreed count, and declining ticket volume across a stated number of days. A two weeks with no exit measure ends when the calendar says so, which hands an unstable org to a support team that never agreed to receive it.

What changes about hypercare when an agent is live?

Standard metrics miss the main risk. An agent that answers plausibly but reasons poorly generates no tickets and no defects, so the failure is silent. Sample conversations daily and review the basis of each decision rather than only the outcome, and treat higher-than-expected consumption per conversation as a behavioral signal about instructions rather than only a cost variance.