The goal is an office record staff can use and explain. A beautifully displayed map is not enough if nobody can show which source supports a location, who reviewed a discrepancy or why a plot's status changed.
Where should a cemetery start?
Start with an inventory of sources and daily work. List the registers, deed books, index cards, maps, spreadsheets and document folders the office uses. Record who maintains each source and whether staff consider it authoritative for a particular question.
Ask employees to demonstrate three ordinary tasks: finding a burial, checking a space before a sale and retrieving a supporting rights document. Note where they rely on memory, a handwritten correction or an unofficial cross-reference. These are migration requirements, even if they do not appear in the software sales presentation.
The Utah State Historic Preservation Office's cemetery resources include a burial-data template and identify digitization and GIS mapping as cemetery project types. That is a useful public example of structured cemetery data work. It does not mean a particular cemetery qualifies for a grant or that any one template covers all operating records.
What should you scan and preserve?
Preserve the originals' context. A scan of one ledger entry can become hard to interpret if the page heading, column labels or marginal note is missing. Establish a naming convention and keep the page or volume reference with the transcribed entry.
Record the source document's date where available and the scan or transcription date separately. They describe different events. A file created this year may contain an entry written many decades ago.
Check image quality before a large batch is accepted. Staff should be able to read the smallest relevant writing and identify the page. Keep a list of unreadable or damaged items. Repeatedly enlarging a poor scan does not restore information that was not captured.
Use the cemetery's retention and records policy for originals. Digitization alone should not be taken as authorization to dispose of physical records. The applicable requirements need to be checked by the responsible records professional or adviser.
How do you structure the searchable data?
Separate the person's information, the property's location, rights documents and interment events. A stable space identifier links the records. Preserve the original location text alongside any standardized version so staff can trace a search result back to the source.
For each transcribed value, retain enough source information to locate the evidence. This can be a document ID and page number rather than a copy of the whole source in every row. The source pointer matters most when two records disagree.
Our recommended migration dictionary includes:
| Field group | Example fields | Review question |
|---|---|---|
| Identity | Source name, reviewed display name, aliases | Was a spelling standardized or actually corrected? |
| Location | Cemetery, section, lot, grave, source map | Does the identifier refer to the same space in every source? |
| Interment | Event date, event reference, status | Is this a completed event or a planned booking? |
| Rights | Recorded holder, document ID, review status | Is this a verified relationship or an unresolved request? |
| Provenance | Source volume/page, transcriber, reviewer | Can someone reproduce the interpretation? |
| Exception | Type, owner, next action | What is still unknown? |
Do not convert a blank field to a confident value merely to satisfy an import requirement. If the receiving system requires a value, agree on a documented representation of unknown information before importing.
What do you do when maps and registers disagree?
Create an exception, preserve both values and identify the decision needed. A transcription error, a numbering alias and an uncertain burial location are different problems. They should not all be sent to the same “data cleanup” task.
A useful exception log records the affected space IDs, conflicting values, source references, apparent issue, person assigned and approved resolution. Include “not yet resolved” as a valid outcome. The reviewer should be able to explain why a value changed without relying on an undocumented conversation.
In a first-hand plot-map discussion, a cemetery describes missing grave locations and irregular placement. That problem cannot be solved simply by drawing a regular grid in software. Where physical locations are uncertain, seek the appropriate surveying, archaeological or preservation expertise and required permissions.
Do not treat a blank area on a map as evidence that ground is unoccupied. An office data project and a professional investigation of uncertain ground are different scopes of work.
How should a pilot migration work?
Choose a representative section, not only the cleanest records. Include old and recent entries, a numbering change, a corrected document and an unresolved question. Agree on the expected result before the vendor imports anything.
Have ordinary office staff use the pilot. Ask them to find an entry from a surname, retrieve its source page and explain its status. Then ask a second person to repeat the task without help from the person who prepared the import.
Compare record counts at each stage, but investigate what the counts mean. One ledger entry may generate a person record, a property link and an interment record. A larger number of rows in the new database is not necessarily duplication; matching totals are not necessarily accuracy.
Document acceptance criteria in plain language. For example: every imported interment has a source reference; every space has a stable ID; unresolved conflicts remain visibly flagged; staff can retrieve the supporting scan. These are proposed project criteria, not a statistical guarantee for records outside the pilot.
A worked example: two names and one space
In a fictional cemetery section, an index card lists one spelling of a surname, the register lists another and the map shows an abbreviated name. The migration team initially proposes creating three people because each source has a different text value.
The reviewer instead links the entries as a possible match and records the source references. The team checks the relevant supporting records before deciding whether they represent the same person. If the question remains unresolved, the new system retains the ambiguity rather than merging automatically.
This example illustrates why matching by name alone is insufficient. Dates and space identifiers can help reviewers investigate, but the team's approved process determines whether the evidence supports a merge.
How do you protect daily operations during conversion?
Decide which system is the working record during the project. Keep a controlled record of changes made after the export so new sales, interments and corrections are not lost between the pilot and final import.
Assign a cutover owner and a fallback procedure. Staff need to know where to record an urgent change if the import is paused. Avoid maintaining two unofficial masters indefinitely; disagreements between them become another migration problem.
Before acceptance, test search, document retrieval, corrections and an export of the cemetery's records. Confirm what the export includes and what needs a separate request. A migration is easier to evaluate when the cemetery can inspect both the imported record and its source.
FuneralHQ includes cemetery mapping, inventory and deeds. Bring the pilot requirements to a workflow demonstration, and compare vendors using the same evidence. The software migration guide covers the wider changeover; the cemetery project also needs source maps, property relationships and unresolved-location records accounted for explicitly.
Blank working template
Open the accompanying blank CSV worksheet. This editorial template contains headings only. Adapt it to the firm’s reviewed process before use and keep completed records in approved storage.
The FuneralHQ advantage
Start with one case, then build from there
Bring the folder, forms and checklist you use today. We will show how the same work fits into FuneralHQ and agree on the first records to move.
We will work through a real example with you, from the first details to the finished record.
See it on one of your casesAbout the FuneralHQ Editorial Team
This guide was written by the FuneralHQ Editorial Team, the in-house team behind funeral home software used by independent firms to run cases, documents, payments, and QuickBooks sync in one record. Our editorial standards explain how we review product claims, outside sources, automation, updates, and corrections.
