How to migrate Salesforce data without losing field history

Migrating Salesforce data into a new org or a data platform without losing field history takes a deliberate plan, not a different tool. Salesforce's standard migration tools move current record data; field history moves only if you export it first and give it a home.

TL;DR

• Salesforce data loaders migrate current records, not field history — history needs its own export.
• Keep field history by exporting it before cutover and loading it into a staging object or your data platform.
• Without Field Audit Trail, Salesforce retains history on standard and custom objects for up to 18 months in the UI and 24 months via the API.
• Record audit fields like Created By are preserved with special data-loading permissions.
• Reconcile history row counts against the source before you retire the old org.

How do you migrate Salesforce data without losing field history?

The answer is a sequence, and the order matters:

1. Inventory history. What you do: List every object with Track Field History enabled. Why the order matters: You cannot export what you did not know was tracked.
2. Export history. What you do: Extract field history and audit trail data to CSV before cutover. Why the order matters: Standard migration tools cannot import native history records.
3. Choose a retention home. What you do: Staging objects, your data platform, or the source org itself. Why the order matters: History needs somewhere queryable to live.
4. Migrate current data. What you do: Load records with audit fields preserved. Why the order matters: Current data and history are loaded differently.
5. Reconcile. What you do: Compare history row counts source vs target. Why the order matters: A silent history gap is invisible until someone audits.
6. Retire or archive the source. What you do: Keep the old org read-only or rely on your exports. Why the order matters: The last copy of the audit trail should be verified, not assumed.

Each step, expanded:

Inventory what is tracked. In Setup, check field history settings per object. Most orgs track history on opportunities, cases, and key custom objects — but rarely on everything, and discovering the gaps after cutover is too late.

Export before you touch anything. Field history exports happen through the API or a data loader against the history objects (for example, OpportunityFieldHistory).

Choose the retention home deliberately. Three options work: load history into staging or custom "history" objects in the new org, land it in your Databricks or Snowflake environment alongside the migrated records, or keep the source org read-only as the archive. The right one depends on how often auditors actually query the old history.

Load current data with audit fields intact. When migrating records themselves, enable the special permissions (Set Audit Fields upon Record Creation) so Created Date, Created By, and Last Modified values survive the move. Without them, every record looks like it was born on migration day.

Reconcile counts, not vibes. Row counts per object, source versus target, is the minimum. Where they differ, find out why before the source org is decommissioned.

What Salesforce tracks — and for how long

Salesforce retains field history differently from most record data, and the limits shape your migration plan:

• Field history (standard and custom objects). Retention: Without Field Audit Trail, up to 18 months in the UI and 24 months via the API.
• Older field history. Retention: With Field Audit Trail, may move to FieldHistoryArchive, queryable via API.
• Standard data loaders. Retention: Migrate current records; export history separately.

These figures come from Salesforce's field history documentation and limits reference, checked against the Winter '26 release documentation. The practical consequence: a migration that waits until after cutover to "grab the history" is already working against retention windows.

Why field history gets lost in most migrations

Four failure patterns account for nearly every lost-history migration we see:

The tool assumption. Teams assume Data Loader or a migration app moves everything. It moves current records; history objects are separate.

The backup gap. Data export and backup are treated as an IT checkbox, not part of migration scope. If you are unsure what a backup actually covers, start with the differences between manual exports, the Data Export Service, and backup add-ons in our Salesforce data backup guide.

The audit-fields miss. Records arrive without original Created Date and Created By because the audit-field permission was never enabled, so even current data loses its provenance.

The decommission race. The old org is switched off to save license cost before anyone verified the history exports. Decommission dates and verification should be sequenced, not simultaneous.

Where the history should live: three patterns compared

• Load into the new org as staging/custom objects. Best for: Auditors who query inside Salesforce. Trade-off: Storage and object limits; clutter for users.
• Land in a lakehouse (Databricks, Snowflake). Best for: Compliance retention plus analytics reuse. Trade-off: Requires a governed data platform to be useful.
• Keep the source org read-only. Best for: Short retention needs, tight budgets. Trade-off: Ongoing license cost; does not age well.

If your team is already building a governed data foundation, option two usually wins: the history becomes queryable forever, and it feeds the same cleanup and deduplication work the migration already needs. Our data consulting team runs exactly this pattern — export, land, reconcile — during legacy migrations. If the migration is part of a larger systems change, our integration work covers how the moved data keeps flowing afterward.

A worked checklist you can run in a week

1. Day 1-2: Inventory tracked objects; confirm export access and API capacity.
2. Day 3-4: Export field history and audit data; store checksums and row counts.
3. Day 5: Load current records with audit fields; load history to its retention home.
4. Day 6: Reconcile per-object counts; spot-check the last 90 days of history against the source.
5. Day 7: Sign off. Only then schedule the source org's retirement.

The checklist compresses the work, but the sequence is what protects the audit trail: export before load, reconcile before retirement.

FAQ

Does Salesforce Data Loader migrate field history?

Not into native history objects. Standard loaders move current record data. Field history lives on separate history objects that you export and load deliberately, before cutover.

How long does Salesforce keep field history?

Without Field Audit Trail, Salesforce retains field history for up to 18 months in the UI and 24 months via the API. Export before cutover regardless of the window.

Can I preserve Created Date and Created By when migrating records?

Yes. Enable the audit-field permissions (Set Audit Fields upon Record Creation) in the target org before loading, or every migrated record will carry the migration date as its origin.

What is the safest place to keep migrated field history?

A governed data platform such as Databricks or Snowflake keeps it queryable indefinitely and reusable for analytics. Staging objects in the new org work for auditors who only search inside Salesforce.

Can I migrate history after the old org is decommissioned?

Only from a backup, if one exists. Once the org is retired with no export, the history is gone. Verify exports before scheduling decommissioning.

Does migrating field history count against Salesforce storage?

Yes. History loaded into staging or custom objects consumes the target org's data storage, which is one reason large history sets often land in a data platform instead.

Related guides

• Salesforce data backup options compared
• Data cleanup and migration services
• Integration work that starts with the data model
• More implementation field notes

One last thing

The cheapest field-history insurance in any Salesforce migration is a dated export file stored outside the platform — taken before the first record moves. Everything else in this guide is recoverable; a missing history export usually is not.

Migrations are one of the most common reasons teams end up on a Salesforce managed services plan — the post-migration backlog (validation rules, reporting fixes, new-hire requests) lands all at once. If you would rather talk through a migration scope with a person, book a meeting with SOLVD.cloud's team.