Salesforce · CRM · Master data

Salesforce Account Data Migration

Migrate accounts into Salesforce, covering the account record, parent-child hierarchy, record types, ownership, external identifiers and the relationships that every other CRM object depends on.

Discuss Your Migration All Migration Objects

Object overview

Accounts are the top of the CRM graph. Contacts, opportunities, cases and activities all resolve to an account, which makes it the first object loaded and the one whose keys everything else depends on.

The defining technical decision is the External Id. Salesforce generates its own record Id on insert, so a load without an External Id field cannot be repeated — a second run creates duplicates rather than updating. Loading against an External Id makes every migration cycle idempotent, which is what makes multiple rehearsals survivable.

What data is typically migrated

Scope is agreed in discovery; this is the shape of the object.

Data area	Typical information
Account	Name, account number, type, industry, phone, website, description
Addresses	Billing and shipping address, with country and state picklist values
Hierarchy	Parent account relationships
Ownership	Owner user, which drives record visibility
RecordType	Which page layout, picklist values and processes apply
External identifiers	The legacy key carried into an External Id field
Custom fields	Org-specific extensions on the standard object

Object relationships

Dependency drives load sequence: a child cannot exist before its parent.

Account

└─ Parent account (self-referencing, second pass)

└─ Contact

└─ Opportunity

└─ Opportunity line item

└─ Case

└─ Activity

└─ Attachment / file

Object migration flow

Source Accounts→DataMove→Map & transform→Validate→Salesforce Accounts→DataVault reconciliation→Sign-off

Before you migrate this object

Confirm each of these before the first migration cycle.

□Users, roles and the sharing model are configured

□RecordTypes, page layouts and picklists exist

□An External Id field is created and indexed on Account

□Validation rules are reviewed and any that block migration are temporarily managed

□Duplicate rules are configured and the matching strategy is agreed

□The owner fallback rule is agreed

□Country and state picklist values are loaded if picklists are enabled

Common source systems

Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

Oracle Fusion CX SupportedMicrosoft Dynamics 365 SupportedSAP CRM SupportedOracle Siebel Custom mappingLegacy / spreadsheet Custom mapping

Source-to-target mapping examples

Object-level equivalence. Field-level mapping is produced per engagement.

Source system	Source entity	Target object
Oracle Fusion CX	Organization party	Salesforce Account
Dynamics 365	Account (Dataverse)	Salesforce Account
SAP CRM	Business Partner (sold-to role)	Salesforce Account

Migration methods for this object

Bulk API 2.0 for volume loads

Upsert against an External Id field so reloads update rather than duplicate

Data Loader or a managed migration pipeline for cycle execution

Extraction considerations

Parent hierarchy needs two passesA parent account has no Salesforce Id until it has itself been created, so hierarchy is extracted with the source parent key and applied after the population exists.

Ownership mappingOwner drives visibility in Salesforce. Source owners that have no target user need an explicit fallback decision, because an unmapped owner silently changes who can see the record.

RecordType determines validityA picklist value valid under one RecordType is rejected under another, so RecordType is extracted as part of the key rather than as an attribute.

Custom fields and formula fieldsFormula and rollup fields are calculated, not stored. They are recreated in the target rather than migrated, or the target inherits frozen values.

Transformation rules

Legacy key to External IdThe transformation that makes the migration repeatable. Every subsequent object resolves its account through this field.

Country and state picklistsWhere state and country picklists are enabled, free-text values are normalised to the configured picklist entries or the record is rejected.

Account type and industry crosswalksMapped to the picklist values valid for the assigned RecordType.

Owner resolutionSource owner to Salesforce user, with a documented fallback for unmatched owners.

DeduplicationMatched on normalised name, domain and address before load, because Salesforce duplicate rules will otherwise block or flag them at insert.

Data quality and validation

External Id uniqueness

Duplicates break upsert behaviour entirely.

Owner exists and is active

An inactive user cannot own records.

RecordType exists and is assigned to the loading profile

Otherwise the insert is rejected.

Picklist values valid for the RecordType

Including country and state where picklists are on.

Parent account resolves

In the second pass, every parent key maps to a loaded account.

Required fields per RecordType

Which differ by RecordType and validation rules.

Load sequence and dependencies

What has to exist before this object can load.

1Users and roles
2RecordTypes, picklists and page layouts
3Accounts (no parent)
4Parent hierarchy second pass
5Contacts
6Opportunities
7Cases and activities
8Files

Common migration errors

What actually fails on this object, and why.

Duplicate detected by Salesforce duplicate rulesThe insert is blocked or flagged, depending on configuration.

Invalid picklist value for RecordTypeThe value exists but is not available under that RecordType.

Owner not found or inactiveOwnership cannot be assigned.

Parent account not foundThe hierarchy pass ran before the parent existed.

Validation rule failureOrg-specific validation rules reject records that are otherwise structurally valid — a common surprise in the first cycle.

Required field missingPer RecordType and page layout configuration.

External Id not uniqueTwo source records mapped to the same key.

Reconciliation

Counts alone rarely prove this object migrated correctly.

Account count: source vs loaded, with agreed exclusions listed

Hierarchy completeness: parent relationships present after the second pass

Ownership distribution compared to source, including the fallback owner count

RecordType distribution compared to the expected split

Child object resolution: every contact and opportunity resolves to a loaded account

Duplicate merge log where deduplication was applied

How Syntra ETL supports this object

DataMove

Extraction, mapping, transformation, validation preparation and target load generation.

Explore DataMove →

DataVault

Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

Explore DataVault →

DataLens

Migration progress, data quality, exceptions and readiness across cycles.

Explore DataLens →

Relevant migration routes

Source-specific guidance for moving this object.

Salesforce→Oracle Fusion CX

Successfully delivered projects involving this object

Published case studies whose scope included accounts.

Salesforce→Oracle Fusion CX CloudGlobal US Software Company ($1B+ revenue)Enterprise Software · USA

$1B+ Customer annual revenue
CRM Customer & sales data migrated
Automated Source-to-target mapping

Successful migration to Oracle Fusion CX with auditable source-to-target reconciliation and reduced manual effort.MIGRATION COMPLETEView Project →

Frequently asked questions

Why does an External Id matter so much in a Salesforce migration?

Because Salesforce generates its own record Id on insert. Without an External Id to upsert against, a second load creates duplicates instead of updating, which makes multiple migration cycles impossible to run safely.

How is the account hierarchy loaded?

In a second pass. A parent account has no Salesforce Id until it has been created, so accounts load flat first and parent relationships are applied afterwards using the source parent key.

Why do records fail validation even though the data looks correct?

Org-specific validation rules. They are written for interactive users entering current data and frequently reject historical records that are perfectly valid. Reviewing and temporarily managing them is part of migration preparation.

What happens to formula and rollup fields?

They are not migrated. They are calculated in Salesforce, so they are recreated as formula or rollup fields in the target. Loading them as values produces frozen numbers that never update.

How is account ownership handled when the source user does not exist?

Through a documented fallback rule agreed before the load. Owner drives record visibility in Salesforce, so allowing it to default silently changes who can see what.

Planning a similar data migration?

Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

Discuss Your Migration Explore Migration Routes