In this guide
A successful file upload proves that a system received something. It does not establish that all required records arrived, that the fields mean the same thing or that the effective dates are correct. Accept migrated payroll data only after reconciling the source, transformation and destination.
The DOL recordkeeping fact sheet emphasizes complete and accurate wage-and-hour records. A migration plan should preserve the information needed to explain the record, not just the number that happens to fit a new field. Applicable retention and access duties require separate review.
Define the population before counting it
Write down who belongs in the migration: active workers, future starters, terminated workers needed for year-to-date or historical reporting, and other authorized record groups. The same person may legitimately have more than one employment record, so distinguish a person count from an employment-record count.
Use stable authorized identifiers in your protected environment. Do not paste Social Security numbers, bank data or raw exports into public tools. This publication’s diagrams use fictional counts and do not offer a file upload.
Make the field map carry meaning
For each important field, record the source name, destination name, meaning, format, transformation rule and owner. A date of hire, service date and benefit-eligibility date may all look like dates while doing different jobs. An hourly rate and an annual salary are both money values but cannot be converted without a supported rule.
Flag fields that are derived, truncated, defaulted or not migrated. A default of zero can conceal missing information. A blank may mean unknown, inapplicable or intentionally removed. Write the distinction into the mapping rather than expecting the reviewer to infer it from a spreadsheet cell.
A fictional count that reconciles but still fails
Suppose an approved source contains 52 employment records. The destination also shows 52. During review, one expected record is missing and another appears twice. The count agrees, but completeness and uniqueness fail. Now suppose the duplicates are corrected and gross year-to-date pay matches in total. Two workers could still have offsetting errors that leave the total unchanged.
| Test | Fictional result | Meaning |
|---|---|---|
| Record count | 52 expected; 52 loaded | Necessary control, not proof of identity-level completeness |
| Identity reconciliation | One missing and one duplicate | Fail until resolved, even though counts agree |
| Aggregate money total | Source and destination both $680,000 | Useful balance; offsetting person-level errors remain possible |
| Targeted field test | Two effective dates shifted by one pay period | Fail affected records and assess the transformation rule |
The next move is not to inspect random rows until the file feels reliable. Investigate the error mechanism. If a date transformation caused the problem, find all records using that transformation. If an identifier collision caused duplication, examine the matching rule and its full affected population.
Preserve a controlled version chain
Name the source extract, mapping specification, transformed file and destination result. Keep versions connected through an internal migration run ID. Record who supplied and approved each stage, when it was created and what changed after review. A filename containing “final” is not a version-control method.
When a late correction arrives, decide whether to replace the full dataset or apply a controlled incremental change. Reconcile the affected population and totals again. Prevent the older file from being accidentally reloaded by marking its status clearly and limiting processing to the approved version.
Use an exception register that can close
Each exception needs an identifier, field or population affected, expected and observed values, impact, owner and closure evidence. Keep sensitive values in the authorized record system, and reference them from the issue log rather than copying them into a broadly shared project board.
Distinguish an accepted difference from an unexplained mismatch. A documented new-system calculation may intentionally differ from an old display. Acceptance requires a reason and an authorized reviewer; it should not be achieved by editing the expected value to match whatever the destination produced.
Test retrieval as well as processing
Ask a reviewer to retrieve a migrated record and its supporting context using the access they will have after launch. Confirm how unmigrated historical material will remain available. A project can move current values successfully while losing the evidence needed to explain a later question.
Finish with a signed-off scope of acceptance: dataset version, checks completed, resolved exceptions and remaining limitations. Bring that scope into the first-payroll acceptance pack. If the migration is not accepted, the launch decision needs an explicit response; the passage of the scheduled launch date does not make the data correct.