A Salesforce cutover is the controlled switch from the current operating state to the new production state. It may involve a new org, a legacy CRM replacement, a large data move, or a release that changes a core process. The technical deployment is only one part of the event. Cutover also covers the point when changes stop, the final data movement, the decision to open the new state to users, and the recovery path if the release cannot continue safely.
A Salesforce cutover checklist turns those decisions into an ordered runbook. Each task needs an owner, evidence, a deadline, and a condition for moving forward. Business and technical teams also need a shared rule for when the source becomes read-only, which system owns new transactions, how results will be checked, and who can call a rollback.
This guide focuses on the Salesforce data freeze, parallel operations, rollback, rehearsal, final extraction, deployment order, reconciliation, go/no-go rules, and stabilization.
TL;DR
A workable Salesforce cutover checklist is an execution plan. Freeze metadata and source writes at stated times, take the final backup and extract after the freeze boundary is clear, then load data in the rehearsed dependency order. Validate the release in production before the window where the deployment method allows it. Use a short parallel period only for a defined business risk. Set go/no-go thresholds before the event. The rollback plan must state what gets reversed, how data and metadata recover, how integrations return to the prior route, who decides, and how much time remains for recovery.
What A Salesforce Cutover Actually Controls
A cutover controls state. Before the cutover, the old state is authoritative. After the cutover, the new Salesforce production state becomes authoritative for the processes named in scope. The danger sits in the transition between those 2 conditions because metadata, records, integration traffic, scheduled jobs, user activity, and external systems can all change at different times.
Salesforce itself recommends using development and test environments instead of making risky changes directly in production. Its deployment guidance explains that production changes should pass through testing stages so teams can validate integrated behavior and practice the release before users depend on it. That principle matters during cutover because a deployment package that worked in isolation can still fail when production data, permissions, integrations, and timing come together.
A useful Salesforce cutover plan should define 5 boundaries. First, define the release boundary: exactly which metadata and configuration changes are included. Next, define the data boundary: which records and fields move and which stay behind. Define the integration boundary: which interfaces change endpoints or ownership. Define the user boundary: which groups can work in which system at each stage. Finally, define the time boundary: the latest time each step may finish before the plan moves to rollback or repair.
Those boundaries prevent a common cutover problem: teams treating the event as one deployment command. A release can technically succeed while the business cutover fails. For example, Apex and Flow may deploy correctly while record ownership is wrong, a downstream ERP is still reading from the old source, or users are entering transactions in both systems. The Salesforce cutover checklist must therefore cover technical state and business state together.
Build The Cutover Timeline And Ownership Model
The Salesforce cutover checklist should be written in clock order. Start with the last normal business period, then move through freeze, backup, extract, deployment, load, validation, go/no-go, opening to users, and stabilization. Each line needs a start time, expected finish time, owner, dependency, evidence, and fallback action.
Salesforce advises teams to plan deployment prerequisites and dependencies before moving changes. Its deployment preparation guidance calls out source and target authorization, metadata dependencies, supported metadata, and configuration data that may need to move. Put those checks before the production window so the team is not discovering missing components during cutover.
One cutover manager should control the runbook and timekeeping. Technical owners should report completion with evidence. Business owners should validate the workflows they own. A release authority should make the go/no-go decision using thresholds approved before the event, and the person who can authorize rollback should already be named.
Add hold points where the next step cannot start until evidence exists. Typical hold points include source freeze confirmation, backup completion, record reconciliation, smoke-test results, and business sign-off. The Salesforce cutover plan should also state the latest safe rollback start. Work backward from the required service time so the team does not spend the recovery window trying to rescue a failing release.
Set Pre-Cutover Readiness Gates
The Salesforce cutover plan should begin execution only after measurable readiness gates pass. The goal is to remove discovery work from the production window. A readiness gate is stronger than a label such as “UAT complete” because another person can inspect the evidence.
Salesforce DevOps Center guidance stresses controlled project and release paths where metadata overlaps. Its DevOps Center project guidance also calls out branch and environment discipline. For cutover, the release artifact should be fixed before the freeze so local admin edits or unreviewed work do not change the expected production state.
Use these gates before approving the Salesforce cutover checklist:
· Release scope is fixed and mapped to the approved build or commit.
· High-severity test defects are closed or have an accepted treatment.
· Business owners have signed off the workflows they will validate after deployment.
· Production permissions and access changes have been tested with representative users.
· Integration owners have tested authentication, endpoints, retries, and failure handling.
· Salesforce data migration mapping is signed off, including legacy IDs, ownership, required fields, and relationship rules.
· Final load order has been rehearsed with production-like volumes.
· Backup and restore steps have been tested.
· Monitoring queries and smoke tests are ready before the window opens.
· Rollback has a tested sequence and named decision owner.
Salesforce describes Full sandboxes as copies that include production data and metadata and support staging, load testing, and performance testing. Its sandbox environment guidance helps teams choose a rehearsal environment. If the test environment differs from production, record those differences and treat them as open cutover risks.
The readiness meeting should end with approval or a block. If the team accepts an exception, record the owner, risk, workaround, and the point at which that exception becomes a no-go condition.
Design The Salesforce Data Freeze
The Salesforce data freeze protects the cutover from moving targets. It defines which changes stop, where they stop, and when. A freeze may cover source records, Salesforce metadata, integration writes, scheduled jobs, or only the parts affected by the move. It should be narrow enough to limit business disruption and strict enough to make the final extract trustworthy.
Salesforce migration readiness guidance includes go-live communication, data freeze windows, access changes, and training. The migration readiness checklist also recommends a production-like sandbox and a working group that reviews migrated data. Use that same operating model for the Salesforce data freeze: users get exact instructions, and named reviewers verify that the frozen source matches the extract.
Define the source-of-truth rule first. Can users still read the old system? Can inbound interfaces continue to create records? Can batch jobs update the source after the final extract? Each answer changes the delta method. A freeze that stops human edits but leaves automated writes running still needs a plan for those later changes.
Freeze metadata before the release artifact is finalized. Admins and developers should stop direct production changes to components in scope. If an emergency change is required, record it, decide whether it must enter the release branch, and revalidate affected dependencies.
The freeze also needs an exception path for urgent business work. Use one controlled exception log with timestamps and stable business keys so those transactions can be loaded and reconciled once. The notice should state the exact start time and time zone, systems affected, blocked actions, allowed actions, emergency route, and expected reopen time. The freeze ends only after the go/no-go decision confirms that the new state can own the work.
Run The Final Extract And Delta Strategy
The Salesforce data migration final extract should begin from a known source state. If the source can be fully frozen before extraction, take the extract after the freeze confirmation. If the business cannot stop all writes, use a controlled delta method based on a fixed timestamp or source key. The delta method must be rehearsed because a late change can break parent-child relationships or create duplicate records if the matching rule is weak.
Salesforce’s current data migration guidance recommends defining the objects in scope, loading in dependency order, preserving legacy IDs, and validating with reports, spot checks, and error review. Those practices should be built into the cutover runbook. Store the source key on the target where appropriate so records can be matched during delta loads and later reconciliation.
The final Salesforce data migration package should include more than CSV files. Preserve the extraction timestamp, row count by object, checksum or file control where available, mapping version, source query, filters, transformation version, and loader settings. That evidence lets the team distinguish a source-data issue from a transformation issue or target-load issue.
Salesforce data migration object order should reflect dependencies. Users and reference data may need to exist before business records. Parent objects should normally load before children. Junction objects should wait until both sides of the relationship exist. Files, activities, and history may have separate handling. The Salesforce data migration order depends on the data model, so write it from the mapping document rather than from a generic template.
If automation needs to be bypassed for the load, design the bypass so it affects only the migration user or migration process where possible. Disabling broad automation in production can create another problem if normal user traffic resumes before every control is turned back on. List every temporary bypass in the Salesforce cutover checklist with an owner and a re-enable step.
The last part of the delta strategy is a stop condition. If the source keeps receiving writes past the planned cutoff, decide whether the project will extend the freeze, run another delta, defer those transactions, or stop the cutover. Don’t make that decision from scratch during the window.
Sequence Deployment And Production Setup
The Salesforce cutover plan should use a fixed production order that separates what can be prepared early from what must happen inside the freeze. Some settings, users, permission sets, integration credentials, or reference data may be staged before cutover. Other changes can only be activated when the source is frozen or when the new data is present.
Salesforce supports validation-only deployments and Quick Deploy for eligible recent validations. The deployment monitoring guidance states that a successful qualifying validation can be used for Quick Deploy within the allowed window, provided the validation still qualifies. Use that capability where it fits the release method because it moves test discovery out of the cutover window and makes production timing easier to estimate.
The deployment order should account for metadata dependencies and data dependencies. For example, fields and record types must exist before records that use them can load. Permission changes should be timed so users don’t gain access before the system is ready. Flows and triggers that expect final migrated data may need a migration bypass or delayed activation. Integration endpoints should not switch until the target can process messages correctly.
The Salesforce go-live checklist can use this production sequence:
1. Confirm freeze and backup evidence.
2. Confirm the approved release artifact and production authorization.
3. Deploy metadata that must exist before data load.
4. Apply planned configuration changes that aren’t in the deployment artifact.
5. Load reference data and parent records in the rehearsed order.
6. Load dependent records and controlled deltas.
7. Restore or enable planned automation and integration behavior.
8. Run technical smoke tests before business validation begins.
9. Open the system only after go/no-go approval.
Salesforce recommends testing and validating changes before production release. Its org development deployment module describes validating a production deployment before the final release and using that evidence to reduce risk in the go-live window. Keep the actual production sequence aligned with the sequence tested in the rehearsal. If production requires a different order, that difference should be treated as a cutover risk and tested separately where possible.
Define The Salesforce Parallel Run
A parallel period keeps the new Salesforce process and the previous process available for comparison or continuity. It should answer a specific question. If both systems remain writable without clear ownership, teams can create duplicate or conflicting transactions.
The first decision is whether the old system stays read-only or writable. Read-only access is easier to control because Salesforce can become the system of record while the old system remains available for history checks. A writable Salesforce parallel run may be justified for a critical process that cannot switch at once, but every transaction type needs an owner and a repeatable reconciliation rule.
Salesforce’s data integration decision guide asks teams to define timing, direction, source of truth, target, user experience, and exception handling. Apply the same questions to a Salesforce parallel run. If 2 systems can change the same business object, state which system wins and how mismatches are resolved.
Keep the scope narrow. Pick the workflows whose failure would materially affect operations, define the records or time window to compare, then use stable business keys and agreed fields for reconciliation. Avoid asking users to duplicate every action in both systems unless the business has a specific reason.
Write the exit criteria before the parallel period starts. They may include a complete business cycle without unexplained mismatches, reconciled totals within the agreed tolerance, no unresolved critical integration errors, and business-owner sign-off. Once the criteria pass, close the old write path. Parallel operation is a residual-risk control, not a substitute for pre-production testing.
Validate Data And Business Processes During Cutover
The Salesforce go-live checklist should require proof that the new production state is trustworthy. Record counts are useful, but they are only the first layer. A complete cutover validation compares volume, relationships, field meaning, ownership, security, automation results, and downstream behavior for the parts of the business that are in scope.
Salesforce recommends validating migrated data with record-count checks, data-quality checks, and comparisons against the current system. Its migrated data validation guidance also calls for a test plan for each run. Build those checks before the cutover so results can be produced quickly after the final load instead of creating ad hoc queries while the clock is running.
Use a reconciliation pack that is repeatable across rehearsal and production. Include source and target counts by object, counts by status where status matters, sums for financially meaningful fields, duplicate checks on business keys, orphan checks for required relationships, ownership checks, and a sample of records chosen by business owners. If the system sends data downstream, include outbound message counts or receiving-system confirmation where that evidence is available.
Technical smoke tests should follow the same principle. Check login and access with representative users. Open records from core objects. Create or update a record if the go/no-go plan allows it. Run a critical Flow or approval. Test a representative integration transaction end to end. Confirm scheduled jobs are in the expected state. Check reports that depend on migrated data or new sharing rules.
The Salesforce cutover checklist should separate blocking failures from repairable failures. A small set of rejected records with a known cause may be safe to repair after go-live. A broken ownership model that exposes restricted records is different. The team needs written severity rules so the go/no-go call isn’t based on who argues most strongly at the end of a long night.
The Salesforce go-live checklist should keep an evidence log. For each validation item, record the query or test, expected result, actual result, timestamp, owner, and status. That log supports the go/no-go decision and helps the support team understand what was already checked if an issue appears after users return.
Set Go/No-Go Criteria Before The Window
Go/no-go criteria are the decision rules that convert validation results into an action. They should be approved before the cutover starts. The release authority should not invent thresholds while waiting for a load to finish or while business leaders are asking when users can return.
Salesforce’s Well-Architected guidance on application lifecycle management connects release management with controlled environments and signals that detect failure. Apply that idea directly to cutover. Every high-risk area should have a signal, an owner, and a threshold. If the signal crosses the threshold, the runbook should say whether to pause, repair forward, or start the Salesforce rollback plan.
Useful go/no-go criteria often cover these areas:
| Decision Area | Evidence To Review | Possible No-Go Condition |
| Deployment | Deployment status and required tests | Required component failed or critical test failed |
| Data | Counts, sums, duplicate and orphan checks | Core data can’t be reconciled within the approved tolerance |
| Security | Representative access tests | Users can see restricted records or can’t access required records |
| Integrations | End-to-end transactions and queues | A critical interface can’t process or recover messages |
| Business Process | Owner-led smoke tests | A critical workflow can’t complete |
| Time | Remaining cutover and rollback window | Safe rollback can no longer finish before required service time |
The exact tolerance depends on the process. A financial total may require exact agreement. A historical activity load may allow documented exceptions. Define the tolerance in the runbook and get the business owner to approve it before cutover. Avoid vague criteria such as “data looks good” or “most integrations are working.”
The Salesforce go-live checklist should also define decision order. If a data issue is found, who investigates first? How long is allowed for diagnosis? Who can approve a repair forward? At what point does the rollback decision become automatic? Those rules protect the remaining recovery time.
Write A Salesforce Rollback Plan That Can Be Executed
A rollback plan must restore a usable business state across metadata, data, integrations, and user access. Those areas may need different recovery methods, so the plan should separate them and name the owner for each step.
Salesforce recommends routine backups and a point-in-time backup before major data work. Its backup guidance distinguishes data from metadata and warns that mass updates or deletions can require restoration. Tie the pre-cutover backup to the runbook with proof of completion and a named restore owner.
For metadata, keep a known-good prior state and a tested deployment method. Source control makes the prior state easier to identify, but the recovery still has to be rehearsed. For data, decide how inserted records are removed or corrected and how updated or deleted records return to the prior state. Salesforce Backup can restore record versions, and the record restore documentation explains how prior versions and related records can be selected for restoration.
The Salesforce rollback plan must also cover integration traffic. State how outbound jobs pause, how inbound traffic is stopped or redirected, which endpoints return to the previous route, and how queued messages will be handled. If the old system is the fallback, confirm that it can accept writes again and that users still have access.
| Failure Type | First Response | Rollback Scope |
| Metadata deployment failure | Stop dependent steps | Redeploy prior known-good metadata |
| Data load corruption | Stop user access and further loads | Restore or reload affected data |
| Critical integration failure | Pause the interface | Reopen the prior route and reconcile queued traffic |
| Security or sharing failure | Restrict access | Restore the prior access state before reopening |
| Business process failure | Pause the affected process | Revert the affected release slice if repair will miss the window |
Preserve deployment logs, load files, error files, reconciliation results, and timestamps before reversal. Then rehearse rollback and time it. That measured recovery time should drive the latest safe rollback start in the Salesforce cutover plan.
Manage Post-Cutover Stabilization And Hypercare
The Salesforce go-live checklist is not finished when users can log in. The first operating period should confirm that the system remains stable under real work. The hypercare window needs named owners, a single intake route, severity rules, and a schedule for reviewing data and integration health.
Salesforce’s backup export guidance notes that backup data can support historical comparison and larger restoration work. That is useful during hypercare because fixes can change the production state further. Treat large corrections during the first days with the same discipline as cutover changes. Back up affected data, record the reason, test the correction method, and validate the result.
Monitor the areas that were risky during cutover. Watch failed integration messages, scheduled jobs, Flow and Apex errors, duplicate creation, sharing complaints, record ownership, and important business totals. Compare the first full business cycle against the baselines used during rehearsal where that comparison makes sense. If a Salesforce parallel run is still active, keep the comparison window short and review mismatches on a fixed schedule.
The support team should distinguish user questions from cutover defects. A training issue may need a quick answer and updated guidance. A data mapping issue may affect many records and require a controlled correction. A permission issue may be isolated to one group or may reveal a wider sharing problem. Classification helps the team avoid making broad production changes in response to a single report.
The Salesforce go-live checklist should close hypercare only after open high-severity issues are resolved or moved into normal support with an accepted plan. Confirm that temporary migration permissions are removed, bypasses are closed, old integrations are disabled where required, and exception logs have been processed. The final cutover record should capture what changed from the original runbook so the next release starts with better evidence.
Complete Salesforce Cutover Checklist
This Salesforce cutover checklist and Salesforce cutover plan can be copied into a runbook and expanded with owners, times, evidence links, and status fields. Keep each item tied to a real control. Remove items that do not apply rather than marking them complete without evidence.
Before The Freeze
· Freeze the release scope and identify the exact build, tag, package, or change set.
· Confirm all production dependencies and environment differences are documented.
· Complete UAT and obtain business-owner sign-off for critical workflows.
· Rehearse the final data load and reconciliation with production-like volumes.
· Confirm the Salesforce data migration mapping, legacy IDs, ownership rules, and load order.
· Validate the production deployment where the release method supports it.
· Confirm backup scope for both data and metadata.
· Test restore or recovery steps in a safe environment.
· Approve the Salesforce rollback plan and latest safe rollback start time.
· Publish the Salesforce data freeze notice with exact times and user instructions.
· Confirm integration owners and downstream system contacts are available during the window.
· Prepare technical smoke tests and business validation scripts.
During The Freeze And Cutover
· Confirm source-system write restrictions are active.
· Confirm metadata changes are frozen.
· Confirm emergency transaction handling is active and logged.
· Take and verify the pre-cutover backup.
· Run the final extract and record control totals.
· Deploy metadata in the rehearsed order.
· Apply required production-only configuration.
· Load data by dependency and capture success and error files.
· Run the planned delta load if writes were allowed after the main extract cutoff.
· Re-enable temporary automation or integration controls in the defined order.
· Run data reconciliation and technical smoke tests.
· Execute the Salesforce parallel run checks if that control is in scope.
· Review go/no-go evidence with named business and technical owners.
· Start the Salesforce rollback plan immediately if the approved trigger is met.
After Go-Live
· Open access according to the release plan.
· Confirm critical integrations are processing live traffic.
· Monitor errors, queues, scheduled jobs, and record creation patterns.
· Reconcile the first business cycle against agreed control totals where relevant.
· Process freeze-window exceptions and verify they landed once.
· Close old write paths after the Salesforce parallel run exit criteria pass.
· Remove temporary migration permissions and bypass controls.
· Record defects and corrections made during hypercare.
· Hold a cutover review and update the runbook with evidence from the actual event.
The Salesforce cutover checklist should stay specific to the release. A CRM replacement, an org consolidation, a major Sales Cloud redesign, and a data-only move will share controls, but the ownership and recovery steps will differ. The best runbook is the one the team has already rehearsed against the same sequence it intends to execute.
Closing The Cutover Window With Evidence
A safe Salesforce cutover plan depends on controlling when the old state stops changing. The Salesforce cutover checklist then proves whether the new state is ready to take over. The Salesforce cutover checklist gives that work an order. The Salesforce data freeze fixes the source state. The final extraction and deployment sequence move the approved change. Validation shows whether the target state is trustworthy. The Salesforce parallel run can provide a short comparison period for selected risks. The Salesforce rollback plan protects the remaining recovery path if a blocking condition appears.
The Salesforce go-live checklist should settle the most important decisions before cutover day. Define ownership, thresholds, evidence, and time limits while the team is calm. Rehearse the sequence with production-like data and include rollback in that rehearsal. During the production window, follow the runbook, record evidence, and use the agreed go/no-go rules. That approach keeps the cutover focused on execution instead of improvisation.
FAQs
What Is A Salesforce Cutover Checklist?
A Salesforce cutover checklist is an ordered production runbook for moving from the current state to the approved Salesforce state. It covers freeze timing, backup, deployment, data movement, validation, rollback, access, integrations, and post-cutover checks.
When Should The Salesforce Data Freeze Start?
The Salesforce data freeze should start early enough to create a stable source state for the final extract and validation. Set the time from rehearsal results, data volume, delta handling, business hours, and the available cutover window.
Does A Data Freeze Mean Users Cannot Read The Old System?
No. A write freeze can still allow read-only access if that supports continuity and does not affect the migration. The runbook should state which actions are blocked and which automated writes remain possible.
What Is A Salesforce Parallel Run?
A Salesforce parallel run is a limited period when the new Salesforce process and the previous process remain available for comparison or continuity. It needs a clear source-of-truth rule, reconciliation method, scope, and exit criteria.
How Long Should A Salesforce Parallel Run Last?
Keep it only as long as needed to complete the checks it was designed to support. Set the end condition before go-live so the old process does not remain active by default.
What Should A Salesforce Rollback Plan Include?
A Salesforce rollback plan should name the triggers, decision owner, latest safe start time, recovery methods, integration reversal steps, access changes, user communication, and validation needed before service resumes.
Can Salesforce Metadata Be Rolled Back With One Click?
There is no universal one-click rollback for every Salesforce metadata change. Teams need a known-good prior state and a tested deployment or restore method that fits the release approach in use.
How Should Data Be Validated After The Final Load?
Check record counts and also test relationships, ownership, duplicate rules, key business values, sampled records, integration results, and error files. Prepare the validation set during rehearsal so production checks are repeatable.
What Is The Difference Between Repair Forward And Rollback?
Repair forward corrects the production state while keeping the new release in place. Rollback returns the affected state to the prior known-good condition. The runbook should define when each path is allowed.
Who Should Make The Go/No-Go Decision?
A named release authority should decide using evidence from technical and business owners. Choose that authority before cutover and approve the decision thresholds and rollback triggers before the production window.
Should Integrations Be Turned Off During Cutover?
Some interfaces may need to pause or redirect while the target is incomplete. Others may stay active for continuity. Decide behavior per interface and document message handling, retries, queues, and endpoint changes.
Why Are Legacy IDs Useful In Salesforce Data Migration?
Legacy IDs provide a stable way to match source records to Salesforce records. They help rebuild relationships, support upserts, investigate rejects, and reconcile later delta loads.
What Should Be Backed Up Before A Salesforce Cutover?
Back up the production data and metadata that could be affected by the release or migration. Match the backup scope to the rollback method and verify that the team can use the selected recovery process.
What Should Happen If The Cutover Window Is Running Late?
Use the latest safe rollback start time in the runbook. Do not consume the recovery window without an explicit decision. The release authority should follow the approved no-go rule when safe completion no longer fits.
What Should Be Reviewed After The Cutover Is Complete?
Review timing, failures, exceptions, reconciliation results, user issues, integration behavior, hypercare corrections, and any step that differed from rehearsal. Update the runbook with evidence from the actual event.