Migration
A migration in Salesforce is the planned movement of something from a source to a target.
Definition
A migration in Salesforce is the planned movement of something from a source to a target. That something can be records, configuration metadata, an entire org, a feature, or a set of user licenses. The word is overloaded, so the first job in any migration conversation is to confirm which kind is meant.
The five common types are data migration (records between systems or environments), metadata migration (configuration between orgs), platform migration (an org moving to Hyperforce), product migration (replacing one feature with a newer one), and license migration (moving users between license types). Each type has its own tools and risks, but all follow the same arc: inventory the source, design the target, test in a safe environment, then cut over with a rollback plan ready.
The five migrations hiding behind one word
Data migration: moving the records
Data migration moves records into Salesforce from a legacy CRM, between two Salesforce orgs, or from a sandbox up to production. For volume work the standard tool is Data Loader, which handles up to 150 million records per job and can run from a UI or the command line. The Data Import Wizard covers lighter loads (up to 50,000 records) for common objects like accounts, contacts, and leads. For multi-system orchestration, MuleSoft moves and transforms data across endpoints. The technical part is rarely the bottleneck. Data quality is. Field mapping, deduplication, and validation-rule conflicts dominate the effort. Salesforce recommends loading objects in dependency order so relationships resolve, and using External ID fields with upsert so child records find their parents. Load a small test file first to confirm the mapping before the full run. Configure Data Loader to use the Bulk API for large jobs, since it processes records in parallel and cuts the network round-trips that slow a SOAP-based load.
Metadata migration: moving the configuration
Metadata migration moves configuration (not records) between orgs: a sandbox to production, a dev org to UAT, or one environment to another during a release. Change Sets are the native, UI-driven option that needs no extra install, but every interdependent component has to travel together or the deployment fails on a missing reference. Salesforce DX brings a CLI and source-tracked workflow for teams that want version control and automation. Unlocked Packages let you bundle and version metadata as modular units, which suits internal business apps that are not headed for AppExchange. DevOps Center is the Salesforce-supplied change and release tool, available as a managed package and as a next-generation version built on the platform. The Metadata Coverage Report tells you which component types are deployable through the Metadata API at all. Anything outside that list needs manual setup in the target org, so check coverage before you promise a clean automated path.
Platform migration: moving to Hyperforce
Platform migration moves an org off legacy first-party infrastructure onto Hyperforce, the public-cloud architecture that runs Salesforce on providers like AWS. This is not a feature you turn on. It is an infrastructure move that Salesforce schedules, and most older orgs are on a multi-year plan to get there. The Hyperforce Assistant in Setup walks an admin through readiness: it lists preparation tasks, flags hard-coded references and IP allow-lists that need updating, and helps schedule the cutover window. The practical risk lives in anything that assumes a fixed instance or IP range, such as integrations pinned to an old endpoint, allow-lists on a firewall, or code with hard-coded URLs. Connected products like MuleSoft, Marketing Cloud, and Tableau Cloud each have their own Hyperforce migration guidance and timelines. Treat the Assistant as a checklist, not a one-click button, and remediate the references it surfaces well before the scheduled date.
Product migration: replacing a retiring feature
Product migration swaps one Salesforce capability for a newer one. The clearest current example is automation. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, and now directs all new automation to Flow Builder. Existing rules and processes keep running after that date, but they get no bug fixes or support, which is why teams are moving them. The Migrate to Flow tool converts workflow rules and Process Builder processes into flows, including scheduled actions, and supports partial migration when only some actions can be converted automatically. The workflow is simple: select a rule, run Migrate to Flow, test the resulting flow, deactivate the original, then activate the new flow. Other product migrations follow the same shape with their own tools, such as Salesforce for Outlook to the Outlook Integration, or Salesforce Classic to Lightning Experience. Each has a documented path and an end-of-support date worth tracking.
License migration: moving users between editions
License migration changes the license type assigned to users, for example moving someone from a Salesforce license to a Lightning Platform license, or an external user from Customer Community to Customer Community Plus. Unlike the others, this one is part contract and part configuration. The commercial side is a change with your Salesforce account team to adjust what your org is entitled to. The technical side is reassigning each user to the new license in Setup and confirming their profiles and permission sets still grant what they need. Most license migrations exist to save money by matching the license to how a user actually works, so a heavy admin and a read-only viewer are not paying for the same thing. The trap is feature loss. A cheaper license usually carves out objects, tabs, or API access, so audit what each affected user touches before the switch, and test a representative user in a sandbox first.
The pattern every migration shares
Strip away the tooling and every migration runs the same loop. Inventory the source so you know the true scope, including the records, configuration, integrations, or users actually in play. Design the target so you are migrating to a deliberate end state, not just copying the old shape. Test in a non-production environment, a sandbox or scratch org, because production-first migrations have a long history of causing incidents. Plan the cutover with a rollback option, and know up front which migrations cannot be reversed. Communicate timelines so stakeholders can plan around the change instead of being surprised by it. Mature programs add governance on top: a small group that catalogs ongoing migrations, tracks completion, and coordinates cutovers. The Workflow Rules end-of-support is a cautionary tale here, since orgs without that oversight discovered un-migrated automation late and scrambled. Governance turns a string of one-off scrambles into a managed, predictable cadence.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Migration.
Hands-on resources to go deeper on Migration.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which activity counts as Migration in the Salesforce context?
Q2. Which tool is typically used for the data-migration flavor of Migration?
Q3. What is described as the hardest part of a data Migration project?
Discussion
Loading discussion…