You’ve spent weeks getting the data right. The Bulk API jobs ran clean, the auth layer is locked down, and the retry logic held up under load testing. Now you’re looking at the date you set to ‘go live,’ feeling that familiar mix of confidence and fear.
That feeling is normal. Cutover is where all your planning gets tested in real time, usually over a weekend, usually with half the team running on coffee. The difference between a calm go-live and a 2 a.m. scramble rarely comes down to luck. It comes down to whether the team had an actual plan, written down, with names attached to decisions.
This is the final piece of our Salesforce data migration series. We’ll cover the architecture that needs to hold up under pressure, a validation checklist you can use as a real sign-off sheet, a cutover timeline you can copy into your project plan, and the practices that separate teams who sleep during go-live from teams who don’t.
Why Cutover Is Where Migrations Actually Win or Lose
Most teams pour their energy into the build phase and treat cutover as an afterthought. The data model gets reviewed twenty times. The cutover plan gets a single bullet point in a status deck that says “go-live weekend.”
It is the other way around. There is room for error during the build phase; you can re-run test loads, fix mappings, or modify triggers. There is no such margin for error during cutover, because you are effectively working for a live business that requires accurate data by Monday morning.
The failure patterns are consistent across projects. No rollback plan, so when something breaks, nobody knows whether to fix forward or pull back. A delta load that gets rushed or skipped, leaving a gap between the last extract and go-live. Integrations flipped on without a smoke test. And maybe the most common one: no communication plan, so executives ping the project lead every twenty minutes instead of getting scheduled updates.
A structured cutover plan fixes this, not through magic, but by forcing decisions to be made in advance, when people are calm, rather than in the moment, when they’re not.
Understanding Your Migration Architecture Before Go-Live
You don’t need to be an architect to understand this, but when you flip the switch, it helps to know what is going on behind the scenes during the migration.
The Layers, Explained Without the Jargon
A typical migration architecture has five moving pieces. The source data extractor pulls records from the legacy system. A migration orchestrator sequences the load through scripts or middleware. The authentication layer handles OAuth 2.0 and Named Credentials, allowing scripts to communicate with Salesforce without storing secrets in a config file. The API layer does the actual work: Bulk API 2.0 for high-volume loads, Composite REST API for records that need parent-child relationships to land together. And the target org sits behind a validation framework checking what landed against what should have landed.
If you want the deeper mechanics of authentication, we covered Connected Apps, the Client Credentials flow, and Named Credentials in our piece on OAuth 2.0 for Salesforce migrations. Worth a read before cutover weekend, not during it.
How Early Decisions Come Back to Bite You
Decisions made in week one show up again in week twelve, right when you can least afford to fix them. If you do not use external IDs from the start, idempotency breaks as soon as a delta load is executed, because the system lacks a reliable way to determine which records already exist. We covered this in our retry logic and idempotency article, and it is fair to say that the ‘External ID’ strategy is one of the three most critical factors determining whether the ‘cutover weekend’ proceeds smoothly or becomes fraught with difficulty.
Same goes for parallelisation. If nobody mapped out which objects can load simultaneously and which ones depend on each other, your six-hour window quietly turns into eleven.
The Data Integrity Validation Checklist
Treat this as a gate, not a nice-to-have. Nobody flips the switch to production until every item has a sign-off next to it. You can’t validate every field on every record. That’s not realistic, so here’s what actually matters.
- Record Count Reconciliation: Total record counts per object in Salesforce must equal source system counts, plus or minus expected exclusions (soft-deletes, duplicates intentionally merged, out-of-scope date ranges).
- External ID Coverage: 100% of migrated records must have a populated External_ID__c value. Any null External IDs indicate a mapping failure that results in orphaned, untraceable records.
- Relationship Integrity: All Lookup and Master-Detail relationships must be valid. Run SOQL queries to identify orphaned child records where ParentId is null, but the record should have a parent.
- Picklist Compliance: No record should carry a picklist value not in the current valid picklist definition. Invalid picklist values cause formula field errors and reporting inconsistencies.
- Owner Assignment Coverage: No migrated record should be owned by the migration integration user unless that was the intended assignment. Run the user mapping validation query.
- Automation Resumption: Re-enable all bypassed triggers, validation rules, and Flows. Perform a test DML operation on a non-migrated record to verify automation chains execute correctly.
Cutover Window Planning
| Phase | Activity | Owner | Duration | Go/No-Go Gate |
|---|---|---|---|---|
| T-72 hours | Final schema sync from production to UAT sandbox | Architect | 4 hours | Schema parity confirmed |
| T-48 hours | Migration dry-run in UAT; document timings and failure rates | Migration Team | 8 hours | < 5% failure rate |
| T-24 hours | Freeze source system for new record creation | Business Owner | Ongoing | Freeze notice acknowledged |
| T-8 hours | Execute delta extraction (records changed since dry-run) | Migration Team | 2 hours | Delta count documented |
| T-0 (Cutover) | Disable Salesforce login for non-migration users | Salesforce Admin | 30 mins | User lockout confirmed |
| T+0 to T+6 h | Execute migration waves 1-4 with real-time monitoring | Migration Team | Up to 8 hours | < 0.1% failure rate |
| T+6 hours | Full post-migration validation suite execution | QA Team | 2 hours | All validation checks pass |
| T+8 hours | Re-enable user logins; announce go-live | Business Owner | 30 mins | Stakeholder sign-off |
Best Practices Summary
Pre-Migration Best Practices
- Conduct a formal Org Readiness Assessment at least six weeks before the migration window.
- Assign a dedicated, purpose-built Salesforce integration user with minimum required permissions.
- Implement Custom Metadata-based automation bypass flags on all triggers, Flows, and validation rules.
- Create External ID fields on every object before migration and enforce uniqueness at the schema level.
- Establish a user mapping table resolving all source-system user identifiers to Salesforce User IDs.
- Activate Salesforce Shield Event Monitoring to capture the complete API audit trail before migration starts.
- Complete Salesforce Platform Encryption configuration before loading any sensitive PII or PHI data.
During-Migration Best Practices
- Use Bulk API 2.0 for all loads exceeding 200 records; use REST Composite for small, relationship-critical inserts.
- Prefer Upsert over Insert wherever an External ID field exists, to guarantee idempotency across retry cycles.
- Implement exponential back-off with jitter on all API calls; never use fixed-interval polling or retry logic.
- Chunk CSV files at no more than 150,000 records per Bulk API 2.0 job for optimal processing time.
- Enqueue all failed records into a Dead-Letter Queue immediately; never discard failure data.
- Persist migration checkpoints after each successful wave to enable resuming without restarting after any disruption.
- Monitor the org’s API limit consumption in real time via the /limits REST endpoint throughout the window.
Post-Migration Best Practices
- Execute the full validation suite before enabling end-user access; treat validation as a binary go/no-go gate.
- Preserve all migration artefacts, including job result CSVs, audit logs, and checkpoint files for a minimum of 90 days.
- Revoke or deactivate the Connected App and integration user credentials immediately after cutover sign-off.
- Document all deviations from the migration plan, including records that landed in the DLQ and their final resolution.
- Conduct a post-migration retrospective within five business days to capture lessons learned for future engagements.
Wrapping Up the Series
If you’ve followed this whole series, you’ve built something more useful than seven blog posts: a working playbook covering org readiness, authentication, Bulk API and REST API patterns, resilience and idempotency, compliance and governance, and now cutover.
That’s a complete capability, not a checklist you use once and forget. Bookmark this series. The next time your org takes on a migration, whether it’s a merger, a CRM consolidation, or a platform move, you’ll have a reference already thought through, instead of starting from a blank page under deadline pressure.
Your Cutover Plan Is Only as Good as Your Preparation
Cutover weekend is stressful. That’s not going to change, and I wouldn’t trust anyone who tells you otherwise. What changes is how stressful it feels when your team walks in with a documented plan instead of good intentions. Treat the checklist, timeline, and architecture in this article as reusable tools, and your next go-live will be calmer than your last.
Kiran Sreeram Prathi
I’m Kiran Sreeram Prathi, a Salesforce Developer dedicated to building scalable, intelligent, and user-focused CRM solutions. Over the past five years, I’ve delivered Salesforce implementations across healthcare, finance, and service industries—focusing on both technical precision and user experience. My expertise spans Lightning Web Components (LWC), Apex, OmniStudio, and Experience Cloud, along with CI/CD automation using GitHub Actions and integrations with platforms such as DocuSign, Conga, and Zpaper. I take pride in transforming complex workflows into seamless digital journeys and implementing clean DevOps strategies that reduce downtime and accelerate delivery. Recognized by organizations like Novartis, WILCO, and Deloitte, I enjoy solving problems that make Salesforce work smarter and scale better. I’m always open to connecting with professionals who are passionate about process transformation, architecture design, and continuous innovation in the Salesforce ecosystem.