Cutover Planning: The 30-60-90 Day Plan Before Go-Live

The Cutover Paradigm: Why Salesforce Deployments are Non-Linear

In traditional custom software engineering—such as custom Java, .NET, or React web applications—the cutover process is relatively linear. A compiled binary is pushed to an application server, database migration scripts are executed sequentially, and integration pathways are redirected. However, Salesforce operates on a highly complex, multi-tenant cloud architecture that introduces a fundamentally non-linear cutover paradigm. On a modern enterprise Salesforce programme, a release is never a simple binary swap. Instead, it is an intricate orchestration where platform-native metadata (Apex classes, Lightning Web Components, Flow orchestrations, Permission Sets) must be synchronised with active database transactional records, environment-specific integration configurations, and configuration-as-data (such as Salesforce CPQ pricing tables, Field Service templates, OmniStudio structures, or Advanced Promotions).

This coupling of transactional data and application architecture is the core challenge. Unlike a standard relational database where schemas change slowly, a Salesforce system update often modifies active object structures while high-volume transactional pipelines are running. This means that a standard cutover plan cannot treat data migration and metadata deployment as isolated phases. They are structurally interdependent. For instance, you cannot import new child transactional records (like Order Items or Assets) until the parent lookup relationships and validation rules are deployed; yet, you cannot deploy the metadata validations without temporarily disabling them to allow legacy data that does not conform to the new rules to be loaded. This chicken-and-egg dilemma requires a non-linear, multi-pass deployment strategy where validation rules, triggers, and automated flows are deployed, partially disabled, executed upon, and then systematically re-enabled.

Furthermore, Salesforce's multi-tenant architecture imposes strict governor limits that do not exist on self-hosted infrastructure. During high-volume data migrations, a cutover team must navigate concurrent request limits, Bulk API batch allocations, and apex CPU timeout constraints. If a data migration script attempts to insert 5 million records while complex, active apex triggers are enabled, the transaction will hit Apex CPU limit violations and roll back completely, ruining the cutover timeline. Delivery leaders must design cutover runbooks that categorise every deployment step not just by technical layer, but by platform limit consumption, planning freeze periods and system bypasses to navigate these multi-tenant guardrails safely.

The 90-Day Horizon: Establishing the Readiness Baseline

The success of an enterprise Salesforce cutover is decided three months before the actual go-live weekend. At the 90-day mark (T-minus 90 days), the programme must transition from a pure development mindset to a rigorous operational readiness framework. The first step in this transition is establishing the Cutover Governance Board, led by a dedicated Cutover Manager. This role must be distinct from the day-to-day Project Manager or Release Engineer; the Cutover Manager is the ultimate orchestrator, responsible for driving the cutover runbook compilation, coordinating across third-party vendor teams, and managing the live communication bridges during execution. Supporting the Cutover Manager are key stakeholders representing Salesforce Platform Architecture, Core Integrations, Business Readiness, and external business-critical systems (like SAP ERP, MuleSoft Middleware, or corporate data warehouses).

During this initial phase, the team must identify the optimal cutover window by analysing historical transactional volume. The target is a period of minimum business activity—typically a weekend or a holiday window—where system downtime will not cause significant revenue disruption or customer-facing failures. Once this window is agreed upon, the Cutover Manager begins drafting the Master Cutover Runbook. This document acts as the single source of truth for the entire cutover team. It is a highly granular, chronological schedule detailing every task, its duration, its specific owner, its immediate pre-requisites, its target environment state, and its validation criteria. Crucially, every task must be assigned to a real person, not an abstract team name, ensuring absolute accountability when executing under pressure.

Simultaneously, the Lead Platform Architect must map all external integration dependencies. Salesforce is rarely a standalone silo; it is the hub of the corporate customer ecosystem. The team must document the state of every integration during the cutover: which APIs must be silenced, which endpoints must point to maintenance holding pages, and how delta transactions will be queued in the middleware (e.g., MuleSoft or Kafka) during the transition. A detailed data-mapping document must also be drafted, establishing how legacy record IDs will be stored in the new Salesforce org to maintain parent-child integrity across asynchronous data migration batches.

The 60-Day Horizon: Environment Hardening and Dry Run Execution

At the 60-day mark, the focus shifts to environment hardening and testing the actual execution runbook. The first priority is to freeze developer sandbox creations and ensure that the Staging/Full-copy sandbox is refreshed to mimic the exact state of the production environment, including its metadata volume, active sharing rules, and configuration records. Once this Staging environment is locked down, the team initiates Dry Run 1 (Rehearsal 1). This is not a theoretical review; it is a full, timed simulation of the cutover runbook executed in the Staging sandbox by the actual individuals assigned to the live cutover tasks. The primary goal of Dry Run 1 is to capture the baseline duration of every single deployment step, from metadata migration to data loads, and to discover undocumented dependencies.

Timing the execution to the minute is critical because it replaces estimation guesswork with solid telemetry. A script that a developer estimated would take "about 20 minutes" may actually run for 4 hours when subjected to standard sandbox data volume and API limits. When Dry Run 1 is executed, the Cutover Manager logs the start and end times of every step, capturing the variance between planned and actual durations. This log immediately highlights bottlenecks and critical-path dependencies, allowing the team to optimise the master schedule. If a specific data load task is identified as a bottleneck, the team can focus on optimising the ETL queries, tuning bulk batch sizes, or restructuring the sequencing to run parallel loads where no dependencies exist.

Dry Run 1 also acts as a stress test for the deployment architecture. The team will inevitably encounter failures: Salesforce custom validations rejecting legacy records, record-locking conflicts during concurrent API loads, or Apex trigger limits being exceeded due to complex processing loops. Rather than viewing these as setbacks, delivery leaders should celebrate these discoveries. Finding a validation error 60 days before go-live allows the team to modify the migration mapping or write a custom bypass logic script; finding it during cutover weekend is a catastrophic delay that can derail the entire launch.

The 30-Day Horizon: Freeze Protocols and Final Data Preparation

As the programme crosses into the final 30 days, the governance must become extremely strict. The first operational mandate is enforcing the Code and Metadata Freeze. From this point forward, no new features, enhancements, or non-critical refactoring are permitted into the release branch. The git repository is locked, and only critical bug fixes or emergency hotfixes—explicitly approved by both the Lead Architect and the Cutover Board—are allowed to be merged. This freeze is crucial to eliminate the risk of environment drift, where Staging sandboxes undergo rapid changes that diverge from the validated target state of Production, making the results of previous dry runs obsolete.

To support this freeze while maintaining release integrity, the team must establish a formal Emergency Hotfix Process. A dedicated hotfix sandbox is configured, and any approved change must be developed, unit tested, and immediately back-ported to both the release branch and the Staging/Full-copy sandbox. This rigorous governance ensures that the environment utilized for the final rehearsal remains a true mirror of what will be deployed on cutover weekend. Simultaneously, the Data Migration team begins pre-staging historical data. Moving massive data volumes—such as ten years of historical transactional logs or closed opportunities—during the cutover weekend is highly risky and mathematically unnecessary. By migrating these static, read-only historical records to the Production org 30 days early, you dramatically reduce the volume of data that must be loaded during the critical downtime window, leaving only the "delta" changes (records created or updated during the freeze) to be migrated on cutover weekend.

Finally, at T-minus 15 days, the team executes Dry Run 2 (The Final Rehearsal). This run is an exact mirror of the actual cutover weekend, using the final version of the code and the pre-staged data set. The goal of Dry Run 2 is to achieve a flawless run with zero manual interventions, validating that all bulk delta scripts operate within the expected time window and that the post-load integration reconciliation scripts execute successfully. The successful completion of Dry Run 2 provides the steering committee with the statistical confidence required to authorize the final go-live decision.

Execution Weekend: The T-Minus Command Center and Hypercare Handover

When cutover weekend arrives, the execution must run like a highly choreographed military operation. The Cutover Manager establishes the T-Minus Command Center, keeping a live virtual bridge line open 24 hours a day with representatives from all technical and business teams. Every task in the runbook is tracked in real-time, and shift rotations are strictly enforced to prevent fatigue-induced errors among the engineering teams. The cutover execution proceeds through eight discrete, highly structured stages, each requiring explicit approval before passing the next gate:

Stage 1: System Lockout and User Freezing. The very first action of the cutover is preventing business transactions from occurring in the legacy system. In Salesforce, this is achieved by executing an automated script (typically using the Salesforce CLI or Apex anonymous code) that freezes all active user accounts, preventing them from logging in or making changes. Only integration users and the deployment team's administrative accounts remain unfrozen. System administrators also update the login policies, activate custom maintenance pages, and terminate any active OAuth user sessions.

// Apex Anonymous Script to freeze all non-deployment users during the cutover window
List<UserLogin> loginsToFreeze = new List<UserLogin>();
Set<String> exemptUsernames = new Set<String>{
    'deployment.admin@sfvedas.com',
    'integration.user@sfvedas.com'
};

for (UserLogin ul : [SELECT Id, UserId, IsFrozen FROM UserLogin WHERE IsFrozen = false]) {
    User u = [SELECT Username FROM User WHERE Id = :ul.UserId LIMIT 1];
    if (!exemptUsernames.contains(u.Username)) {
        ul.IsFrozen = true;
        loginsToFreeze.add(ul);
    }
}

if (!loginsToFreeze.isEmpty()) {
    update loginsToFreeze;
    System.debug(loginsToFreeze.size() + ' users successfully frozen for cutover.');
}

Stage 2: Integration Silencing and Middleware Queuing. With the system locked, the Middleware Lead silences all inbound and outbound integration pipelines. Downstream systems are placed into read-only mode, and upstream message queues (such as MuleSoft or RabbitMQ) are configured to hold transactions rather than attempting to deliver them to Salesforce. This ensures that no data drift occurs while metadata is being replaced and database tables are restructured.

Stage 3: Metadata Release. The Release Engineer executes the final deployment of the metadata branch from the CI/CD pipeline. This includes custom objects, Apex code, Aura/LWC packages, flow orchestrations, and permission sets. Manual pre-deployment and post-deployment configurations—such as custom settings activation or third-party package licence assignments—are performed by designated engineers and validated against the runbook checklist.

Stage 4: Delta Data Load and Reconciliation. The Data Migration team initiates the final data import. Using optimized Bulk API 2.0 loads, they migrate all transactional records created or updated since the pre-staging freeze. Once the load completes, they run automated data reconciliation queries (comparing source and target database checksums and record counts) to verify that no record loss occurred during the migration. Validation rules and apex triggers are systematically re-enabled, and any transient integration errors are resolved.

Stage 5: Integration Re-activation and Sync. The Middleware Lead switches integration API endpoints to point to the live Production environment, restores secure credentials, and starts the processing queues. The system begins processing the backlog of queued messages, and integration synchronisation is verified by monitoring the API request logs for any persistent errors.

Stage 6: Multi-tiered Smoke Testing. Designated Business Leads and technical experts conduct extensive smoke testing. This testing follows a strict script designed to validate core system behaviours: creating an account, generating an opportunity, executing a CPQ quote, and verifying integration calls. This testing must be conducted using specific test profiles to ensure security structures and sharing rules are fully functional.

Stage 7: The Go/No-Go steering committee meeting. The steering committee convenes to review the results of the data reconciliation and smoke testing. If all validation criteria are met, the official "Go" decision is declared. In the rare event of an unresolvable, business-critical failure, the Cutover Manager invokes the pre-defined Roll-back Plan, reverting metadata and database states back to the pre-cutover baseline using pre-compiled backup files.

Stage 8: System Unlock and Hypercare Commencement. Upon receiving the "Go" decision, administrators execute a script to unfreeze all active user accounts, distribute credentials, and announce that the platform is live. The T-Minus Command Center is officially dissolved, and the project transitions into the Hypercare Support phase. This phase—staffed by dedicated, highly responsive helpdesk and engineering teams—ensures that any post-launch user adoption friction or minor system anomalies are addressed immediately, protecting the business from operational disruption and securing a highly successful go-live.