Contact
Privacy
Legal Notice - Impressum
Career
News
A Salesforce data migration becomes significantly more challenging when projects encounter areas such as Chatter feeds, files, person accounts, big objects, CPQ records, and field history. Each carries structural rules that simple extract-and-load cannot deliver. Moving them safely requires object-specific logic, not a generic pipeline.
Most Salesforce migration projects go fine until they reach the objects with added complexity. Accounts, contacts, and opportunities may move through without incident then the project hits Chatter, or a file library running several terabytes, or a CPQ quote structure with dependency chains four levels deep, and the migration stalls.
These objects do not fail because the tool is weak. They fail because they are sObjects that do not fit the simple, mutable model generic tools are built around. They carry version histories, immutability rules, dual-object structures, and API restrictions that a generic extract-transform-load pipeline is not designed to handle.
This article identifies the six areas that most often challenge a Salesforce complex object data migration, explains the technical reason each one resists standard handling, and outlines how conemis transition cloud (ctc) moves them without delays while maintaining data integrity.
Standard migration projects assume records are stored in single SObject, or sObjects with clean relationships. That assumption holds for the core CRM objects and requires additional handling for objects that carry structural complexity beyond the simple sObject model. A complex object carries at least one property the standard model does not account for: a record cannot be updated after creation, a child record depends on three or four ancestors resolving first, history sits in a system table the API exposes differently, or the object is metadata rather than data.
When a tool built for flat sObjects meets one of these, the loading will go wrong. It fails outright, or it loads the records while the version history, associations, or audit trail around them never arrive. The second outcome is the dangerous one, because the migration looks complete until someone opens a record and finds the history, the file version, or the feed context missing. A reliable Salesforce migration treats these objects as distinct problems, each with its own extraction, transformation and load logic.
These six object families account for the most common friction points in migrations. Each fails for a different structural reason.
Chatter records resist migration because their meaning lives in associations, not in the records themselves. FeedItem and FeedComment objects each reference a parent record, an author, mentioned users, and often an attached file. Export the FeedItem in isolation and you get a row of text with broken pointers: the parent ID belongs to the source org, the author ID no longer resolves, and the @mentions reference users that may not exist in the target. Salesforce provides no standard migration path for feed data, so a generic tool requires extensive manual reference mapping across multiple sequential operations, with high risk of broken associations at scale.
ctc migrates Chatter by resolving every reference against the target org first, remapping parent records, authors, and mentioned users, then loading FeedItems and FeedComments with their associations intact and their original timestamps preserved. See how this was delivered for a global media and entertainment company.
File migration is another challenge for standard tools because a file in Salesforce is not one record. A single document is a ContentDocument with one or more ContentVersion records beneath it, plus sharing rules, ownership, and link associations to every record it is attached to. A flat export captures the latest version and discards the history, the sharing model, and the links. At enterprise volume, the problem compounds: a library of several terabytes pushes against API limits and storage timing in ways a generic loader requires manual management of API limits and sequencing.
ctc migrates files by preserving the full ContentVersion chain, carrying ownership and sharing logic, reattaching documents to their related records, and sequencing large transfers to stay within platform limits.
Person Accounts are difficult because a single Person Account exists as an Account record, and a Contact record bound together. Standard tools treat Account and Contact as separate objects and migrate them independently, which splits a Person Account into two disconnected records or creates duplicates. The migration also has to respect whether the target org has Person Accounts enabled and how its record types are configured.
ctc handles Person Accounts by recognizing the dual structure during extraction, mapping the paired records as a single unit, and loading them in the sequence the target org's configuration requires.
Big Objects resist migration because they cannot be updated or deleted. They are built for high-volume, archival data, and the platform enforces an append-only model: once a record is written, it is immutable. A standard tool's error handling assumes it can retry, update, or roll back a failed load. None of that applies here. A failed Big Object load cannot be corrected in place, only added to.
ctc migrates Big Objects by validating and mapping records fully before any load, then writing them in correctly sequenced batches, because with an immutable object the only safe load is one that is right the first time.
CPQ migration, now part of Agentforce Revenue Management, is challenging because of dependency depth. A quote is not a single record. It sits on top of quote lines, product options, bundle structures, price rules, and discount schedules, and each layer references the one beneath it. Load the records in the wrong order and the references fail; load them without preserving the bundle logic, and the quote calculates incorrectly.
ctc migrates CPQ data by mapping the full dependency graph first, then loading each layer in the order the structure requires so that quotes, bundles, and pricing behave in the target org exactly as they should. ctc can either replicate the same structure from the source or transform it into a new one in the destination.
Field history challenges migrations because Salesforce stores it in system-managed tables that cannot be written to directly. History Tracking objects record every tracked field change, but they are subject to retention limits and Salesforce offers no standard way to migrate them into a target org. A generic tool has no native path for history data, leaving the audit trail behind. For organizations under regulatory or audit obligations, that is a compliance gap, not a cosmetic one.
History data can be extracted and preserved for archival purposes before migration. Contact the conemis team to understand the options for your specific compliance requirements.
A complex object data migration controls this by sequencing the full object set in advance:
ctc maps the load order across all objects together, simple and complex, runs the parallelizable work in parallel and the dependent work in the correct sequence, and can execute a cutover plan whose timeline reflects the objects the migration will actually move, not just the easy ones.
Plan a complex object migration by inventorying the complex objects, before the project timeline is fixed. If they surface mid-project, when the timeline and budget are set, each one adds work that a generic estimate did not account for, which makes it impossible to meet the go-live date.
A disciplined Salesforce migration starts with a full object inventory: identify which of these six families are present, assess the volume and configuration of each, and scope the object-specific logic each one needs before committing to a go-live date.
The migration tool matters here. A tool scoped for standard sObjects handles the straightforward majority and stalls on the objects that carry the most risk. ctc is built to migrate the full object range, standard and complex, in a single managed process, which is what keeps a complex object data migration on schedule rather than discovering its hardest work halfway through.
The objects that challenge generic data migration tools are also the ones that carry a migration's real risk: the audit trail, the document history, the quote logic a sales team depends on. ctc is built to migrate the full range of Salesforce objects, in one managed process.
To scope a complex object data migration for your org: