<p>The question of what has to survive a tracker migration usually gets answered with one word: the grants. Right instinct, incomplete inventory. The useful artifact is not a list of records. It is a field map: one line per source field, with a decision attached to each. Since the GrantHub sunset passed on 31 January 2026, the source for that map is a folder of export files, not a live account. Below is a short extract from a real-shaped map, with commentary on why each line reads as it does.</p>

<p>The format is four columns. Source field, target field, fidelity, owner. Then a note, because the note is where the reasoning lives and the reasoning is the part you’ll need in six months.</p>

grantcue (https://www.grantcue.com/blog/sample-grant-proposal-nonprofit-organization-templates-guide)

<h2>Line one</h2>

<p><code>grant_name → opportunity.title | exact | program | note: none</code></p>

<p>Every map has lines like this, and they lull you. A one-to-one text field, no transformation, no argument. Most of a map looks like this, which is why teams finish the exercise more confident than they should be. The lines that matter are the rest.</p>

<h2>Line two</h2>

<p><code>status → award.stage | lossy | program + finance | note: 7 source values, 5 targets. “Pending” collapses.</code></p>

<p>Here is the first real decision. The old system accumulated status values over years; the new one has its own set. Two source values are about to become one, which means a distinction your team relies on stops existing at the moment of load. That is sometimes fine. It is never fine to discover it afterwards. The owner column has two names in it deliberately: whoever answers this question alone will answer it wrong.</p>

<h2>Line three</h2>

<p><code>close_date → award.end_date | exact | finance | note: drives retention clock, verify against final report date</code></p>

<p>A date field that looks trivial and is not. The retention obligation attached to an award generally keys off the submission of the final report rather than the end of the performance period, so an archive holding only one of them leaves you unable to compute your own obligations. If the export carries just one, add a line for the report submission date and reconstruct it from correspondence.</p>

<h2>Line four</h2>

<p><code>cfda_number → award.assistance_listing | exact | finance | note: verify format against source posting</code></p>

<p>Federal identifiers change names and formats over time, and offices carry whatever convention was current when a record was created. Reconcile against the posting rather than your own copy. Opportunity records tracing back to <a href=“https://www.grants.gov/”>Grants.gov</a> can be checked directly, and a mismatched identifier is cheaper to fix now than during a report.</p>

<h2>Line five</h2>

<p><code>custom_field_14 → (none) | dropped | ??? | note: label “Site”, populated in most rows, unknown author</code></p>

<p>This is the line that decides whether your migration was careful. A custom field with hundreds of populated values, no obvious home in the new system, and nobody willing to claim it. The lazy resolution is to drop it and hope. The correct one is to put a name in the owner column before load, even if that person has to go and ask what “Site” meant. Fields like this are where institutional knowledge dies quietly.</p>

<h2>Line six</h2>

<p><code>attachments[] → documents | manual | operations | note: confirm files are in hand, not just filenames</code></p>

<p>The most important line in the map, and it is not really a field. Exports from any tracker may or may not include the document files themselves rather than pointers, so check before relying on it. If what you hold is a column of filenames, the documents have to come from wherever else they exist: email, shared drives, funder portals. Sort them into folders named by award identifier before anything else runs. Documents substantiating restricted spending are exactly what an examination would want to see, and the IRS material for <a href=“https://www.irs.gov/charities-non-profits”>charities and nonprofits</a> is a reasonable orientation point for a board asking why this step gets priority over the shiny new interface.</p>

<h2>Line seven</h2>

<p><code>change_log → (none) | archive as PDF per award | operations | note: accepted loss, approved by finance lead 2026-04</code></p>

<p>Change history rarely maps into a new platform as structured data. Flattening it to a dated document per award is a legitimate answer. Recording who approved that loss, and when, is what turns it from a gap into a decision. Every map should contain at least one line like this, written honestly.</p>

<p>Seven lines is not a map. A real one runs to several dozen and takes a working week. Skipping it does not remove the decisions, it only moves them to the moment of failure, which now arrives with no original system to consult. For the ordering that surrounds this artifact, <a href=“https://www.grantcue.com/blog/granthub-sunset-2026-migration-guide”>the full sequence</a> shows where the field map sits relative to the document pull and the reconciliation pass.</p>