How to Detect Data Breaks Caused by a Business Software Migration

“The migration completed” is a system status. It is not proof that the business data still means the same thing.

A migration can load nearly every row and still break reporting, billing, operations, or customer service. Customer records may arrive without their account owners. Invoices may retain their numbers but move into the wrong status. Timestamps may shift enough to put late-day activity into a different accounting period.

Treat the migration as a controlled comparison problem, not a one-time loading problem. A data break is an unexplained loss, addition, alteration, relinking, or timing shift that makes records or business measures unreliable across the cutover boundary.

The practical test is to compare the old and new environments in five layers.

Start with a baseline you can reproduce

Before cutover, capture a dated baseline from the source system. Record the extraction time, filters, record counts, distinct IDs, duplicate rates, null rates, minimum and maximum dates, and a short list of important numeric totals.

Also preserve the definition of each measure. “Active customer,” for example, may mean a customer with an open contract in one system and a customer with any activity in the past year in another. A difference caused by a changed definition should be documented as expected, not discovered later as a mystery.

Do not rely on a database-wide row count. Break counts out by meaningful segments: entity type, legal entity, business unit, country, month, lifecycle status, source system, and record age. A total can match while one segment is missing and another is doubled.

Confirm identity before comparing values

Row-level comparisons only help when the corresponding records can be identified. Review the migration crosswalk between legacy and target IDs. Count unmatched IDs in both directions, and investigate new duplicate keys.

This matters most for master data. In an HR migration, employee counts can match even when two legacy worker IDs merge into one target identity. The consequence may not appear until payroll, benefits, or manager assignments are joined back to the employee record.

A primary key or other stable unique identifier makes this work easier. Where the new system deliberately changes identifiers, keep an approved crosswalk and test its completeness. Do not assume a name, email address, or description is a safe substitute for identity.

Look for field-level warning signs

Next, inspect fields that are vulnerable to conversion errors or central to a business decision. Useful signals include unexpected nulls, unusual string lengths, changed category frequencies, shifted date ranges, and changes in numeric distributions.

Pay close attention to data-type mappings, precision, character encoding, status conversions, and date or time-zone treatment. A ledger can balance in total while transactions near midnight land on the wrong posting date. Inventory units can match while inventory value diverges because one product family received an incorrect unit-of-measure conversion.

Checksums or hashes can provide stronger evidence than a row count when the records and fields should be unchanged. They are not proof of semantic equivalence. An approved transformation, a changed precision rule, or source updates still in flight can create a difference. Use them as a signal to investigate, not as the entire test plan.

Test relationships and business logic

Relationship checks catch errors that field comparisons can miss. Every order should point to a valid customer. Every invoice line should link to a valid invoice. Every employee assignment should connect to a valid employee and organizational unit.

Then test status logic and workflows. If an ERP migration preserves invoice counts but open receivables are lower, compare value by currency, legal entity, and invoice status. The issue may be a mapping that marked credit memos as closed rather than open.

Database checks are not enough. Run a few important end-to-end scenarios in the new software: create and amend an order, fulfill it, invoice it, issue a refund, close a period, or produce a management report. A data store can look sound while an integration, permission rule, or workflow produces a wrong business result.

Reconcile the cutover seam

The riskiest records are often those created or updated around switchover. If the old system remained active during the load, compare records changed immediately before and after the agreed cutover point. Look for late-arriving changes, duplicates, and gaps.

Use the same as-of time for source and target comparisons. Otherwise, ordinary transaction activity can resemble a migration defect. This is especially important when continuous replication or change capture is involved, because the source and target may be temporarily at different points in time.

Add a small set of business control totals that process owners recognize: unpaid receivables by currency, open orders by status, inventory quantity and value by warehouse, active subscriptions by plan, or current-period payroll totals. Pair these totals with segment checks and selected record comparisons. Aggregate totals can conceal offsetting errors.

Make exceptions decisions, not loose ends

A mismatch is not automatically a defect. It may be an approved transformation, a changed business definition, or a timing difference. The point is to make that disposition explicit.

For each exception, record an owner, suspected cause, affected record count, business impact, disposition, correction, retest evidence, and sign-off. Do not call the data ready because total rows match. Require critical controls to pass, expected differences to be documented, and unresolved issues to have a business-approved risk decision.

In the first week after cutover, watch for null-rate spikes, cliffs at the migration date, new duplicates, orphaned records, abrupt category shifts, delayed updates, and management reports that no longer tie to operational records. Those are often the earliest signs that a completed migration left a break in the data.