The documentation can be found here: SFDMU Help Center
The SFDMU GUI Desktop Application: SFDMU GUI Desktop App
Please, see the User Support Policy before opening cases
Welcome to contribute to the SFDMU! Please, take some time to read our Contribution Policy
- Introduction.
- Why should you use the SFDMU ?
- Use case.
- Watch the demo. The Plugin in action.
- Installation of the Plugin.
- Configuring the migration job.
- Running the migration job.
The SFDX Data Move Utility (SFDMU) is a modern and powerful open-source salesforce data loader based on the famous SFDX CLI. It will make salesforce data seeding process extremely easy and fast.
This Tool is the innovative and very handy alternative to the traditional salesforce data loader application as well as to the set of the force:data:tree commands.
✔ The SFDMU will help you to populate your org (scratch / dev / sandbox / production) with data imported from another org or CSV files.
✔ It supports all important CRUD operations (Insert / Update / Upsert / Delete) also for multiple related sObjects.
✔ It provides you the All-In-One data migration solution with a large amount of unique OOTB features have never provided before by the existing tools.
✔ This Plugin is approved and digitally signed by the Salesforce.
The SFDMU is equipped with special capabilities making migration of complex related data significantly easy:
- It supports direct Org-to-Org data migration without having to deal with annoying intermediate CSV files.
- Full support of CRUD operations: Insert / Update / Upsert / Delete.
- Supports import and export of CSV files.
- Supports multiple object sets allowing you to execute multiple migration jobs in one run.
- Supports simultaneous migration of multiple SObjects in one run..
- Handles complex circular references between multiple SObjects.
- Simple and user-friendly configuration just with a single export.json file
- Can be run from a command line, can be easly integrated into any DevOps pipeline.
- Handles self-referenced fields, e.g. Account.ParentId.
- Supports External Id field of any type even formula and auto-name fields, a field does not need to be defined as External Id.
- Supports composite external Id keys.
- Supports data migration preserving Record Type for each record.
- Supports fully customized Fields and Object Mapping.
- Has the built-in ETL features, including customized Value Mapping, expression-based records transformation.
- Supports migration of Person Accounts, including mixed account records of Busines and Person type.
- Supports migration of Salesforce Files as well as old-fashioned Notes , Attachments, including file binary data.
- Supports record owner assignment, including option for a default owner assignment.
- Has the built-in data anonymization feature to anonymize a sensitive source data (e.g. coming from Production org).
- Supports binding of polymorphic lookup fields (e.g. FeedItem.ParentId).
- Secured and safe. All operations are performed on the client's machine, there is no cloud interaction, so all is completely safe.
- Fast performance. Processes only a selected subset of records and fields that need to be inserted or updated and does not touch others.
- The core functionality can be extended by using the Custom Add-On Api. You can create your own Add-On for your special purposes.
Creating of a scratch org, dev org or even a sandbox today is a pretty fast and simple action. On the other hand the newly created organization has only metadata ready-to-use, has no real data that is always strongly required to develop and debug any Salesforce application. It makes no sense to manually create or load data traditional way (with the Salesforce Data Loader) for each new org because the data easily can be taken in whole or in part from production or from the sandbox and imported into the new organization.
In some cases we already have the data, but it's only required to modify particular records or even fields without touching others. When a date model is complex and contains a large number of dependencies, it becomes a very hard and annoying task.
Also there is a situation when as client you would like to keep the data model clean without creating external ID fields in the SObject, therefore your goal is to find some workaround to update records in your developer org from the existing source without adding new fields.
Population of the RecordtypeId field is another quite difficult task, when ids are not consistent between environment.
At current moment, there is no effective tool for both inserting and updating dependent objects based on any unique field used as External Id. In most cases people use Excel spreadsheets to build source tables and try to mix between them to get proper values for the lookup or master-detail fields. So filling out even a small number of objects turns into a huge pain...
Running the Plugin from the command console / terminal:
Before using the SFDMU you need to perform the usual procedure of installing SFDX CLI on your computer from here:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm
# If you have an old version of the Plugin, uninstall it:
$ sfdx plugins:uninstall sfdmu
# Install the latest version of the Plugin:
$ sfdx plugins:install sfdmu
# If you have outdated source code already cloned and linked, go to the directory containing old Plugin source code and unlink it from the SFDX by typing:
$ sfdx plugins:unlink
# Clone the source code:
$ git clone https://github.com/forcedotcom/SFDX-Data-Move-Utility
# Make the installation directory current:
$ cd SFDX-Data-Move-Utility
# Install npm modules:
$ npm install
# Link the Plugin to the SFDX:
$ sfdx plugins:link
Create a new export.json file with the following format:
{
"objects": [
{
"query": "SELECT Id, Name FROM Account",
"operation": "Upsert",
"externalId": "Name"
}
]
}
Assume you have the following data model with complex circular relationships between SObjects:
Let's say, each record has unique Name value, so you want to use Name field as an External Id field for all SObjects in that data model.
You can Upsert all records preserving relationships between SObjects by creating an export.json file with the following format:
{
"objects": [
{
"query": "SELECT Id, Phone, TestObject3__c FROM Account WHERE Name LIKE 'TEST_ACC_%'",
"operation": "Upsert",
"externalId": "Name"
},
{
"query": "SELECT Id, Account__c, TestObject3__c, RecordTypeId FROM TestObject__c",
"operation": "Upsert",
"externalId": "Name"
},
{
"query": "SELECT Id, Account__c, TestObject__c FROM TestObject2__c",
"operation": "Upsert",
"externalId": "Name"
},
{
"query": "SELECT Id, TestObject2__c FROM TestObject3__c",
"operation": "Upsert",
"externalId": "Name"
}
]
}
-
Go to the directory where your export.json is located.
-
Use the following command to run a direct migration between source and target salesforce orgs:
$ sfdx sfdmu:run --sourceusername source@name.com --targetusername target@name.com
- For import data from CSV files:
$ sfdx sfdmu:run --sourceusername csvfile --targetusername target@name.com
- For export data into CSV files:
$ sfdx sfdmu:run --sourceusername source@name.com --targetusername csvfile
Documentation articles: