AncestryDesk migration guide
GEDCOM validator: how to check a GEDCOM file before import
A GEDCOM file that opens without errors is not necessarily ready to migrate. Broken cross-references, duplicate individuals, impossible dates and provider-only fields can survive an export from one service and fail silently or loudly when imported into another. A GEDCOM validator runs a local preflight that checks the file's structure before import, so you can fix problems in a controlled copy instead of discovering them halfway through a migration.
What a GEDCOM validator checks
A GEDCOM validator reads the file structure and reports four classes of problem: broken relationship links (a family record pointing to a person who was not exported), duplicate or ambiguous individuals (two records that may describe the same person), impossible or inconsistent dates (a child born before a parent, a baptism after death) and privacy exposure (contact details for likely-living people). It also flags provider-only tags that the destination service may ignore or misinterpret.
Step 1: Preserve the original export
Keep the source GEDCOM unchanged in a protected location and record where it came from. All review and repair work should produce a separate copy, so the original export can be re-validated or re-imported if something goes wrong. Record the file's SHA-256 checksum so you can prove the copy you are working from is identical to the export.
Step 2: Resolve relationship targets
GEDCOM stores relationships as cross-references between records. Every HUSB, WIFE, CHIL, FAMC and FAMS value must point to an individual or family record that actually exists in the file. A common export bug omits a referenced person, leaving a family pointing to nobody. The validator should report the exact family record and source line for every missing target, so you can decide whether to remove the broken reference or recover the missing person from the original service.
Step 3: Review people and dates
The validator presents duplicate candidates and chronology warnings in context, not as automatic fixes. Two individuals with the same name, birth year and birthplace may be one person or two; the validator cannot know. Never merge people or rewrite uncertain dates based only on a heuristic. Review each candidate, compare the source data and apply only copy-safe changes you can justify.
Step 4: Check privacy and portability
Treat any person with no death event as potentially living, especially when the birth year is within a conservative age window or no birth year is present. Inventory ADDR, RESI, EMAIL, PHON and WWW fields along with notes that may contain contact details. Redact sensitive values in the sharing copy; do not add a death event just to change privacy behavior. Also flag provider-only tags (custom underscore-prefixed lines) that the destination service may not understand.
Step 5: Export a documented copy
Apply only reviewed changes to a copy, never to the original export. Keep the audit report, the change log and the checksums beside the repaired GEDCOM so the migration is traceable. The repaired copy should pass the same validator a second time before import, so the destination service receives a file that has already been checked for the most common GEDCOM failure modes.
What a GEDCOM validation report should contain
A useful report lists the total number of individuals and families, every broken relationship link with the source line, every duplicate candidate with a similarity score, every chronology warning with the individuals involved and every privacy flag with the field name and a redaction suggestion. The report is evidence for a human decision, not a certificate that the file is correct, because a GEDCOM file can be structurally valid and still contain genealogical errors only a human reviewer can catch.