Warranty Data Migration: A Go-Live Reconciliation Checklist

The import finished, and the destination has the expected number of claims. Then a reviewer opens a claim that was awaiting inspection. Its status is closed, its registration points to the wrong unit, and nobody can tell which coverage terms applied when it was filed. The import finished. The work is not ready. Can staff continue the claim and explain past decisions from the migrated record?

A reconciliation checklist gives the business owner something to inspect before saying yes to go-live. It connects each source cohort and transformation rule to a destination check, an exception owner and a sign-off decision. This is manual acceptance guidance for your team and vendor. The matrix below is not a native WarrantyHub migration report or a universal data schema.

What must be reconciled before sign-off?

Start by naming every source system and the records in scope: registrations, units, policies or coverage references, claims, statuses, financial fields and documents needed for ongoing work. For each cohort, identify its source ID, intended destination ID, mapping rule, and the relationship that must survive. A row count alone cannot tell you whether the right claim still belongs to the right unit.

Agree on a baseline before import. Record when each source export was taken, which statuses it included, and how counts or amounts were calculated. Then define what a passed comparison looks like and who can accept an exception. Some differences are intended transformations, such as a renamed status; others mean the record changed meaning. Put the rule and its version beside the comparison so a reviewer can tell them apart.

Use your own terms and retention obligations to decide which history must remain operational, which may be accessible in an archive, and how an older coverage decision will be explained. There is no universal purge age or accuracy threshold that substitutes for those decisions. The warranty software implementation guide covers the broader preparation and rollout; this checklist focuses on acceptance evidence at the point of go-live.

Build the on-page field-map and sign-off matrix

Give each important field or relationship a row that can be checked independently. The example IDs, amounts and statuses below are fictional and illustrative. They are not customer data, a WarrantyHub schema, or a promised importer output. In a real project, use your approved field names, record locations and evidence references.

The evidence column should point to a named export, comparison file, screenshot or reviewed record with a timestamp. It should not merely say “looks right.” The sign-off column names the person who accepted the check and the date, or remains pending. If the vendor handles the import, the buyer still owns the acceptance question: which differences can staff live with, and who is authorized to say so?

Compare records, relationships and totals

Reconcile counts by defined cohort: for example, active registrations, open claims at the baseline, or claims with a reserved amount. Compare like with like. If the source count includes archived records and the target count includes only operational records, document that scope difference before interpreting the gap. For each status, compare its meaning as well as its count. A renamed status can be correct; a closed claim mapped from “awaiting inspection” needs an explanation.

For financial fields, agree on currency, date basis, whether the number is paid or reserved, and whether reversals or adjustments are included. Compare totals and then inspect individual records that make up any difference. An equal total is not proof of a correct migration: two amounts can be assigned to the wrong claims and still sum to the same number. The same is true of relationships. The expected number of registrations can be present while several point to the wrong units.

Sample source-to-target pairs across ordinary and difficult cases. Follow a registration to its unit, coverage reference and claim. Open the record as the person who will continue the work, not only as the person who built the import. Can they find the prior decision and the next action? The warranty registration page describes the broader registration context, but your migration check must prove the specific relationships in your own data.

Keep mismatches visible until corrected or explicitly accepted. A failed row needs its source evidence, target evidence, suspected cause, owner and next test. After a mapping change, rerun the affected cohort rather than fixing one example and assuming its peers are correct. Preserve the version of the rule used for each run so a later reviewer can reconstruct why a target value appeared.

Rehearse the open-claim delta

An import rehearsal is a snapshot. Claims continue to change while the team works: an inspection arrives, a reserve changes, a customer supplies a document, or someone closes a case. Choose a baseline cutoff and record every relevant source change after it. At cutover, identify those changes, apply the agreed handling, and rerun the comparisons against the cutover snapshot. A successful rehearsal does not prove that later changes were captured.

Walk one difficult open claim from source to destination. Confirm its owner, status, next action, linked registration and unit, applicable coverage reference, financial state and documents needed to decide it. Ask who will answer the customer if the record is in neither team’s working queue during the switch. Record the handoff time and the person responsible for checking that the claim remained actionable.

Separate access to archived history from operational continuity. A read-only archive may let someone retrieve an old document; it does not by itself put an open claim in the right queue with the right next action. Decide which historical information must be reachable for decisions and which active work must function in the destination. Confirm retention and coverage handling under your actual terms and with counsel.

Keep the evidence behind sign-off

For each completed check, retain the source export name and timestamp, target comparison name and timestamp, mapping rule version, mismatch resolution, reviewer and approval date. Record known exceptions in plain language, including their effect on customers or staff and the owner of the follow-up. A go-live decision should refer to this evidence, not only to a completed import job or a vendor assurance.

Ask the vendor to demonstrate how source IDs, policy versions, claim relationships, mismatches and attachments would be checked for your data. Also ask which checks are manual, which are produced by tooling, and how you would inspect the result. Do not assume migration audit reports, native line-item reconciliation, attachment handling or preserved historical policy versions. These are scope and demo questions.

WarrantyHub Essentials includes onboarding. Custom pricing is scoped to your volume, workflows and integrations, and Custom onboarding is quoted separately; confirm which migration and reconciliation work is in scope rather than assuming fixed inclusions. WarrantyHub’s stated implementation window is 30–60 days, scoped to the project rather than a guarantee. Use the manufacturer RFP checklist if you are still comparing vendors; once a vendor is selected, make these acceptance rows part of the implementation conversation.

Frequently asked questions

What happens when a reconciliation row fails?

Keep the row open with a named owner, the source and target evidence, the cause being investigated, and the next comparison. After a correction, rerun the check and record the new result. A reviewer should explicitly accept any remaining exception before sign-off.

How should we check attachments?

List the attachment types and source records in scope, then sample whether each required item can be located, opened and associated with the right destination record. Ask the vendor to demonstrate how attachments would be handled for your migration; do not assume that every file moves or remains accessible.

Do historical coverage rules need to move into the new system?

Decide how a reviewer will find the terms that applied to an older registration or claim. That may require a mapped version, a linked archive or another agreed method. Confirm the treatment with the vendor and qualified counsel, and document the accepted approach rather than assuming historical versions are preserved.

General information, not legal advice; follow your actual terms and qualified counsel.