Data Migration and Cutover Planning for B2B Software

Common migration failure modes in B2B

The most common mistake is treating migration as the final task before go-live, without rehearsing it at production scale. Duplicate natural keys are discovered on Friday night. ERP and legacy customer masters are assumed to match even though they have not been reconciled for years. Teams also cut over during a customer's peak season because the software is technically ready, ignoring business freeze windows. Operators then discover that migrated history behaves differently in search, reports, or workflows, creating avoidable support volume. The worst case is having no tested rollback path after promising dual-write or parallel operation. Support then gets flooded with 'missing record' reports caused by migration filters or mapping rules that nobody documented.

• Natural key collisions across merged sources
• Encoding, locale, and formatting issues in names and addresses
• Historical status values with no valid mapping to the new state machine
• Attachments and files left on network shares instead of being migrated
• Open transactions or edits still in flight during the cutover window

Inventory sources and define the system of record

List every source: legacy SQL databases, Access exports, SharePoint lists, SAP extracts, third-party SaaS exports, and operational spreadsheets. For each entity—customer, asset, order, contract—define the system of record during the transition and after cutover. During strangler migrations, two systems may temporarily own different fields. Document field-level ownership explicitly to prevent conflicting edits and dual-write reconciliation gaps. Profile data quality before designing transforms: null rates, orphaned foreign keys, maximum string lengths, invalid characters, duplicate keys, and unexpected value distributions. Review findings with business owners because some apparently 'bad' data may be required historical or regulatory evidence.

Mapping rules, transforms, and validation

Keep mapping rules in version control, whether as spreadsheets, YAML, or structured configuration: source field, target field, transform, default value, and business owner sign-off. Review mapping changes with the same discipline as schema migrations. Validate with JSON Schema or database constraints plus business rules such as non-negative credit limits and end dates that follow start dates. Send rejected rows to quarantine tables with explicit error reasons; never silently drop records. Preserve migration lineage: original legacy ID, import batch ID, source system, and imported_at timestamp. Operators may need to search by the old reference years after cutover. For audit and compliance, record who approved mass imports and which parameters were used, including date cutoffs, included sites, and mapping versions.

• Quarantine table for failed rows with an export path for business correction
• Row counts and checksum totals per entity type after each migration run
• Sample-based manual review for high-risk financial and operational records
• Transform unit tests covering dates, currencies, timezones, and unit conversions

Dry runs, performance, and rehearsal planning

Run the full migration against a production-scale staging dataset at least twice before go-live. Measure execution time, disk growth, index rebuild duration, lock behavior, and application performance after the import. Rehearse the cutover with customer operations: who is online, who owns escalation, when legacy edits freeze, and how field users are notified. A real rehearsal includes the rollback procedure, not just the happy path. Automate reconciliation reports covering row counts, financial totals, key-column hashes, and other business-critical aggregates between source extracts and target tables. Investigate every material delta before approving the cutover. Tie rehearsal gates to testing strategy and run UAT against migrated data, not only synthetic seed data.

Cutover models: big bang, phased, and parallel run

Big bang means one controlled window: make the legacy system read-only, run the migration, reconcile results, and switch users to the new system. It minimizes calendar complexity but carries the highest operational risk and depends on strong rehearsal. Phased cutover migrates by site, business unit, customer group, or product line. It reduces blast radius but extends the transition and requires explicit data boundaries, rollout controls, and reconciliation between waves. Parallel run keeps both systems operational while teams reconcile results. It is expensive but can be justified in regulated or operationally critical environments. Define the reconciliation owner, frequency, and acceptable variance before starting. Match the cutover model to contract milestones: phased migrations require multiple acceptance gates and clearly defined completion criteria.

ERP and master data synchronization during migration

When the ERP remains the system of record for customers, products, or other master data, the migration may need to load references rather than full master records. Import ERP keys, validate that referenced records exist before insert, and route missing masters through an approval workflow. Align the migration with integration patterns: use idempotent upserts, define conflict resolution when ERP records change during a long import, and respect ERP freeze windows around month-end or other critical periods. After cutover, synchronization must also handle records created in the new application before the ERP reflects them. Document acceptable synchronization lag, conflict ownership, and recovery procedures in the runbook.

Rollback, communication, and hypercare

Define rollback criteria before cutover: error-rate thresholds, reconciliation variance above tolerance, or a critical workflow remaining unavailable beyond an agreed duration. A rollback may require reverting DNS or routing, re-enabling legacy edits, and communicating a freeze on new-system data entry. If users have already created new records after cutover, rollback becomes a data reconciliation problem. Define the merge strategy in advance; in many cases, a forward fix is safer than accepting data loss. Plan a structured hypercare period for the first one to two weeks: daily reconciliation reports, a dedicated escalation channel, prioritized defect handling, and clear ownership. Include migration-specific procedures in the go-live checklist.

Migrating off spreadsheets and tribal knowledge

Spreadsheet migration is rarely just a data exercise. The workbook often encodes an undocumented workflow through tabs, formulas, macros, color conventions, hidden columns, and manual approval steps. Interview the owners before deciding what should be migrated, replaced, or removed. Import raw sheets into staging tables before normalization. Reproduce critical calculations in application logic with automated tests, because users will compare application totals against Excel for months after launch. See build vs buy for internal tools when deciding which spreadsheet behavior should become product functionality and which should be deliberately simplified.

Budget and timeline for migration work

Migration can consume 20–40% of total project effort in replacement projects, and more when there are multiple sources, weak data quality, or complex reconciliation rules. Underestimating migration usually appears as a delayed go-live rather than an obvious development overrun. Include migration explicitly in development cost estimates as its own workstream, including profiling, mapping, dry runs, reconciliation, cutover, and hypercare—not as a single developer task at the end. Contractor engagements should specify the number of rehearsal cycles, reconciliation report format, acceptance criteria, and customer responsibilities such as providing timely extracts and signing off on mapping rules.

Next steps

Export one representative entity from each source system this week. Run basic profiling queries, identify the system of record for each critical field, and document the first cutover assumptions. Schedule the first full dry run before committing to a go-live date. See other resources, case studies, book a call, or send a message with your source systems, record volumes, cutover constraints, and whether the ERP remains authoritative.

FAQ