Data Migration and Cutover Planning for B2B Software

Common migration failure modes in B2B

Treating migration as the last task before go-live, with no dry run on production volume. Discovering duplicate natural keys Friday night. Assuming ERP and legacy app agree on customer master when they have not reconciled in years. Cutting over during customer's peak season because software was ready, ignoring business freeze windows. Skipping operator training on how migrated history appears in search and reports. No rollback plan when dual-write was promised but never tested. Support drowning in 'missing records' that were filtered by migration rules nobody communicated.

• Natural key collisions across merged sources
• Encoding and locale issues in names and addresses
• Historical status values with no mapping to new state machine
• Attachments and files left on network shares, not in database
• Open transactions in flight during cutover window

Inventory sources and define system of record

List every source: legacy SQL, Access exports, SharePoint lists, SAP extracts, third-party SaaS CSVs. For each entity (customer, asset, order, contract), name the system of record during transition and after cutover. During strangler migrations, two systems may own different fields temporarily. Document field-level ownership to avoid double edits and dual-write reconciliation gaps. Profile data quality early: null rates, orphan foreign keys, maximum string lengths, illegal characters. Share findings with business owners; some 'bad' data is legally required history.

Mapping rules, transforms, and validation

Maintain mapping spreadsheets or YAML in version control: source field, target field, transform function, default if null, business owner sign-off. Code review mapping changes like schema migrations. Validate with JSON Schema or database constraints plus business rules (credit limit non-negative, end date after start date). Reject rows to quarantine tables with error reasons, not silent drops. Preserve immutable history: original legacy ID, import batch ID, imported_at timestamp. Operators search by old reference for years. For audit and compliance, log who approved mass imports and parameter choices (date cutoff, included sites).

• Quarantine table for failed rows with export for business fix
• Checksum counts per entity type after each run
• Sample-based manual review for high-risk financial records
• Transform unit tests for date, currency, and unit conversions

Dry runs, performance, and rehearsal calendar

Run full migration against staging copy of production data at least twice before go-live. Measure duration, disk growth, index rebuild time, and application query performance post-import. Rehearse cutover calendar with customer ops: who is online, escalation phone tree, freeze on legacy edits, communication to field users. Dry run includes rollback drill, not only happy path. Automate comparison reports: row counts, sum of amounts, hash of key columns between source extract and target tables. Investigate any delta before signing go. Tie rehearsal gates to testing strategy UAT on migrated data, not only synthetic seeds.

Cutover models: big bang, phased, and parallel run

Big bang: single window, legacy read-only, import, verify, switch DNS or training. Fastest calendar time, highest risk, needs flawless rehearsal.Phased: migrate by site, business unit, or product line. Lower risk, longer calendar, requires tenant or scope configuration and clear data boundaries.Parallel run: operators use both systems while reconciling daily. Expensive but common in regulated or industrial contexts. Define reconciliation owner and tolerance thresholds. Match model to contract milestones: phased cutovers map to multiple acceptance gates and billing triggers.

ERP and master data synchronization during migration

When ERP remains system of record for customers or items, migration may load references not full masters. Import ERP keys, validate existence via API before insert, queue creates for missing masters with approval workflow. Align with integration patterns: idempotent upserts, conflict resolution when ERP changes during long import, freeze windows when ERP month-end blocks writes. Post-cutover sync jobs must handle records created in new app before ERP reflects them. Document lag tolerance in runbooks.

Rollback, communication, and hypercare

Rollback criteria defined before cutover: error rate threshold, reconciliation delta above tolerance, critical journey broken for more than N hours. Rollback means reverting DNS, re-enabling legacy edits, and communicating freeze on new app data entry. If new data was created post-cutover, rollback needs merge strategy or accept data loss scope explicitly in runbook (often unacceptable; prefer forward fix). Hypercare first two weeks: daily reconciliation reports, war room channel, prioritized defect SLA. Include migration-specific playbooks in go-live checklist.

Migrating off spreadsheets and tribal knowledge

Spreadsheet migration is political: the file is not just data, it is workflow. Interview owners about tabs, macros, color codes, and hidden columns. Import raw sheets to staging tables before normalizing. Replicate critical calculated columns in application logic with tests. Users will compare report totals to Excel for months. See build vs buy for internal tools when deciding how much spreadsheet behavior to encode vs simplify.

Budget and timeline for migration work

Migration often consumes 20–40% of total project effort for replacement projects, higher when multiple sources or poor data quality. Underbudgeting migration shows up as go-live slips, not code delays. Include migration in development cost estimates as its own workstream with dry runs, not a single developer weekend. Contractor engagements should specify number of rehearsal cycles, reconciliation report format, and customer obligations (timely extracts, sign-off on mapping).

Next steps

Export one entity from each source system this week. Run profiling queries. Name system of record per field. Schedule first dry run date before promising go-live. See other resources, case studies, book a call, or send a message with source systems, record volumes, cutover constraints, and whether ERP stays authoritative.

FAQ