Moving 1094-C Reporting to New Software: A Data Checklist

Separate source facts, prepared drafts, approved filing versions and actual agency outcomes. A payroll roster explains part of the source population; it is not the same artifact as a transmittal that was approved and sent. An old status screenshot may help navigation, but an identifiable acknowledgment provides different evidence.

Record format, export owner, storage location and retrieval method for each group. Some items may remain in a controlled historical archive rather than becoming editable records in the new application.

Map the old platform's employer key to the new key using the reported employer identity and reporting year. Keep administrative changes, such as a new department label or parent dashboard, separate from the historical filing identity. Do not overwrite a prior filed record with today's organization name just to make an import consistent.

The 2025 instructions require an authoritative transmittal for each ALE Member. Your migration should therefore preserve which employer a historical authoritative record summarized, even when several employers now share an account or administrative group. Legal changes in ownership or reporting obligations need their own reviewed treatment; matching software keys cannot resolve them.

Use a crosswalk with old key, historical employer identity, reporting year, new key, current display label and mapping rationale. Flag one-to-many or many-to-one mappings for review. Those patterns may reflect a legitimate administrative structure, but they can also hide accidental pooling of employer histories.

Publication 5165 uses transmission, submission and record identifiers to associate AIR records and their follow-up. Preserve the applicable original references alongside each later correction or replacement. A migration-generated internal ID can help search, but it does not replace the agency references needed for the actual filing procedure.

Ask the new provider to demonstrate whether it can import those associations, retrieve historical evidence and support the specific prior-year operation you may need. If it cannot, agree on an accessible archive and a workable service process before closing the old account. A product's support for preparing this year's transmittal is not evidence of support for every historical correction scenario.

Keep rejected attempts and accepted versions distinguishable. Do not mark all imported rows accepted merely because a prior vendor supplied them, and do not infer rejection from a missing imported status. Mark missing evidence as an unresolved migration issue.

Fictional example: Summit Fabrication exports its 2025 history from an old platform. Cedar East, old employer key CE-47, has 120 original employee returns. Cedar West, old key CW-19, has 80. Each has its own reviewed authoritative transmittal. The new platform assigns keys E-100 and E-200 while placing both under a shared Summit administration dashboard.

Cedar West also has three accepted employee-return correction events affecting two original employees: one employee was corrected twice and the other once. The migration inventory therefore contains 200 original employee-return identities plus three correction events. It does not contain 203 unique original employees. The original and later accepted versions must remain linked in the correct order.

The evaluator selects the twice-corrected record, retrieves its original and both correction outcomes, and identifies the latest accepted version. They also retrieve Cedar East's 120-return history separately from Cedar West's 80-return history. A dashboard total of 200 is useful, but it cannot replace those employer-specific records.

Begin with one employer, one reporting year and a sample containing an authoritative transmittal, a second batch if applicable, an accepted correction and an unresolved item. Use an authorized migration preview or test environment; importing history should not itself initiate an agency transmission.

Compare old and new values for employer identity, year, batch count, authoritative designation, monthly fields and record associations. Check blank values, zero values and fields not required under the applicable treatment separately. Document transformations such as a new internal key or normalized date display, and distinguish them from changes to reported facts.

Ask someone who did not build the mapping to retrieve the sample from the new workflow and archive. They should be able to explain the historical value and locate the actual outcome evidence. If they cannot, fix the mapping or retrieval process before expanding the import.

Reconcile the full export using separate totals for employers, reporting years, original return identities, correction events and unresolved attempts. Counts can reveal omissions, but equal counts do not prove correct associations. Retain the sample comparisons and investigate any unexpected merges or duplicated histories.

Assign every open correction or uncertain transmission outcome to a named operational owner. Specify which provider will handle it and where the prior evidence is stored. Keep imported historical records out of a new-original release queue unless a reviewed filing task explicitly calls for that operation.

Before ending old access, successfully retrieve the selected records from the retained archive, confirm who can access it, and document the process for obtaining provider assistance. Coordinate the retention schedule with the employer's applicable requirements and policies. Use the permissions checklist to test historical access separately from authority to edit or release new work.