Data migration complexity: modern red-brick university building and plaza

What determines the complexity of a data engagement

Volume rarely governs data migration complexity; what the data must represent, and how many sources it comes from, usually does.

The complexity of a remediation or migration is set less by the number of records than by what those records must represent. A million contacts with a single source of truth and one deduplication rule present less difficulty than a few thousand contracts amended, co-termed and repriced across a decade. In the assessment our consultants therefore ask first what the data describes, and only then how much of it there is. At scale, volume sometimes matters too: for example, files, attachments and knowledge articles take time and storage to move, and records whose loading triggers code or automation might need to go through the ETL tooling in smaller batches.

The drivers of data migration complexity

The principal drivers, in approximate order of consequence:

  • Contracts and subscriptions, or orders and invoices. Where the target must hold contracts and subscriptions that renew, amend and calculate recurring revenue, every line must reconcile to what the customer was sold and billed. Where only orders and invoices are carried, the obligation is historical accuracy rather than forward behavior.
  • Product structure. The breadth of the catalog in use, whether legacy products map to current ones, and whether bundles, options and single-SKU bundles must be decomposed or reconstructed.
  • Pricing mechanics. Multi-year segments, ramp deals, tiered and usage pricing, uplift that varies by year, and discounts held inline or as separate SKUs.
  • Billing behavior. Billing frequency and schedules, and whether invoicing is driven from Salesforce, from the ERP or from a separate billing system; where it is the ERP, that determines what the two systems must agree upon.
  • Multiplicity of sources. Each additional instance or system contributes its own identifiers, conventions and duplicates, and requires rules that decide which source prevails.
  • The state of the data. Duplicate rates, missing keys, stale ownership, unreconciled addresses, and fields whose source and purpose are held in memory rather than documented.

Dependency and definitional agreement

Two properties cut across all of these. The first is dependency: an object whose records are consumed by automation, integrations or revenue calculations carries the consequence of every error downstream, and must be validated against those consumers as well as against its source. The second is definitional agreement: where RevOps, GTM, Finance and Business Systems hold different definitions of a customer, an amendment or a renewal, the data cannot be made consistent until the definitions are. Neither appears in a record count, and both are established in the assessment before any estimate is written.

What agents add

Where the work prepares data for AI agents, the agents in view also shape the complexity: each agent use case depends on its own set of Salesforce reference objects, and an agent traverses several related records in a single task. Our data experts focus remediation on the objects the target agents read, rather than on the entire org.

Assess the data before the agents depend upon it

The first call is with the practitioners who would do the work, not a sales intermediary. The measures come first and the estimate follows.

Talk to our experts