GEDCOM Explained: How to Move Your Family Tree Between Apps
Move a family tree with GEDCOM safely by auditing exports, transferring media separately, testing imports, and preserving the original database.
GEDCOM is a text-based exchange format for moving core genealogical data between family tree applications. It can carry people, relationships, events, names, places, notes, sources, citations, and some media references, but it does not guarantee a perfect copy of every app-specific feature. Treat a move as a tested migration, not a single export-and-delete action.
What GEDCOM is
GEDCOM organises genealogy as structured records linked by identifiers. The specification is maintained at GEDCOM.io; GEDCOM 7 is the current specification family, while many consumer applications still use or support GEDCOM 5.5.1 in some workflows.
A file commonly uses the extension .ged. Because it is an exchange format, the sending and receiving apps decide how their own fields map to it.
What usually transfers
Common data often includes:
- people and multiple names;
- parent, spouse, and child relationships;
- births, baptisms, marriages, deaths, burials, residences, and other events;
- dates and places;
- notes;
- source and citation structures;
- submitter information;
- references to media or bundled media in supported GEDCOM 7 packages.
Actual results depend on both apps and the GEDCOM version selected.
What can be lost or changed
App-specific templates, tasks, research logs, colour coding, chart layouts, custom fields, privacy flags, DNA tools, hints, match status, web links, story formatting, and local IDs may not map cleanly. Dates, place hierarchies, same-sex relationships, adoption roles, witnesses, and source templates deserve specific inspection.
Media is a frequent surprise. A GEDCOM may contain paths or URLs rather than the image files. MyHeritage explicitly notes that photos are not contained in a GEDCOM export. Copy the media separately unless your apps support and you have tested a packaged transfer.
Before exporting
- Back up the native database and media.
- Record app version, GEDCOM version, export options, date, and tree counts.
- Run duplicate and consistency checks without blindly merging.
- Resolve or document broken media links.
- Review living-person and private data.
- Decide whether the destination should receive the whole tree or a selected branch.
- Produce readable reports of important source-heavy people.
Never experiment on the only copy.
Choose export options deliberately
Read the app’s current help for character encoding, living-person filtering, notes, sources, media, privacy, and selected-person scope. UTF-8 is generally preferable for names and text across languages when supported.
Export to a new dated folder, for example:
2026-08-13_source-app_tree-name/
Keep the GEDCOM, media copy, export log, count report, and any warnings together.
Inspect the file safely
A GEDCOM is readable text, but do not casually edit it unless you understand the format and have a backup. Check the header for source app, character encoding, and GEDCOM version. Search for several distinctive people, notes, sources, and media references.
Do not upload a private GEDCOM to an unknown online “checker.” It may contain living people, notes, addresses, and submitter details.
Import into a new test tree
Create an empty database or temporary project in the destination app. Do not merge directly into an established tree. Save the import report and warnings.
Compare counts for people, families, events, places, sources, citations, notes, and media. Counts will not always match exactly because apps model data differently, but unexplained gaps need investigation.
Audit representative records
Check at least:
- a person with multiple names and conflicting events;
- an adopted, foster, step, or otherwise non-simple relationship;
- a household with several marriages;
- a source with several citations;
- notes containing formatting and non-English characters;
- a place with a historical hierarchy;
- private and living people;
- linked photographs, documents, audio, and URLs;
- a custom event or witness role;
- a person at the edge of the exported branch.
Export a GEDCOM back from the destination only as a diagnostic; a round trip can reveal which data the new app now owns, but repeated conversions may compound losses.
Move media separately
Preserve original filenames and folder structure until the import is verified. If the destination cannot locate files, use its documented relink tool rather than moving folders repeatedly. Confirm that thumbnails open the full asset and that captions, dates, owners, and rights remain connected.
Switch the system of record
Once the test passes, import the final export, repeat checks, and declare the destination authoritative from a specific date. Make the old database read-only and label it as archived so relatives do not continue editing both.
Keep the old app backup, export package, and audit report. A migration can appear successful while an obscure note or source field is only discovered missing months later.
GEDCOM is not a complete backup
Use it as one layer of resilience. A sound backup set includes:
- native app backup;
- GEDCOM exchange copy;
- complete media files;
- readable charts or reports;
- source inventory and research notes;
- multiple storage copies.
Quick troubleshooting
- Garbled names: check character encoding and re-export as UTF-8 where supported.
- Missing photos: copy media and repair paths; confirm whether the exporter bundled files.
- Flattened sources: compare source templates and preserve a readable citation report.
- Wrong relationships: inspect relationship roles and destination mappings.
- Living people exposed: stop sharing, fix privacy settings, and create a filtered export.
- Duplicate people: import into an empty tree and use reviewed matching rather than automatic mass merges.
The safest transfer keeps both sides until the destination proves that your relationships, evidence, uncertainty, and media—not merely the person count—survived.