Salesforce Data Migration: A Practical Planning Checklist

Salesforce data migration is the controlled movement of business datainto, out of or between Salesforce environments. The technical import isonly one part of the work. A reliable migration must preserve meaning,relationships, ownership and trust.

That means answering difficult questions before selecting a migrationtool:

• Which information should move?
• Which system owns each record?
• How will duplicate and obsolete data be handled?
• How do source fields map to the new data model?
• In what order must related records be loaded?
• How will the business prove that the migration is complete andcorrect?
• What happens if the final cutover fails?

Salesforce's own migration guidance begins with planning, datapreparation and matching the source to the target schema. This practicalchecklist expands those principles into a complete business process. Salesforce:Data migration best practices

Start with thebusiness reason for migrating

Do not begin by exporting every available table.

First define why the migration is happening. Common reasonsinclude:

• Moving from a legacy CRM into Salesforce.
• Consolidating several Salesforce organisations.
• Separating data following a business sale or restructuring.
• Replacing Salesforce with another CRM or business platform.
• Combining CRM, sales, service or marketing information.
• Redesigning a poorly structured Salesforce implementation.

For each reason, define the expected outcome. The goal might be areliable customer view, better sales reporting, fewer duplicates or asimpler process for users. Those goals should determine the migrationscope and acceptance criteria.

“Move all the data” is not a useful objective. It hides decisionsthat will otherwise appear during testing or cutover.

Appoint owners beforetouching the data

Migration decisions belong to the business as well as the technicalteam.

Establish these responsibilities:

RoleMain responsibilityExecutive sponsorResolves priorities and accepts major business riskMigration leadCoordinates scope, mapping, test cycles and cutoverBusiness data ownersDecide which records are valid and how they should be usedSalesforce administrator or architectDefines the target data model, automation and securitySource-system specialistExplains fields, identifiers and historical behaviourIntegration specialistBuilds repeatable extraction, transformation and loadingprocessesSecurity or compliance representativeReviews privacy, retention and access requirementsBusiness testersValidate migrated records in real working scenarios

Every important dataset needs a named owner. If nobody can decidewhether an old customer record is still valid, the migration developershould not be expected to guess.

Decide what data shouldmigrate

Create a migration inventory before mapping fields.

Potential data categories include:

• Accounts and contacts.
• Leads and opportunities.
• Products, price books and related commercial data.
• Activities, tasks, events and communications.
• Cases, service history and entitlements.
• Campaigns and campaign members.
• Contracts, orders or quotations where used.
• Custom objects and their relationships.
• Notes, files and attachments.
• User, owner, territory and sharing references.
• Consent, preference and suppression records.
• Audit or historical information required for reporting.

For each category, choose one of four treatments:

1. Migrate: needed for current operations orreporting.
2. Archive: retained and accessible, but not loadedinto the new live system.
3. Transform or summarise: preserved in a more usefulor manageable form.
4. Dispose: removed under an approved retentionpolicy.

Record the reason and approving owner. Migrating years of unusedactivities may make the project slower and the new CRM harder to use.Removing history without legal and operational review can be equallydamaging.

Profile the source data

Do not assess data quality from a few familiar records. Profile thefull population.

Check:

• Record counts by object, source, status and date.
• Empty values in important fields.
• Invalid dates, email addresses, codes or identifiers.
• Inconsistent country, currency and language values.
• Duplicates and near-duplicates.
• Orphaned child records without a valid parent.
• Values that exceed target field lengths.
• Picklist values not available in the target.
• Inactive owners and queues.
• Files that are missing, duplicated or too large for the intendedprocess.
• Personal information that should not be migrated.
• Records changed after the initial extraction.

Produce a data-quality report and agree how each problem will behandled. This turns vague warnings about “dirty data” into measurablework.

Clean data with businessrules

Data cleansing is not simply correcting spelling. It often changeswhich records survive and how they are interpreted.

Define rules for:

• Selecting the surviving record when duplicates are merged.
• Combining non-conflicting fields from several sources.
• Treating missing mandatory values.
• Standardising names, addresses, telephone numbers and codes.
• Converting free text into controlled values.
• Closing or excluding obsolete records.
• Handling contacts linked to several organisations.
• Retaining the source identifier for traceability.
• Preserving consent and communication preferences.

Salesforce provides validation, duplicate-management and otherdata-quality capabilities, but ongoing quality also depends on training,monitoring and regular maintenance. SalesforceTrailhead: Plan for ongoing data management

Do not cleanse only in the target after import. Use a repeatabletransformation process so every test and production load applies thesame approved rules.

Define the targetSalesforce data model first

Migration cannot be finalised until the destination is stable enoughto receive the data.

Document:

• Standard and custom objects.
• Record types.
• Required and optional fields.
• Field types, lengths and formats.
• Picklists and dependent values.
• Parent-child and many-to-many relationships.
• Ownership and sharing rules.
• Validation rules.
• Duplicate and matching rules.
• Automated flows, triggers and other logic.
• External IDs and integration identifiers.
• Reporting requirements that depend on migrated history.

Salesforce advises that the target organisation should be configuredwith the required metadata, customisations and users before moving databetween organisations. Salesforce:Migrate data from one organisation to another

Freeze or tightly control relevant schema changes during the latertest cycles. Otherwise, a field mapping that worked last week may failat cutover.

Build a detailed mappingspecification

A mapping document should explain more than which source columncorresponds to which Salesforce field.

For each field, record:

Mapping detailExample questionSourceWhich system, object and field supplies the value?TargetWhich Salesforce object and field receives it?TransformationIs the value copied, combined, split, converted or calculated?ConditionDoes the mapping apply only to certain record types orstatuses?DefaultWhat happens when the source value is empty?ValidationWhich formats or values are acceptable?RelationshipWhich external identifier links this record to its parent?OwnershipHow is the Salesforce owner selected?ReconciliationHow will the mapped result be checked?

Include worked examples for complicated rules. “Map customer status”is vague. A table showing how every source status becomes an approvedSalesforce value is testable.

Keep the mapping under version control or another controlled changeprocess. Each revision should record the decision, owner and effect onearlier test results.

Preserve recordrelationships and load order

CRM data is relational. Accounts may own contacts and opportunities;opportunities may have products; cases may refer to contacts, assets orentitlements. Loading records in the wrong order can break thoserelationships.

A typical sequence might include:

1. Reference data and approved picklist values.
2. Users, queues and ownership structures.
3. Parent objects such as accounts.
4. Contacts and other children.
5. Opportunities, cases and related transactions.
6. Junction objects and detailed line records.
7. Activities, notes, files and historical data.

The actual order depends on the target model.

Retain a stable source identifier and map it to the new Salesforcerecord ID. Salesforce upsert operations can use an external ID to decidewhether a record should be inserted or updated, which is valuable forrepeatable migration cycles. SalesforceDevelopers: Bulk API create job

Never rely on names alone to recreate relationships. Names can changeand may not be unique.

Choose theright Salesforce data migration tools

The best tool depends on volume, complexity, repeatability, securityand the skills available.

Data Import Wizard

Salesforce's Data Import Wizard provides a guided way to prepare aCSV file, select the target data and map fields. It can be suitable forsupported, relatively straightforward imports. Salesforce:Import data with the Data Import Wizard

Before choosing it, confirm that it supports the objects, actions,matching behaviour and volume required by the project.

Data Loader

Salesforce Data Loader is a client application for bulk import andexport. It supports operations including insert, update, delete andexport, and works with CSV files or a database connection. SalesforceDevelopers: Data Loader

It can be useful when the project needs more control than a guidedwizard provides. Configuration, mappings and output logs should beretained as migration evidence.

Bulk API and scriptedmigration

Salesforce's Bulk APIs are designed for large datasets and supportoperations including insert, update, upsert and delete. A scripted orintegration-led approach can provide repeatability, transformation,logging and automation across several migration cycles. SalesforceDevelopers: Bulk API introduction

This route requires development and operational discipline. Theproject still needs mapping, validation and reconciliation; the API doesnot make those decisions.

Third-party migrationtools and services

Salesforce data migration services or specialist products may helpwith complex transformations, multiple sources, attachments, schedulingor monitoring. Evaluate them against the actual requirements.

Ask:

• Which Salesforce and source objects are supported?
• Can the process be repeated consistently?
• How are relationships and external IDs handled?
• What happens to rejected records?
• Where is migration data processed and stored?
• Can the team inspect the transformations and logs?
• Who supports the solution during cutover?
• How will you operate without the supplier afterwards?

Do not select a tool because it promises a one-click migration. Thedifficult work is deciding what the data means.

Control automation duringloading

Salesforce automation can affect migrated records. Validation rules,flows, triggers, assignment logic, duplicate rules, notifications andintegrations may reject records or create unintended side effects.

For each automation, decide whether it should:

• Run normally during migration.
• Be temporarily bypassed under an approved control.
• Be adjusted to recognise migration records.
• Run in a controlled process after the load.

Document every temporary change and how it will be restored. Test theload with the same automation state intended for production.

Do not disable controls casually. A faster import is not a successfulimport if it creates invalid records or sends thousands of unintendedmessages.

Protectpersonal and commercially sensitive data

Migration creates extracts, working files, error reports and backupsoutside the normal application. These copies can increase risk.

Define:

• Who may extract and handle each dataset.
• Secure transfer and storage methods.
• Whether sensitive fields should be masked in test environments.
• How access is logged and reviewed.
• How working files are retained and destroyed.
• Which legal or contractual restrictions apply.
• How data-subject preferences and suppression records arepreserved.

Use migration accounts with only the access they require. Removetemporary permissions and credentials after the project.

Run several test migrations

A production migration should not be the first complete run.

Use repeated test cycles to prove:

• Extraction and transformation are repeatable.
• Mappings produce the intended business meaning.
• Relationships are preserved.
• Load sequencing works.
• Volumes can be processed in the available window.
• Errors can be corrected and reloaded safely.
• Users can find and use the information.
• Reports produce credible results.
• Integrations recognise the migrated records correctly.

Begin with a representative sample, including difficult records andexceptions. Then perform at least one full-volume rehearsal in anappropriate non-production environment where practical.

Record the duration of every stage. A test on a few clean accountscannot predict how long files, activities or millions of related recordswill take.

Reconcile the migration

An import job completing successfully does not prove that themigration is correct.

Create a reconciliation pack containing:

• Source, transformed and target record counts.
• Counts by status, type, owner, region or other importantcategory.
• Control totals such as opportunity values or active casenumbers.
• Duplicate and exclusion counts.
• Rejected records and their eventual treatment.
• Samples traced from source to target.
• Relationship checks for orphaned records.
• Reports compared with agreed source reports.
• Business-owner approval.

Reconciliation should explain every difference. If 100,000 recordswere extracted and 98,400 loaded, the remaining 1,600 must bedeliberately excluded, consolidated, rejected and corrected, orotherwise accounted for.

Prepare the cutover plan

The final migration is a business change, not just a technical batchjob.

The cutover plan should state:

• The final source-data freeze or change-capture method.
• Who may continue working and which transactions require temporaryhandling.
• The extraction, transformation and load sequence.
• Expected duration and checkpoints.
• Responsibility for each step.
• Communications to users and connected teams.
• Final reconciliation and approval.
• The decision point for proceeding or stopping.
• The rollback or recovery plan.
• When integrations and automation are enabled.
• How access to the old system changes after launch.

Rehearse the plan and maintain a runbook. During cutover, peopleshould follow agreed steps rather than inventing solutions underpressure.

Keep the legacysystem available appropriately

Not all history needs to live in the new CRM. Some may be retained ina secure archive or read-only legacy system.

Define:

• Who can access historical records.
• How quickly information must be retrieved.
• How long the legacy environment will operate.
• Who maintains its security and backups.
• How legal retention and deletion will be handled.
• Whether reports need information from both old and new systems.
• The eventual retirement criteria.

An undefined “temporary” legacy system can remain expensive and riskyfor years.

HubSpotand Salesforce migrations need separate mapping decisions

HubSpot-to-Salesforce and Salesforce-to-HubSpot migrations are notmirror images. Each platform has its own data model, lifecycle concepts,ownership rules, marketing history and automation.

Do not assume that every object or activity has an exact equivalent.First decide:

• Which platform will become authoritative for companies, contacts,leads and deals or opportunities.
• How lifecycle stages and sales stages correspond.
• Which activities and engagement history are genuinely needed.
• How marketing consent and suppression data will be preserved.
• Which workflows or integrations must be rebuilt rather thanmigrated.
• How duplicate contacts and companies will be resolved.

This article's planning and control principles still apply, but adetailed HubSpot migration deserves its own platform-specificspecification.

SalesforceClassic to Lightning is not simply a data migration

Moving users from Salesforce Classic to Lightning Experience isprimarily an experience, configuration, feature and adoption transition.Much of the underlying Salesforce data may remain in the sameorganisation.

Some specific features can involve migration work—for example,Salesforce provides a dedicated tool for moving Classic Knowledgecontent into Lightning Knowledge. Salesforce:Lightning Knowledge Migration Tool

Treat the wider Classic-to-Lightning project separately. Assesspages, customisations, buttons, integrations, user processes, trainingand feature compatibility rather than assuming it belongs inside ageneral data-load plan.

Questions toask a Salesforce migration consultant

Before appointing a consultant or Salesforce data migration service,ask:

• How will you help us decide what should not migrate?
• Who owns the mapping specification?
• How do you preserve relationships and source identifiers?
• How many test cycles are included?
• How will rejected records be corrected and reloaded?
• What reconciliation evidence will you provide?
• How do you protect extracts and test data?
• How will automation and integrations be controlled?
• What is included in cutover and post-launch support?
• Can our team repeat or audit the process without you?
• What assumptions could change the cost or timetable?

Be cautious if a proposal is based mainly on record count. Complexityoften comes from relationships, data quality, automation and businessrules—not only volume.

A practicalSalesforce data migration checklist

Strategy and governance

• Business reason and measurableoutcomes agreed.
• Migration scopeapproved.
• Data owners and decision-makersnamed.
• Retention, archive and disposalrules approved.
• Security and compliance requirementsdocumented.

Discovery and design

• Source systems and datasetsinventoried.
• Data quality profiled across thefull population.
• Target Salesforce model sufficientlystable.
• Field and value mappingsapproved.
• Relationships and load orderdocumented.
• External IDs and traceabilityapproach defined.

Build and testing

• Repeatable extraction andtransformation process created.
• Migration tool selected againstrequirements.
• Automation and validation behaviouragreed.
• Representative sample migrationcompleted.
• Full-volume rehearsal completedwhere appropriate.
• Errors can be corrected andreprocessed safely.
• Business users have tested realisticscenarios.

Reconciliation and cutover

• Record counts and control totalsagreed.
• All exclusions and rejected recordsaccounted for.
• Cutover runbookrehearsed.
• Data freeze or change-capture methodagreed.
• Go/no-go authority and rollback plandefined.
• Final business sign-offdocumented.
• Legacy access and retirement planagreed.

After launch

• Temporary permissions and filesremoved.
• Data-quality monitoringassigned.
• User issues and duplicate creationreviewed.
• Integrations and reportsmonitored.
• Remaining legacy dependenciestracked to closure.

Designing futuremigrations differently

Many migration difficulties arise because business logic, datastructures and interfaces have grown without a clear shared model. Everyreplacement then requires extensive interpretation and rebuilding.

Sevenlake is exploring a metadata-driven platform for ERP, CRM andcustom business applications. Its planned direction includes structuredapplication definitions, data import and export, API-basedinteroperability and reusable modules. The aim is to make businesssoftware more adaptable and data movement less dependent on opaque,one-off implementations.

Sevenlake is currently at the vision and architecture stage, movingtowards a proof of concept. It is not a production-ready Salesforcereplacement, and no Salesforce connector should be assumed to exist. Theimmediate opportunity for consultants and developers is to follow thework and contribute practical experience about data ownership, migrationand interoperability.

Migrate meaning, not justrecords

A reliable Salesforce data migration begins before the first exportand finishes after users trust the new system.

Decide what the business needs, assign owners and profile the realdata. Define the target model and mappings. Preserve relationships withstable identifiers. Test repeatedly, reconcile every difference andrehearse the cutover.

The tool matters, but it cannot decide which record is correct, whata field means or whether the migrated process works. Those decisionsrequire business knowledge, technical discipline and clearresponsibility.

If you are a consultant interested in building more adaptable andinteroperable business software, register your interest inSevenlake's planned partner ecosystem and follow the platform'sdevelopment.