Salesforce Data Migration Checklist for Migrating From Another CRM Without Losing Activity History
- Salesforce Managed Services
Most CRM migrations succeed at the part everyone watches and fail at the part nobody checks. Accounts land. Contacts land. Open pipeline lands. Then a rep opens an account she has worked for six years, sees a timeline starting on go-live day, and quietly goes back to the old system for anything that matters.
Activity history is the hardest part of a CRM move and the least discussed. It carries the highest record volume in the project, depends on relationships that must exist before it loads, points at users who may have left the company, and touches fields Salesforce protects by default. None of that makes history impossible to move. All of it has to be decided before anyone opens Data Loader.
This Salesforce data migration checklist is built around that specific problem. It covers the full move from another CRM into Salesforce, and at every phase it calls out what history preservation demands that a standard record migration does not. We have run these projects for teams leaving HubSpot, Microsoft Dynamics, Zendesk, Freshdesk, Oracle, and homegrown systems. The pattern holds: the ones that kept their history planned for it in week one, and the ones that lost it found the gap in user acceptance testing with nine days left.
TL;DR
The Migration Layer Nobody Budgets For
Moving from another CRM into Salesforce reliably transfers accounts, contacts, and open pipeline. Activity history behaves differently. Audit fields overwrite themselves, tasks lose their parent records, and attachments travel as a separate object entirely, so years of customer conversation quietly fail to arrive.
The Calls You Have to Make in Week One
The hard decisions come early: how far back to keep activity, whether to recreate departed owners, and how to prove the timeline actually survived. Get those wrong and users open a familiar account, see nothing before go-live, and drift back to the old system.
Seven Phases That Protect the Timeline
This Salesforce data migration checklist runs seven phases, from history scoping through cutover and the first 90 days. It covers audit field permissions, legacy ID fields, load sequencing, and a twenty-record timeline test that proves history arrived usable rather than merely counted.
What "Activity History" Actually Means When You Leave Your Old CRM
Ask five stakeholders what activity history is and you will get five different answers. Any useful Salesforce data migration checklist starts by settling that, because the definition sets scope, budget, and the load window. In practice, history that users care about lives in four layers, and each lands somewhere different in Salesforce.
History Layer | What It Holds | Where It Lands in Salesforce | Common Failure |
Timeline activity | Calls, meetings, logged notes, completed to-dos | Task and Event records | Activities load with no parent, so they never appear on the account |
Email and messaging | Sent and received email, chat transcripts, case correspondence | EmailMessage, Task, or Case Comment | Bodies exceed field limits or threading is lost |
Documents | Proposals, contracts, signed orders, screenshots | ContentVersion and ContentDocumentLink | Files import unlinked and sit in a library nobody opens |
Audit trail | Who created a record and when, stage change dates, ownership | CreatedDate, CreatedById, LastModifiedDate, custom date fields | Every record shows the migration date and the migration user |
The fourth layer surprises people. Even when tasks and emails migrate perfectly, a database where every account was created on March 14 destroys tenure reporting, cohort analysis, and any measure of sales cycle length across the boundary. Leadership notices within a quarter.
Why the Timeline Is the Part Reps Notice First
Sales and service users do not audit your field map. They open one record they know well and scroll. If the last eighteen months of conversation is there, they trust the system. If it is missing, adoption stalls and they keep a browser tab pointed at the old CRM, which quietly recreates the fragmentation the migration was supposed to end. So treat timeline completeness as an acceptance criterion with a number attached. A useful target: for the top 50 accounts by revenue, every activity inside the retention window appears on the right parent record, with the right original owner and date.
Why Most CRM Migrations Lose History, and Why It Surfaces Late
Understanding the failure modes makes the rest of this Salesforce data migration checklist much easier to follow, because nearly every item below exists to prevent one of these five problems.
Audit fields silently overwrite. By default Salesforce stamps CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById itself, so unless a specific org-level setting and permission are enabled, your 2019 opportunity shows as created today by the integration user. Salesforce documents this under the Set Audit Fields upon Record Creation permission. It has to be switched on before the first production load, because those values cannot be edited afterward.
Activities load without parents. Tasks and Events connect to the rest of Salesforce through two polymorphic fields: WhoId, a Contact or Lead, and WhatId, an Account, Opportunity, Case, or custom object. When those IDs are blank or wrong, the activity exists, is searchable, and appears on no timeline at all. The related lists users actually look at are read-only derived views. The ActivityHistory object shows past events and closed tasks, OpenActivity shows future events and open tasks, and neither can be written to directly. You populate both by loading Task and Event records correctly, which means the parent IDs have to be right the first time.
Historical owners no longer exist. Five years of activity is attributed to people, and some have left. Creating them as active users consumes licenses. Skipping them hands a decade of relationship history to whoever ran the load. The middle path takes planning, and Phase 3 covers it.
Files and notes are a separate migration. Legacy attachments and notes do not travel with the record. They are their own objects, they consume file storage rather than data storage, and each needs an explicit link back to its parent. Teams routinely scope this in the final week.
History gets deferred and then dropped. The common pattern: history is labeled “phase two” to protect the go-live date, the budget rolls into support, and phase two never happens. If history matters, it belongs in the first release.
How to Use This Salesforce Data Migration Checklist
Work the phases in order. Sequencing is the point, because much of all history loss traces back to doing a correct step at the wrong time. Three ground rules first:
- Assign one accountable data owner per source object. Not a committee. A named person who can decide what stays, what gets archived, and what gets dropped.
- Write decisions down as you make them. The version of the field map that reaches production should be reviewable by someone who was not in the room.
- Treat every rehearsal as a full rehearsal. A dry run that skips activities proves nothing, because activities are where the failures cluster.
Phase 1: Discovery and History Scoping Checklist
The opening phase of the Salesforce data migration checklist decides what you are moving. Every hour spent here removes several from later phases.
Inventory Every Object That Carries a Timestamp
Export a record count and date range for each source object, not just the ones on the project brief. The list usually looks like this:
- Companies, people, and deals or tickets
- Logged calls, meetings, and tasks
- Email records, inbound and outbound
- Notes and comment threads
- Attachments and files, with total file size
- Custom date fields such as first contact date, contract start, or renewal date
- Stage or status change logs, if the source keeps them
- Deleted and merged records, which sometimes still carry activity
That last item matters more than it looks. Many CRMs keep activity attached to merged-away records, so exporting only the survivors can lose years of conversation without a single error appearing in a log.
Decide the Retention Horizon Before the Field Map
Not all history deserves to move. Ask a plain question for each object: what is the oldest record a user would realistically open?
For most B2B sales teams the honest answer is three to five years for activities, longer for closed-won opportunities and contract dates. Regulated industries and long-cycle capital sales run further back. Set the horizon deliberately, since it drives volume, cost, and load duration for everything that follows.
Retention is also a compliance decision. Under the storage limitation principle in Article 5 of the GDPR, personal data should be kept in identifiable form no longer than is necessary for the purpose it was collected for. A migration is a natural moment to apply a retention policy rather than copy fifteen years of contact behavior into a new platform by default. Teams without a retention schedule should write a short one now, because the alternative is inheriting the problem into a cleaner system. A formal approach to Salesforce data governance pays for itself here rather than after go-live.
Size the Load Honestly
Two numbers drive the technical plan: record count and storage consumption.
Salesforce counts most standard and custom records at roughly 2 KB each regardless of field count, with documented exceptions such as Person Accounts, Campaigns, and email messages, which consume their actual size. The per-record storage figures are published in Salesforce Help. Tasks and Events count against data storage like anything else, so 4 million historical activities is real consumption worth calculating before you commit to a retention horizon.
Throughput is the second number. High-volume loads run through Bulk API 2.0, and Salesforce documents the limits and allocations for Bulk API ingest jobs at up to 150 million records per rolling 24-hour period. That ceiling is rarely the constraint. Your load window is set by parent-child dependency, record locking, and how much automation you leave running.
Discovery Questions to Answer Before Anyone Opens a Field Map
- Which source objects hold history a user would open in the next 12 months?
- What is the retention horizon per object, and who approved it?
- How many activity records fall inside that horizon?
- How many historical owners are involved, and how many still work here?
- What is the total file size of attachments in scope?
- Does any of this carry regulatory constraints on retention or residency?
- What is the acceptable business downtime for cutover?
Phase 2: Data Model and Field Mapping Checklist
Mapping is where a migration becomes either straightforward or expensive. This part of the Salesforce data migration checklist follows dependency order, and working it in sequence prevents most rework.
Map People and Companies First, Then Everything They Touched
Activities cannot be linked until their parents exist and their Salesforce IDs are known, so the mapping sequence runs Accounts, then Contacts and Leads, then Opportunities and Cases, then Activities, then Files. Source CRMs model the world differently, and the translation is rarely one to one.
Source Concept | Typical Salesforce Landing | Watch Out For |
HubSpot Company and Contact | Account and Contact | Contacts with no company need an account strategy, individual or bucket |
HubSpot Deal with pipeline stages | Opportunity with stage values | Stage histories and close date changes are not native fields |
Dynamics Account, Contact, Lead | Same names, different behavior | Dynamics allows contact without parent account far more freely |
Zendesk or Freshdesk Ticket | Case | Ticket comments split between public and internal, mapping to different objects |
Ticket requester | Contact, plus Account | Requesters often exist only as an email address |
Oracle or SAP customer master | Account, sometimes a hierarchy | Legacy IDs must survive to keep ERP integration working |
Any CRM’s activity log | Task and Event | Calls, notes, and to-dos may all be one object in the source |
Object-level translation deserves its own working session per platform. We keep detailed mapping patterns for HubSpot to Salesforce migration, Microsoft Dynamics to Salesforce migration, and Oracle to Salesforce data migration because each source stores conversation history its own way.
Create the Legacy ID Field That Makes Everything Else Possible
On every migrated object, add a text field marked External ID and Unique, populated with the primary key from the source system.
This one decision solves several problems. You can load parents and children in separate passes and still resolve relationships because a parent is referenced by its legacy ID instead of a Salesforce ID you do not have yet. Loads become idempotent, so a failed batch reruns with upsert rather than creating duplicates. Validation gets a reconciliation key. And support can answer, “Where did this record come from?” two years later.
Skipping the legacy ID field is the most expensive shortcut in CRM migration work, and it is almost always taken to save an afternoon.
Map Activity Types Without Inventing New Ones
Most source CRMs collapse calls, emails, meetings, and notes into one activity table with a type column. Salesforce splits them across Task and Event, with Type and Subject carrying the detail.
- Anything with a start and end time becomes an Event. Anything else becomes a Task.
- Completed historical activity loads as a Task with a closed status, so it lands in the activity history view instead of sitting in the open activity list forever.
- Preserve the original date in ActivityDate and the original creation timestamp in CreatedDate. Different fields, different questions.
- Keep the source type value in a custom field. It costs almost nothing and settles arguments during validation.
- Do not build a custom activity object to keep things clean. Custom objects do not appear in the standard timeline, which is the exact thing users are looking for.
Handle Picklists, Owners, and Statuses Before the Dry Run
Build three translation tables and treat them as deliverables:
- Picklist mapping. Every source value maps to a target value or to an explicit “do not migrate” decision. Uncontrolled values arriving through the API are a leading cause of unusable reports later.
- Owner mapping. Every source user ID maps to a Salesforce user ID, departed staff included. Phase 3 covers how to handle the ones who are gone.
- Status and stage mapping. Closed states especially. A closed-lost opportunity that arrives in an open stage inflates pipeline on day one and costs you the room’s trust in the numbers.
Phase 3: Environment Preparation Checklist
The environment section of a Salesforce data migration checklist exists for one reason: the target org has to be ready to accept history, and out of the box it is not.
Turn On the Permissions That Preserve History
Two org-level settings are enabled in Setup under User Interface, then granted by permission set to the migration user only:
- Set Audit Fields upon Record Creation, which allows CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById to be written on insert through API tools.
- Update Records with Inactive Owners, which allows records to be assigned to deactivated users.
Two constraints matter. Audit fields can only be set at creation, so a load that runs without the permission has to be deleted and reloaded rather than updated. And the permission belongs in a dedicated permission set on the integration user, removed after cutover. It is a migration tool, not a standing capability.
Recreate Legacy Users Before Loading Anything
Historical activity is only meaningful if it is attributed correctly. The workable pattern:
- Create a user record for every historical owner in the source system.
- Activate them temporarily, or load with the inactive-owner permission enabled, depending on your license position.
- Load all historical data with correct ownership and audit attribution.
- Deactivate departed users after validation. Deactivating a user does not remove their name from records they own or created.
- Reassign any open records they still own to a live user, leaving closed history untouched.
This is the difference between a timeline that reads like a relationship and one that reads like a database import.
Switch Off What Will Fight the Load
Before a production load, disable or bypass:
- Validation rules historical data cannot satisfy, since a 2020 record will not carry fields your 2026 process requires
- Record-triggered flows, process builders, and Apex triggers that fire on insert
- Workflow rules, email alerts, and outbound messages, because nobody should get automated mail about a five-year-old task
- Assignment and auto-response rules for Leads and Cases
- Duplicate rules, which block legitimate historical records and slow the load badly
- Roll-up summary recalculation where the design allows it
- Chatter feed tracking on migrated objects, which generates enormous noise
Document every item you switch off and the exact order it comes back on. That list belongs in the rollback plan, because a migration that leaves automation disabled is its own kind of outage. A structured Salesforce health check before the load is the fastest way to find automation nobody remembers building, and it is worth running on any org live for more than a year.
Protect Against Ownership Skew and Locking
Two performance issues cause more failed load windows than volume does.
Ownership skew happens when one user owns a very large number of records, making sharing recalculation expensive. Historical migrations create it constantly, since departed reps and generic house-account users end up owning hundreds of thousands of records. Spread ownership where the business allows it, and plan longer recalculation windows where it does not.
Record locking happens when parallel batches update the same parent at once. Loading 200,000 tasks pointed at the same handful of large accounts will produce lock errors unless the file is sorted by parent so related records land in the same batch. It is a small step with a large effect on throughput.
Phase 4: Load Sequencing Checklist
Sequencing is the shortest part of this Salesforce data migration checklist and the least forgiving, because a step taken early cannot be undone cheaply.
The Order That Keeps Relationships Intact
- Users and permission setup
- Reference and configuration data, including price books, products, and record types
- Accounts, including parent-child hierarchies in two passes
- Contacts and Leads
- Opportunities, Cases, Contracts, and custom transactional objects
- Junction and relationship records, such as opportunity contact roles and campaign members
- Tasks and Events, sorted by parent
- Email records
- Files, notes, and attachments, with parent links
- Post-load recalculations, sharing rules, and re-enabled automation
Steps 7 through 9 are the history layer, and they are what gets compressed when the schedule slips.
Choosing Between Data Loader, Bulk API, and an ETL Platform
Approach | Best Fit | Strengths | Limits |
Data Import Wizard | Small, simple, one-off loads | No setup, in-browser, duplicate handling | Cannot set audit fields, limited object support |
Data Loader with Bulk API | Mid-size migrations with a clean field map | Free, scriptable, supports audit fields and upsert | Manual transformation, limited error orchestration |
ETL or middleware | Multi-source, high volume, complex transformation | Reusable pipelines, joins, retry logic, scheduling | Licence cost and a real learning curve |
Custom scripted pipeline | Unusual sources or heavy reshaping | Full control over transformation and retries | Needs engineering ownership after go-live |
The tool matters less than the discipline around it. Whatever you pick must support upsert on an External ID, write audit fields, and produce a per-record success and failure log you can reconcile against.
Rehearse Twice at Full Volume
One dry run tells you whether the process works. Two tell you whether it works repeatably, which is the real question on cutover night.
Rehearse in a full sandbox at production volume. A partial-copy sandbox will not surface the locking and recalculation behavior that shows up at real scale, and those are exactly the issues that turn a six-hour window into sixteen. Time each step and build the cutover schedule from measured durations.
Phase 5: Validation That Actually Proves History Survived
Record counts alone will not tell you whether history landed usably, so the validation stage of the Salesforce data migration checklist has to answer a user’s question rather than a database’s. Use three levels.
Validation Level | What It Tests | Pass Criteria |
Count reconciliation | Source rows versus loaded rows per object | Zero unexplained variance, every gap traced to a documented exclusion |
Relationship integrity | Activities with a populated and valid parent | Under 1% orphaned activities, and every orphan explained |
Timeline usability | What a user sees when they open a record | Sampled records show correct dates, owners, and ordering |
The Twenty-Record Timeline Test
This check predicts adoption better than any report, and it takes about an hour.
Pick 20 records: the five largest accounts, five recently closed deals, five long-running service accounts, and five that were messy in the source system. For each, sit with the person who owns the relationship and open the Salesforce timeline alongside the same record in the old CRM.
Ask three questions. Is anything missing? Is anything attributed to the wrong person? Is anything dated wrong? Clean on all 20 means history survived. Anything else means you found the pattern before go-live rather than after.
Spot-Check the Ugliest Records in the Set
Sampling only well-formed records is the most common validation mistake. Test deliberately for:
- The oldest dates in scope
- Records owned by departed users
- Contacts that existed under more than one company
- Activities with no contact attached, only a company
- The largest attachments and longest email bodies
- Accented names and other multi-byte text
- Records merged in the source system
Prove the Audit Fields Landed
Run a report on each migrated object grouped by CreatedDate year. If every record sits in the current year, the audit field permission was not active during the load and the data has to be reloaded rather than patched. Catching that in a sandbox rehearsal costs an afternoon. Catching it in production costs the weekend.
Phase 6: Cutover and Delta Load Checklist
The gap between the final full extract and go-live is where late-breaking history lives, and it is real. A week of freeze in a busy sales organization is thousands of activities, which is why the Salesforce data migration checklist treats the delta load as a planned step rather than a contingency.
- Set the freeze window and put it in writing. Users need to know exactly when the old CRM goes read-only.
- Run the delta extract on the source’s own modified-date field, not a filter someone maintains by hand.
- Load the delta with upsert on the legacy External ID, which is what that field was built for.
- Re-enable automation in the documented order, then verify one small transaction end to end before releasing users.
- Keep the rollback decision explicit. Name who can call it, set the deadline for the call, and define what rolled back means in practice.
- Export the loaded org before opening it to users. Cheap insurance, rarely done.
What to Do With the Legacy CRM After Go-Live
Do not switch it off on day one, and do not leave it editable. Set it read-only for 30 to 90 days so users can verify anything that looks wrong. Then take a final archive export, store it under your retention policy, and decommission on a date announced in advance. A legacy CRM left live and writable guarantees a permanent split in your customer record.
Phase 7: The First 90 Days After Migration
The final stretch of the Salesforce data migration checklist runs after go-live, because the migration is not finished when the load finishes.
- Watch storage consumption in the first month after a long activity horizon
- Monitor report performance on high-volume objects and add indexes where needed
- Track user searches that return nothing, since they often point at history that did not land
- Re-run the orphan-activity query weekly for the first month
- Confirm integrations relying on legacy IDs are resolving correctly
- Collect formal sign-off from each data owner named in Phase 1
- Schedule a 90-day data quality review, since migration-era problems surface on the first quarterly reporting cycle
Teams that pair a migration with structured Salesforce managed services catch these issues while they are still small, and the same holds for orgs that plan the post-launch phase inside their broader Salesforce implementation services engagement rather than after it.
How Long This Takes and What Actually Drives the Timeline
Vendors quote wide ranges because the range really is wide. What follows reflects the projects we deliver, and the drivers matter more than the numbers themselves.
Migration Profile | Typical Duration | Main Driver |
Single source, under 100k records, short history horizon | 3 to 6 weeks | Field mapping and user acceptance |
Single source, 100k to 1M records, full activity history | 8 to 14 weeks | Activity linking and rehearsal cycles |
Multi-source consolidation with history | 4 to 7 months | Deduplication across sources and identity resolution |
Regulated industry with retention and residency rules | 5 to 9 months | Compliance review and documentation |
Salesforce org merge after an acquisition | 3 to 6 months | Metadata conflicts alongside data |
Three factors move a timeline more than volume: how clean the source data is, how fast decisions get made about what to keep, and whether history was scoped at the start or bolted on later. The third is entirely within your control, which is why this Salesforce data migration checklist front-loads scoping.
Where the Budget Actually Goes
Buyers expect the cost to sit in the load itself. It does not. Load execution is a minority of the effort, and most of the budget goes to the phases of the Salesforce data migration checklist that happen before and after it.
- Discovery, mapping, and decisions: roughly a third. Compressing it moves cost into rework later.
- Build and rehearsal: roughly a third. Pipelines, transformation logic, two full dress runs.
- Validation and remediation: roughly a fifth. Reconciliation, sampled review, and fixes.
- Cutover and hypercare: the remainder. Delta loads, automation re-enablement, first-weeks support.
Two line items go missing from cheaper quotes: full-sandbox rehearsal and structured validation of activity linkage. When a proposal names neither, the price difference is telling you what gets skipped.
Choosing a Partner for a History-Preserving Migration
Most Salesforce partners can move accounts and contacts. Fewer are set up to move a decade of conversation with attribution intact. The criteria below separate them, and they apply to us as much as to anyone else on your shortlist. Any provider worth hiring can walk you through their own Salesforce data migration checklist without reaching for a template.
Eight Questions Worth Asking Every Shortlisted Provider
- How do you preserve original created dates and owners, and when in the project do you enable that?
- What orphaned-activity rate do you accept as a pass, and how do you measure it?
- How many full-volume rehearsals are in the price?
- How do you handle historical owners who have left the company?
- What does your reconciliation report show, and can we see a redacted example?
- How do you handle attachments and notes, and is that base scope or an add-on?
- What is the rollback plan, and who is authorized to trigger it?
- What happens in the first 30 days after go-live, and is it included?
An honest provider answers the second and sixth questions with specifics. A vague answer to either usually means activity migration is being treated as a data load rather than its own workstream.
How We Approach It
Our Salesforce data migration services start from the assumption that history is in scope until someone explicitly decides otherwise, and that shapes how we sequence the work.
We open with a history scoping session rather than a field map, because the retention horizon changes the architecture. We build the legacy External ID structure on day one so every load is idempotent. We enable audit field permissions before the first rehearsal, so attribution problems surface in a sandbox. We rehearse at production volume twice. And we validate with the twenty-record timeline test alongside count reconciliation, because counts prove the data arrived while the timeline test proves it is usable.
We will also tell you when history should not move. A CRM carrying nine years of unstructured notes from a process nobody follows is not a heritage asset. Part of the job is separating the history that earns its place from the volume being moved out of habit.
Which Scenario Are You In?
The Salesforce data migration checklist above holds for every source system, but the emphasis shifts depending on where you are coming from.
Moving from HubSpot. The data model is close enough to Salesforce that mapping feels easy, which is the trap. Deal stage history, email engagement events, and marketing activity have no native Salesforce equivalent, so decide early which become Tasks, which become custom records, and which stay behind in reporting exports.
Moving from Microsoft Dynamics. Object names line up, behavior does not. Contacts without parent accounts, activity party relationships, and ownership hierarchies all work differently, and each needs an explicit translation rule rather than an assumed match.
Moving from a helpdesk. Zendesk to Salesforce migration and Freshdesk to Salesforce migration put the history question front and center, since a ticket without its comment thread is close to worthless. Public and internal comments map to different places, and knowledge articles are their own workstream.
Moving from a legacy ERP-linked CRM. Oracle, SAP, and similar environments feed downstream systems that key on the legacy customer ID. Preserving those identifiers is mandatory, and it often shapes the integration design as much as the migration design.
Merging two Salesforce orgs. Source and target speak the same language, but you inherit metadata conflicts, competing record type strategies, and two sets of automation. Audit field preservation is easier here and far more visible, since users know exactly what the dates should say.
Bringing the Salesforce Data Migration Checklist Together
The difference between a migration users trust and one they work around comes down to a handful of decisions made in the first two weeks. Scope history deliberately. Build the legacy ID field. Enable audit field permissions before the first rehearsal. Recreate historical owners. Sort activities by parent. Rehearse twice at real volume. Validate the timeline as well as the counts.
Work through this Salesforce data migration checklist in order and the failure modes described at the top mostly stop being possible, whichever CRM you are leaving. Skip the scoping and you will meet all of them, usually in the same week.
If you are planning a move off another CRM and history is part of what you are protecting, bring us your source data, retention requirements, and target org design. We will walk your situation through this Salesforce data migration checklist and tell you plainly what moves cleanly and what needs a decision first.
FAQs
1. Do We Need to Clean Our CRM Data Before Migrating to Salesforce?
Yes. Cleaning before migration reduces duplicate records, invalid values, outdated contacts, and mapping conflicts. Start with data profiling, ownership review, format standardization, and agreed deletion rules so Salesforce receives information users can trust from day one.
2. Can Data Be Migrated Into an Existing Salesforce Org Without Overwriting Current Records?
Yes. A migration can load into an existing Salesforce org, but matching rules must be defined first. Teams usually compare legacy IDs, email addresses, account domains, and identifiers to decide whether each incoming record should update, merge, or remain separate.
3. Can Custom Objects and Custom Fields Be Migrated to Salesforce?
Yes. Custom data can be migrated when there is a clear Salesforce destination. Some source fields can map directly, while others may require new custom fields, custom objects, transformations, or redesigned relationships before the production load begins.
4. How Are Duplicate Accounts, Contacts, and Leads Handled During Migration?
Duplicates should be identified before loading rather than left for users to fix afterward. Matching logic can use email, domain, phone, company name, or legacy identifiers, with review rules for uncertain matches so legitimate records are not merged incorrectly.
5. What Happens to Formula Fields and Calculated Values During a Salesforce Migration?
Formula fields are usually rebuilt in Salesforce instead of migrated as permanent stored values. The underlying source fields must be mapped correctly so Salesforce can recalculate results. Historical calculated values may need separate fields when past outputs must remain unchanged.
6. Can Email Opt-Out and Marketing Consent Preferences Be Preserved?
Yes, when the source system stores those preferences in exportable fields. Consent status, unsubscribe flags, timestamps, and lawful-basis information should be mapped deliberately so a migration does not accidentally turn previously suppressed contacts into marketable records.
7. How Are Multiple Currencies Handled When Moving Data Into Salesforce?
Multi-currency migrations require currency codes, exchange-rate assumptions, and amount fields to be reviewed before loading. Opportunities and financial records should retain their original transaction currency where required, while reporting currency behavior must match the target Salesforce configuration.
8. How Do You Prevent Date and Time Errors During Salesforce Data Migration?
Date errors usually come from time zones, daylight-saving rules, or inconsistent source formats. Normalize timestamps before loading, document the source time zone, and test representative records so meetings, emails, activities, and created dates appear at the correct time.
9. Can Lead Conversion History Be Migrated Into Salesforce?
Lead records can be migrated, but historical conversion behavior needs careful design because Salesforce does not recreate every legacy conversion event automatically. Teams may preserve conversion dates, original lead IDs, source details, and related account or opportunity references separately.
10. Can Campaign Membership and Marketing Attribution Be Migrated?
Yes, but campaign structures should be mapped before member records are loaded. Preserve campaign names, member statuses, response dates, and source identifiers where useful. Historical attribution may require custom fields or reporting logic if the legacy model differs from Salesforce.
11. Can Salesforce Roles, Queues, Territories, and Account Teams Be Migrated Too?
They can be recreated or mapped, but they should be treated as configuration rather than ordinary business records. Their design affects ownership, visibility, routing, and reporting, so teams should validate the target access model before assigning migrated records.
12. How Is Sensitive CRM Data Protected During the Migration Process?
Sensitive data should be limited to approved fields, transferred through secure methods, and accessed only by authorized migration users. Sandbox copies may also need masking or restricted access, especially when the source contains regulated, confidential, or commercially sensitive information.
13. Do Integrations Need to Be Paused During a Salesforce Migration?
Often, yes, especially during final cutover. Active integrations can create, update, or duplicate records while migration batches are running. Teams should document each integration, decide what must pause, and verify synchronization carefully before reconnecting systems after go-live.
14. Can a Salesforce Migration Be Completed in Phases by Department or Business Unit?
Yes. Phased migrations can reduce operational risk when teams have different processes, data quality, or readiness levels. However, shared accounts, contacts, reporting, and integrations need clear ownership rules so phased cutovers do not create conflicting versions of customer data.
15. What System Access Does a Salesforce Migration Team Usually Need?
Migration teams typically need export access to the source CRM and appropriately controlled API or administrative access to Salesforce. Access should follow least-privilege principles, use dedicated migration credentials where possible, and be removed or reduced after cutover.