A completed transfer is not an accepted migration
Data migration validation establishes that the agreed records reached the new application with the correct meaning and relationships. A successful import message cannot prove that. Even matching row counts can conceal orders assigned to the wrong customer, unusable attachments or values interpreted in a different unit.
This guide is for project owners and delivery teams preparing to accept migrated data. It focuses on evidence and acceptance, rather than choosing a migration engine or deciding whether to replace an application. The examples are hypothetical, not claims about EasySaz customer results.
Agree on the scope of acceptance
Specify entities, periods and statuses before testing. Inactive customers, cancelled orders, attachments and change history need explicit decisions. Records intentionally retained in an archive should not later be described as missing, but that exclusion needs approval and a retrievable record.
Assign a business owner to interpret each important data set and a technical owner to implement checks. A detailed discrepancy report cannot produce an acceptance decision when nobody is responsible for interpreting exceptions.
If the replacement strategy is still undecided, the legacy software modernization guide covers that broader choice. Once the approach is agreed, make data acceptance a separate deliverable rather than an activity added just before launch.
Treat the mapping as a meaning contract
For important fields, record the source, destination, type, transformation and treatment of invalid values. Similar column names do not establish equivalent meaning. A registration date in one application might represent creation, while another uses the field for final approval.
Maintain traceability between old and new identifiers. If duplicates are deliberately merged, record which source records map to the destination and who approved the rule. Counts may legitimately differ after that operation, but the difference should follow an agreed rule rather than an explanation invented after the run.
Do not automatically treat unknown, zero and not applicable as interchangeable. Filling every blank with a default may satisfy a form while changing the underlying information. Route unresolved cases to review instead of silently converting them.
Build several layers of evidence
Separate completeness, value correctness, relationship checks and business use. Report untested areas explicitly. A test that did not run is not a passing test, and a tool's unsupported data type remains a coverage gap even when the rest of its report is green.
Counts and coverage
Compare totals using the same scope filters, then break them into meaningful groups such as branch, status or period. One missing group and another duplicated group can leave the grand total unchanged. Keep identifiers and reasons for excluded records so the result can be reconciled.
Values and transformations
Compare important values against the approved transformation, not necessarily their raw representations. A changed format or structure may require a normalized expected result. Preserve enough evidence to explain what was compared and what the check could not evaluate.
The official AWS DMS validation documentation describes source-to-target record comparisons and discrepancy reporting, and notes the additional time and resources required. This illustrates why transfer completion and validation completion are distinct. It is not a recommendation that every project use that service.
Relationships
Check that each order belongs to the intended customer, each line belongs to the intended document and each attachment belongs to the intended case. A reference can point to an existing record and still point to the wrong one. Include merged accounts and multi-branch cases in testing.
Test dates, amounts and text deliberately
Identify whether a date represents a calendar day or a timestamp with a time zone. A due date should not accidentally be transformed like an event timestamp. Include day-boundary cases and older records, and check the rendered application as well as stored values.
For amounts, document units, precision and rounding. In a hypothetical comparison, 2,500,000 in both systems is not meaningful agreement if the units differ. Thousands separators belong to presentation; they should not accidentally become part of the raw numeric interpretation.
Persian text can contain different letter forms, digits and spacing. Any normalization should have a defined purpose and approved rule. Keep original values according to the retention policy, and do not silently rewrite names or document descriptions merely to make matching easier.
Reconcile aggregates without relying on them alone
Compare grouped totals that the business actually uses. A gain in one warehouse and a loss in another may cancel out at company level. Record the scope and discrepancy for each group rather than presenting only one matching number.
Human sampling is useful for complicated cases and application behavior, but it does not demonstrate correctness of every untested record. Combine broad automated checks with targeted human review and state the limits of both.
The custom software guide discusses defining and delivering an application. For data delivery, request a reconciliation report and a named approver alongside the feature list. A functioning report screen does not prove its underlying records are correct.
Make discrepancies actionable and repeatable
For each mismatch, retain the run identifier, relevant source and target identifiers, category, owner and resolution status. Distinguish migration defects from pre-existing quality problems and intentional changes. Keep the decision history after an issue is corrected.
Run corrective work in a test environment first and repeat the same controls. An interrupted migration should not create duplicate records when resumed. Test interruption and recovery deliberately in a safe environment, not by experimenting on production data during cutover.
Attach mapping and input versions to the validation result. Without those references, a successful report may describe an earlier run with different rules. Evidence must identify the precise data and transformation it covers.
Compare a defined point in time
If the source remains active, a difference may reflect timing rather than a defective transfer. Establish the comparison boundary and how subsequent changes are captured. Updates and authorized deletions matter as well as newly created records.
Microsoft's data migration go-live planning guidance discusses timing, validation, rollback and monitoring. It is platform-specific guidance; the general lesson used here is to make the operational decision before the final transfer window.
Once users write new information in the target, rollback is more complicated than switching the old application on. Decide how target-side changes will be handled, who can authorize the decision and what evidence is needed within the available window.
A discrepancy that row counts miss
Imagine 1,200 orders in scope and exactly 1,200 in the target. The count check passes. Relationship checks then show that orders from two branches were assigned to customers with matching names rather than the intended identifiers. Several attachments also fail to open.
The team corrects the identifier mapping, reruns relationship checks and validates the attachments separately. A business reviewer then follows a real workflow: locate the customer, open the order, inspect history and retrieve the relevant report. This connects technical evidence to the actual use of the records.
This is an illustrative scenario, not a project result. Select high-consequence cases and common exceptions with your own business owner instead of filling the review sample with only clean, simple records.
Assemble a data acceptance package
Include the agreed scope, mapping version, count and relationship results, unresolved exceptions and business-test evidence. Identify omitted checks and their reasons. Every remaining issue needs an owner and an explicit decision; a high overall pass rate should not hide a critical failure.
Use the software RFP checklist to make these deliverables part of the purchase scope. Ask about validation effort, rehearsals and discrepancy resolution before agreeing to a transfer-only estimate.
Move from transfer status to acceptance evidence
The useful question is not simply how many records moved, but whether the agreed information is usable with its meaning intact. Define scope and timing, test values and relationships, and resolve discrepancies through a traceable decision process.
Explore EasySaz custom software development services and contact the team about data migration with a high-level source description and a non-sensitive example. Establish access boundaries and a secure exchange method before sharing real operational data.