For teams migrating to Salesforce, moving customer data can look straightforward. The source CRM may use familiar objects such as contacts, companies, deals, accounts, leads, and opportunities. The risk appears when those familiar labels hide different rules. A Salesforce migration succeeds when the new org preserves the old system’s business meaning as well as its data.
That distinction matters because every CRM has its own data model, automation engine, ownership rules, activity structure, and reporting logic. A field can arrive with the right value while the process around it is wrong. A deal can become an Opportunity but land in the wrong stage. A contact can arrive without the account relationship that made the record useful. Historical activity can be present but attached to the wrong parent. Reports can run while answering a different business question.
When migrating to Salesforce, the project therefore needs 2 workstreams. One moves records and files. The other rebuilds meaning: relationships, lifecycle logic, security, automation, integrations, and reports. The second workstream is where most breakage starts.
TL;DR
- Treat a Salesforce migration as a data-model translation project. CSV files alone don’t preserve CRM behavior.
- A HubSpot to Salesforce migration is most exposed around Contacts versus Leads and Contacts, lifecycle stages, associations, deal pipelines, workflows, and engagement history.
- A Zoho to Salesforce migration needs extra care around custom modules, Blueprints, Deluge functions, picklists, files, and related records.
- A Dynamics 365 to Salesforce migration can fail around Dataverse relationships, activities, owner or team security, business units, choice fields, and system fields.
- Preserve source IDs before loading anything. They give the migration team a stable key for matching records and rebuilding parent-child links.
- Build the Salesforce target model before the main data load. Relationships and required fields should already exist.
- Rebuild automation and reports from business rules, not screenshots of the old CRM.
- Test with a representative data set, reconcile results, rehearse cutover, then run a controlled final delta.
Why CRM Migrations Break After the Data Lands
Teams migrating to Salesforce can pass a basic record-count check and still fail users. The reason is simple: record quantity doesn’t prove that business meaning survived. Salesforce uses its own object relationships, lead conversion behavior, ownership rules, duplicate controls, required fields, and automation. Those rules can reject data or alter how users see it after import.
Salesforce tells migration teams to identify the objects in scope and create import templates. It also calls for relationship planning, pre-production testing, and post-load validation. The current Salesforce data migration guidance supports that sequence. This matters even more when the source isn’t Salesforce. Source IDs and relationships then have to be translated into a different model. A CRM migration to Salesforce should therefore be judged by relationship accuracy and process behavior as well as record counts.
| What can look correct | What may still be broken |
| Contact count matches | Contacts are tied to the wrong Accounts or should have been Leads |
| Opportunity count matches | Stages, owners, close dates, or pipeline meaning changed |
| Activities imported | Calls, emails, notes, or meetings are attached to the wrong record |
| Custom fields exist | Field types, picklist values, defaults, or validation behavior changed |
| Users can log in | Role hierarchy, sharing, queues, or team access doesn’t match the old model |
| Dashboards open | Filters or source fields no longer mean what they meant before |
| Integrations connect | Sync direction, matching keys, or error handling changed |
The first planning task is therefore a source-to-target model, not an export. Teams that need help defining that target state can use Salesforce consulting services before field mapping begins. The Salesforce org should reflect the future process instead of becoming a copy of old CRM clutter. The migration file is only one input into that design.
What Must Be Mapped Before Any Record Moves
Before migrating to Salesforce, build the migration map above the field level. Begin with source modules or entities, decide which Salesforce objects will own the information, then define relationships and only then map fields. If the object decision is wrong, clean field mapping won’t save the result.
Salesforce stores relationships through record IDs. Its current migration guidance says related records should load in a logical sequence so child records can reference parents. It also describes external IDs as one way to keep source identifiers available during the move. The Salesforce guidance on preserving record relationships also explains why load order and stable IDs matter. This is why source record IDs should be exported early and kept unchanged in the staging files.
For each object in scope, document these items before the Salesforce migration starts:
- Source object or module and target Salesforce object.
- Source primary key and the Salesforce external ID field that will hold it.
- Parent-child and many-to-many relationships.
- Required fields, default values, field types, and allowed values.
- Ownership rules, queues, sharing behavior, and inactive users.
- Historical fields such as created date, modified date, status history, and original owner when they are required.
- Automation that reads or writes the field.
- Reports, integrations, or downstream systems that depend on the field.
This is also the right point to remove fields that have no owner or current business use. During a CRM migration to Salesforce, keeping an old field “just in case” creates noise. Users may no longer know which fields matter in the new org. A clear target dictionary makes UAT and later support much easier.
The target org should also be built before the main load. That means objects, fields, record types, picklists, relationships, validation rules, ownership structures, and permissions need to be ready. Salesforce implementation services is relevant here because migration work sits inside implementation work. Data can’t be validated correctly when the target schema is still changing under the import team.
What Breaks in a HubSpot to Salesforce Migration
Teams migrating to Salesforce from HubSpot may expect an easy move. Contacts, Companies, Deals, and Tickets have familiar Salesforce destinations. The trouble is that similar labels don’t guarantee the same lifecycle or relationship rules.
HubSpot can export record properties and associations, while activities have separate export paths. Its current export documentation also notes that associated records can be included in record exports, subject to the export options used. The current HubSpot record export documentation separates record properties, associations, and activity-related export needs. That means a single flat contact export shouldn’t be treated as the full migration source.
The largest design issue is usually the person model. Many HubSpot setups center revenue work on Contact records. Salesforce separates unqualified Leads from Contacts that belong in the account model. Salesforce lead conversion can create or connect Accounts and Contacts and can also create an Opportunity. That difference means every HubSpot contact needs a rule for where it belongs in Salesforce. If all contacts become Contacts, early-stage prospects may bypass the intended lead process. If all become Leads, existing customers and active buying relationships can be misclassified.
That split should be defined with business rules before import. Possible inputs include current lifecycle stage, whether an associated company exists, open or closed deals, customer status, sales ownership, and recent activity. Those inputs should be tested against edge cases instead of converted into a single rough rule.
Lifecycle stages and lead status
HubSpot lifecycle stages and Salesforce Lead Status aren’t direct equals. A lifecycle stage can describe a broader relationship with a person or company, while Salesforce lead status usually supports the lead process before conversion. If the old stage values are copied into a Salesforce picklist without redesign, the new pipeline can mix marketing qualification with sales execution.
The migration therefore needs a stage dictionary. Each source value should have a target meaning, entry rule, exit rule, and reporting effect. Historical values can be archived if they matter, but the live Salesforce stage model should follow the new process.
Associations and multiple relationships
HubSpot associations can connect contacts, companies, deals, tickets, and custom objects in ways that don’t always fit a single lookup. The export needs to preserve the source record IDs for both sides of each relationship. Otherwise, a contact can arrive while losing the company, deal, or ticket context that made it useful.
A strong HubSpot to Salesforce migration treats associations as their own migration asset. Parent records are loaded first, new Salesforce IDs are captured, and child or junction records are then loaded against those IDs. That sequence matters even when the visible values appear correct.
Deal pipelines and automation
HubSpot accounts may use multiple deal pipelines with different stages. Salesforce can represent different sales motions through record types, stage values, custom fields, and automation, but the target design has to be decided first. Copying stage labels alone can break forecast categories, probability assumptions, approvals, and reports.
Workflows also need to be rebuilt. HubSpot’s account export guidance shows that workflows can be exported as a view or image for reference. That helps with documentation, but it doesn’t create Salesforce automation. The old workflow should be converted into a written rule: trigger, conditions, actions, exceptions, owner, and expected result. Then it can be implemented in the Salesforce tool that fits the requirement.
Marketing teams also need to decide whether HubSpot remains in the stack. If it stays, the move becomes a CRM migration plus an integration project. Salesforce integration services is useful in that case because sync ownership and matching keys must be clear. Error handling and direction also need to be set before both systems write to the same records. The move is safer when one system is clearly assigned as the source for each shared field.
What Breaks in a Zoho to Salesforce Migration
Teams migrating to Salesforce from Zoho see more obvious object matches. Leads, Accounts, Contacts, and Deals can usually map to Salesforce Leads, Accounts, Contacts, and Opportunities. The hard parts appear around custom modules, relationships, automation, file history, and data types.
Zoho offers module exports and full backups for different needs. Its current export documentation says module data can be exported in CSV or XLSX. A full backup is the route when the requirement includes all module data plus items such as attachments and configuration details. The Zoho CRM export documentation makes that module-export versus backup distinction clear. That distinction matters because the wrong extraction method can leave the migration team with clean rows but missing context.
A Zoho to Salesforce migration should start with an inventory of every module in use. Standard modules can map to standard Salesforce objects when the business meaning fits. Custom modules need a decision: custom object, standard object, related record, or archive. Recreating every custom module without review can carry years of old design choices into the new org.
| Zoho area | Likely Salesforce treatment | Main risk |
| Leads | Lead | Status and assignment logic |
| Accounts | Account | Parent hierarchy and duplicate rules |
| Contacts | Contact | Account links and ownership |
| Deals | Opportunity | Stage, probability, close date, forecast meaning |
| Custom modules | Custom object or redesigned standard object | Wrong relationship model |
| Activities | Task, Event, or related history | Parent links and owner mapping |
| Attachments | Salesforce Files or another approved store | Missing binary files or broken links |
| Blueprints and functions | Rebuilt business logic | State rules and exceptions change |
Zoho picklists and Salesforce picklists also need value mapping. Labels that look similar can still mean different things. Empty values, deprecated options, multi-select fields, dates, currencies, and checkboxes need explicit conversion rules. The import tool should never be allowed to guess when a field affects routing, reporting, or automation.
Blueprints, workflows, and Deluge logic
Zoho Blueprints can enforce state transitions and required actions. Workflow rules and Deluge functions can also change records or trigger work outside the CRM. Those mechanisms don’t transfer as executable logic into Salesforce. Recent Zoho migration guidance from specialist firms reaches the same conclusion and treats the work as a rebuild of business logic in Salesforce.
The safe approach is to document the business rule first. Record what starts the rule, which conditions matter, what changes, which exceptions exist, and how failures are handled. Then rebuild it with Salesforce Flow, approvals, Apex, or an integration where appropriate. Custom API work may also sit here when external systems are part of the rule, because the behavior often crosses the CRM boundary.
The migration also needs a record of hidden dependencies. A field may look unused on a page layout but still drive a workflow, report, formula, API call, or territory rule. Deleting it during cleanup can break a process that no user sees directly.
Files, notes, and original timestamps
Attachments need their own count and validation plan. The migration team should reconcile file totals after loading and open a sample of migrated files. File names alone don’t prove that the content survived. Notes should keep the correct parent link and author context where the target model supports it.
Original created and modified dates also need an explicit decision. Some platform export and import methods treat system fields differently. If audit or operational reporting depends on those dates, test how the chosen Salesforce load method handles them before the main migration.
What Breaks in a Dynamics 365 to Salesforce Migration
Teams migrating to Salesforce from Dynamics 365 usually face the deepest architecture work of the 3 source paths. Dynamics 365 customer apps sit on Microsoft Dataverse. Dataverse has tables, relationship types, ownership choices, business units, security roles, activity tables, and system fields. Each can affect how records are seen or related.
Microsoft’s current Dataverse documentation confirms one-to-many and many-to-many relationships. It also treats relationship behavior as part of the model. The Microsoft Dataverse relationship documentation shows why those links are part of the source model. A table-by-table export therefore doesn’t fully describe how the application behaves. The Salesforce target has to reproduce the business relationship, not the source schema for its own sake.
A Dynamics 365 to Salesforce migration should pay close attention to these areas:
- Business unit and team ownership used for access.
- Security roles and the depth of record access.
- Activity records and the “regarding” relationship.
- Choice fields and status values.
- Custom tables and alternate keys.
- Business process flows, plugins, workflows, and Power Automate flows.
- System-managed owner and timestamp fields.
- Many-to-many relationships that need junction objects or another Salesforce model.
Dataverse security is a specific risk. Microsoft documents record ownership by users or teams and access levels that can follow business unit hierarchy. The Dataverse security role documentation shows how ownership and business-unit access can shape record visibility. Salesforce uses its own role hierarchy, sharing rules, permission sets, queues, territories, and ownership model. The migration team has to redesign access in Salesforce and test it by persona. Copying owner names doesn’t recreate Dynamics security.
Activities and “regarding” links
Dynamics activity records can point to another record through a “regarding” lookup. Salesforce activity relationships use its own fields and object rules. Each activity type and parent relationship needs a clear map. Historical calls, tasks, or meetings must appear on the right account, contact, lead, case, or opportunity.
This is where source IDs matter. If activities are exported without stable IDs, the team may have to match on names or subject text. That creates avoidable risk.
Export limits and unsupported fields
Microsoft’s Dataverse export documentation states that the standard single-table CSV export has a 12-minute time limit. It also lists unsupported fields or data types for that route, including files, images, multi-select choices, and several system fields. The Dataverse CSV import and export documentation lists those limits and unsupported fields. Large or complex Dynamics programs may therefore need a different extraction method than a simple table export.
The extraction method should be chosen based on the data that must survive, not on which button is easiest to find. If files, ownership, audit context, or system dates matter, prove the export path with a sample first.
What Breaks Across All Three Source CRMs
When migrating to Salesforce, the source platform changes the details, but the same failure classes appear in almost every project. These are the areas that deserve explicit acceptance tests.
Record identity and duplicates
Names and email addresses aren’t stable enough to serve as the only migration key. Companies rename themselves. Contacts can share an email alias. Duplicate records may already exist in the source. Salesforce can also block or flag records through matching and duplicate rules.
Use an immutable source ID on every migrated record where possible. Salesforce external IDs can support matching in approved import cases. Its Data Import Wizard also has matching logic that can reduce duplicate creation. Preserve the source ID even after go-live because it gives support teams a clean trace back to the source archive.
The CRM migration to Salesforce should include a duplicate policy before loading. Decide whether duplicate candidates are merged before migration, held for review, or loaded separately. Don’t disable duplicate controls casually just to make an error file disappear.
Parent-child relationships
Relationships break when child records load before their parents or when source IDs are replaced without a crosswalk. Accounts usually need to land before Contacts and Opportunities that reference them. Custom parent objects need the same treatment.
This is one reason Salesforce implementation handover guidance matters after implementation. A handover should record the object map, source IDs, load sequence, transformation rules, and unresolved exceptions. It should also keep the reconciliation results so future admins can explain how the migrated data was built.
Required fields and validation
The source CRM may allow a blank or free-text value where Salesforce expects a required field or controlled picklist. Validation rules can also reject a record that looked valid in the source.
Do a pre-load check against the real target rules. Error handling should separate bad source data from target design problems. If thousands of rows fail the same validation rule, changing each row by hand is usually the wrong fix. The mapping or target rule needs review.
Historical activity and files
History is often the largest volume and the least tested part of a Salesforce migration. Calls, notes, meetings, emails, tasks, and files need both content and context. A history record attached to the wrong parent can be more damaging than a missing record because users may trust it.
Decide how much history belongs in the live org. The choice should follow legal, service, sales, and reporting needs. Older material that doesn’t need to be operational can remain in an accessible archive if that meets business and compliance requirements.
Automation
Automation should be rebuilt from approved business rules. The old CRM may contain duplicate workflows, dead branches, temporary fixes, or actions tied to tools that won’t exist after cutover.
For a CRM migration to Salesforce, each automation needs an owner and a test case. Salesforce implementation team planning guidance is relevant because business users must reserve time to confirm requirements and perform UAT. The project team can build the rule, but only the process owner can confirm that the result matches real work.
Integrations and reporting
Every inbound form, outbound sync, finance connection, marketing tool, support platform, identity provider, and BI feed should be included in the migration inventory. The integration contract needs to state the matching key, field direction, update frequency, error path, and system of record.
Reports need the same treatment. Rebuilding a dashboard by visual appearance can hide semantic changes. Define each metric in words first, then map it to Salesforce fields and filters. This is especially important when lifecycle stages, deal stages, or owner structures changed during the Salesforce migration.
How to Build a Migration Plan That Preserves Meaning
For teams migrating to Salesforce, the safest plan uses a sequence of decisions followed by controlled loads. A large CSV should appear late in the project, after the target model and acceptance rules are clear.
Define scope and success
List the source systems, objects, data history, files, users, integrations, reports, and automations in scope. Then define what must be true at go-live. Success criteria should include business outcomes such as accurate open pipeline, correct account ownership, usable activity history, and report reconciliation.
This step keeps a CRM migration to Salesforce from turning into “move everything.” It also creates a place to document exclusions. If old campaign responses or dormant records will remain in an archive, state that before UAT.
Build the source-to-target map
Map objects first, relationships second, then fields. Include source IDs, data types, allowed values, defaults, owners, required fields, and transformations. Add a column for “used by” so each field’s workflows, reports, integrations, and formulas are visible.
For a HubSpot to Salesforce migration, this is where Contacts split into Leads or Contacts and where deal pipelines get their target design. For a Zoho to Salesforce migration, custom modules and Blueprints need a target decision. For a Dynamics 365 to Salesforce migration, Dataverse relationships and access rules need a Salesforce design.
Clean and freeze the target design
Remove duplicate source values and standardize picklists. Resolve invalid owners, decide what to do with inactive users, and repair broken source relationships that matter. Don’t use migration as an excuse to rewrite every process. Fix what blocks the move or would reproduce a known defect.
The Salesforce target should reach schema freeze before the full rehearsal. If fields and relationships keep changing, migration scripts and tests won’t have a stable target.
Build the load sequence
Parents load before children. Reference data and users may need to exist before business records. After each load, save the Salesforce IDs against the source IDs so later files can reference the new parents.
Small imports may use the Salesforce Data Import Wizard, which currently supports up to 50,000 rows per import file for supported objects. Larger or more technical loads may use Data Loader or another approved method. The tool choice should follow volume, object coverage, required operations, and the need for logs.
Rebuild automation and integrations
Disable or control automation during bulk loads when the approved migration plan requires it, then test the final production behavior before go-live. A record-triggered Flow can create side effects during import. Email sends, owner changes, and child-record creation all need to be considered in the load design.
Integration work should be tested against real keys and failure cases. Salesforce API integration services can support this stage because API connections need monitoring, retry rules, and clear ownership after launch. A successful load doesn’t prove that tomorrow’s sync will behave correctly.
How to Test the Migration Before Cutover
When migrating to Salesforce, testing should use representative data rather than a handful of clean records. Include duplicates and records with missing optional fields. Add open and closed deals, inactive owners, long text, international characters, files, custom objects, and records with many relationships.
Salesforce’s migration guidance recommends testing in a sandbox before the production move and validating the imported data afterward. The test should therefore cover technical acceptance and business acceptance.
| Test | What to verify |
| Record reconciliation | Source count, loaded count, rejected count, excluded count |
| Field reconciliation | Key field values match the approved transformations |
| Relationship test | Child records point to the correct Salesforce parent |
| Ownership test | Active and inactive source owners follow the mapping rules |
| Security test | Each persona can see and edit only what the design permits |
| Automation test | Flows, approvals, assignments, and notifications behave as expected |
| Integration test | Inbound and outbound changes use the right keys and direction |
| Reporting test | Pipeline, conversion, service, and management metrics reconcile |
| File test | Sample files open and are attached to the correct records |
| User test | Real users can complete their common tasks without workarounds |
The HubSpot to Salesforce migration test should include lifecycle and Contact-to-Lead decisions. The Zoho to Salesforce migration test should cover Blueprint replacements, custom modules, and file relationships. The Dynamics 365 to Salesforce migration test should include access personas, activities, and many-to-many relationships.
UAT shouldn’t ask users to “look around.” Give each tester a script based on real work. A salesperson might create a Lead, convert it, open the Account, update an Opportunity, and check history. A service user might find an old customer, review prior activity, create a Case, and confirm access. The test result should be pass, fail, or accepted exception.
How to Run Cutover Without Losing New Activity
When migrating to Salesforce, cutover begins before the final export. Define when the source CRM becomes read-only and how new leads are handled during the freeze. Set the integration stop order and the person who can approve go-live. The shorter and clearer the write-freeze period is, the easier reconciliation becomes.
A CRM migration to Salesforce usually needs a final delta for records created or changed after the rehearsal snapshot. The team should identify those rows with a reliable timestamp or change log. The final delta should use the same transformation rules as the main migration. New activity shouldn’t be copied manually unless the volume is tiny and the process is controlled.
Use a cutover runbook with 4 parts:
- Stop or redirect source-system writes and scheduled integrations.
- Export the final delta, transform it, load it, and capture errors.
- Reconcile open pipeline, key account counts, ownership, relationships, and high-risk history.
- Enable production automation and integrations in the approved order, then perform smoke tests.
Don’t decommission the old CRM the moment Salesforce opens. Keep the approved archive or read-only access for the period required by the migration plan. It gives the support team evidence when users report missing history or conflicting values.
What to Validate After Go-Live
After migrating to Salesforce, post-go-live validation should focus on behavior that only appears under real use. Users will expose edge cases that rehearsals missed, especially around permissions, assignment, integrations, duplicate handling, and reports.
Track failed integrations, rejected records, duplicate creation, records without owners, records without expected parents, and automation errors. Compare important Salesforce reports against the final source snapshot until the business owner signs off on the new metric definitions.
A Salesforce migration also needs operational handover. The team should retain the source-to-target map, load files, scripts, crosswalks, error logs, accepted exceptions, test results, and rollback notes. That evidence makes later support faster because admins can distinguish a migration decision from a new defect.
For a move from HubSpot, watch lead routing, marketing handoff, association-dependent reporting, and duplicate creation. For a move from Zoho, watch custom process replacements, owner assignment, and related files. For a move from Dynamics 365, watch security visibility, activity parents, and integrations that previously depended on Dataverse identifiers.
A failed migration often looks like a normal org with hidden trust problems. Salesforce implementation audit guidance explains the symptoms that appear when pipeline reports, ownership fields, or user behavior stop matching the intended Salesforce design. Those symptoms are useful post-go-live checks even when the initial cutover looked successful.
Conclusion
For teams migrating to Salesforce, the hardest part isn’t moving rows. It is preserving the business meaning that lived around those rows. HubSpot, Zoho, and Dynamics 365 each store customer work differently. The target org therefore needs an explicit design for identity, relationships, lifecycle, ownership, history, automation, security, and reporting.
A HubSpot to Salesforce migration needs careful decisions about Leads versus Contacts, lifecycle stages, associations, pipelines, and marketing handoff. A Zoho to Salesforce migration needs clear handling for custom modules, Blueprints, functions, picklists, files, and related records. A Dynamics 365 to Salesforce migration needs deeper work around Dataverse relationships, activities, business units, ownership, and security.
A CRM migration to Salesforce is ready for production when the team can prove 4 things. The records are present, relationships are correct, business rules behave correctly, and users can trust the reports. That proof comes from mapping, rehearsal, reconciliation, and controlled cutover.
FAQs
What usually breaks first when moving to Salesforce from another CRM?
Relationships and business logic usually fail before basic record counts do. Contacts can lose account links and stages can change meaning. Activities can attach to the wrong parent, while old workflow behavior can disappear unless it is rebuilt. A Salesforce migration should therefore test data relationships and process behavior alongside row counts.
Can HubSpot data be moved directly into Salesforce?
Core HubSpot records can be exported and loaded, but a HubSpot to Salesforce migration still needs design work. HubSpot Contacts don’t automatically tell you whether the Salesforce target should be a Lead or Contact. Associations, lifecycle stages, deal pipelines, activities, and workflows also need mapping or rebuilding.
What is the biggest risk in a Zoho migration?
A Zoho to Salesforce migration can look simple because standard modules have familiar matches. The main risk is assuming that Blueprints, custom modules, functions, picklists, files, and related records will behave the same after import. Those areas need explicit target rules and tests.
Why is Dynamics 365 harder to migrate than a flat CRM?
A Dynamics 365 to Salesforce migration often includes Dataverse relationships, business units, team ownership, security roles, activities, and system-managed fields. Those features affect access and record meaning, so a simple table export can’t represent the whole application.
Should all historical CRM data be loaded into Salesforce?
Only data that has an approved operational, reporting, legal, or service reason needs to live in the production org. Older history can remain in an accessible archive when that meets business and compliance needs. The migration scope should define this before extraction begins.
How do external IDs help during migration?
An external ID can store a source-system identifier in Salesforce. That gives the migration team a stable key for source-to-target matching. It also helps rebuild relationships after parent records receive new Salesforce IDs. It helps later support teams trace migrated records back to the source as well.
How should automation be handled during migration?
Document each source rule as business logic, then rebuild it in Salesforce using the right target mechanism. Test triggers, conditions, actions, exceptions, and failure handling with representative data. Don’t assume a workflow can be copied across platforms just because both CRMs have automation tools.
How do you know a migration is ready for go-live?
When migrating to Salesforce, go-live is ready when the agreed test set passes and record relationships reconcile. High-risk reports must match their approved definitions. Security must pass persona tests. Integrations must handle normal and failure cases, and the cutover team needs a runbook for the final delta and rollback.
