Consolidating multiple Salesforce instances

Consolidation follows acquisitions, regional autonomy that has run its course, or a decision to retire a secondary org. Moving records between orgs is the mechanical part, and Salesforce's data import guidance covers loading them. The substance lies in deciding, for every object, which source prevails when the same customer, contact or product appears in more than one, and in reconciling the different ways each org represents the same commercial reality.

Questions before consolidating Salesforce orgs

The questions answered for each source before mapping begins:

• Is the account hierarchy consistent across instances, and how will parent accounts be matched where names, domains and addresses differ?
• By what criteria will accounts, contacts and users be deduplicated across instances, and which instance's record survives a match?
• Which field values survive when matched records disagree: the most recent, the most complete, or the value from a designated source?
• Is there a data steward in each source who can answer for its conventions and approve its rules?
• Do the sales models differ, direct against channel or annual against multi-year, such that stages, contract terms or renewal logic must be transformed?
• Are users common across instances, and how will duplicate and inactive owners be resolved?

Verifying a Salesforce org merge

Every org brings its own conventions, and consolidation retires them. Legacy identifiers are carried from every source, so that each consolidated record can be traced to each of its origins, and picklist values, record types and stage definitions are mapped to the single set the consolidated org will use. The result is verified per source as well as in aggregate.