Published May 19, 2026 · By EKE Services

Salesforce Org Consolidation: 380K Records, 47K Files in 3 Weekends

Two Salesforce orgs, one company. After an acquisition closed, the combined business needed a single source of truth for sales, support, and reporting — without losing data, breaking parent-child relationships, or stalling business operations. Here's how the consolidation came together over three production weekends, what made it harder than it looked on paper, and the numbers at the end.

The setup

A multi-business-unit company with two Salesforce orgs — one inherited from a recent acquisition, the other the acquirer's original instance. Both were Enterprise Edition. Leadership wanted a single org going forward, with full historical data preserved and the cutover finished inside three production weekends to avoid disrupting quarterly reporting.

• Org A (acquirer, target) — approximately 280K records, around 28K files, Enterprise Edition.
• Org B (acquired, source) — approximately 100K records, around 19K files, Enterprise Edition.
• Goal — merge Org B into Org A with no data loss, no broken parent-child relationships, and business cutover completed inside three weekends.

What made it hard

On paper a two-org merger sounds like a straightforward export-import. In practice four things made it considerably more work than a generic data load:

• Different field schemas on Account and Contact. Org B had custom fields the acquirer's org didn't have — industry-specific attributes that the business needed to keep. Some had to be created in Org A; others needed to map to existing fields with different names.
• Four levels of master-detail relationships. Custom objects in Org B chained four deep, which meant records had to be migrated in strict dependency order with External Id mappings preserved at each level, or the child inserts would fail.
• Approximately 340 files with broken legacy Attachment metadata. Inherited from years of partial migrations and integrations, these had missing or invalid ParentId values and needed manual triage before they could be moved.
• A stakeholder requirement for per-record reconciliation reporting. Finance and compliance wanted a row-level CSV at completion showing the source Id, target Id, and migration status for every record — not just summary counts.

The approach

The consolidation broke into three phases, each scoped to one production weekend so the business had a clean rollback point if anything went wrong.

Phase 1 — Schema reconciliation (pre-cutover week)

Before any records moved, we used Salesforce Data Migration to compare schemas between the two orgs, identify fields that existed in Org B but not Org A, and generate the metadata to create the missing fields in the target. This included custom fields, picklist values, and field-level security settings. Done as a pre-cutover step so the schema work could be reviewed, tested in a sandbox, and approved before any production change.

Phase 2 — Record migration in dependency order (weekends 1 and 2)

Approximately 380K records moved across the first two weekends in strict dependency order: Account → Contact → Opportunity → Custom Objects (top-level) → Custom Objects (child records, four levels deep). Every record was inserted with the source-org Id stored on an External Id field in the target, so later phases could resolve relationships by reference. Reconciliation queries ran after each object completed.

Phase 3 — File migration (weekend 3)

Files moved last, once all parent records existed in the target. Around 47K files — a mix of modern ContentDocuments and legacy Attachments — were migrated using Salesforce File Migration. Because parent Ids in the target were now known (from the External Id map built in Phase 2), the file tool could relink every file to its correct new parent automatically, preserving sharing visibility and link types.

The numbers

Final reconciliation, end-to-end:

• 380K records migrated — 0 lost in reconciliation.
• 47K files migrated — 12 errored (oversized binaries handled manually after the load).
• 99.97% success rate end-to-end across records and files combined.
• 3 weekends from kickoff to cutover — compared with the 6–8 week estimate from manual approaches the team had previously evaluated.
• Per-record CSV report delivered to stakeholders at completion, with source Id, target Id, object type, and status for every row.

The 12 file failures were all oversized binaries that exceeded transfer limits and needed a different upload path. They were re-loaded manually the same week.

What we'd do differently

A few things would have made the weekends calmer if we'd done them sooner:

• Run an inventory pass earlier. The 340 broken-metadata files surfaced mid-Phase 3 and needed triage in real time. A pre-cutover inventory would have caught them weeks earlier. See how to count all attachments and ContentDocuments in your Salesforce org for the SOQL we now run upfront.
• Set storage limits ahead of file load. The target org came within a few hundred megabytes of its file storage cap during Phase 3. Confirming and, if needed, expanding storage entitlement before the cutover would have removed a source of weekend anxiety. See Salesforce storage limits explained.
• Pre-stage the External Id mapping spreadsheet a week earlier. The map of source-org Ids to target-org Ids was finalized the day before Phase 2 kicked off. Doing that a full week earlier would have given QA more time to spot-check the mappings against business expectations.