Once a dataset has been built, Migrate Datasets inserts and updates its records into a destination Salesforce org. All internal relationships are preserved and external references are reconnected to matching objects on the destination. The Bulk API is used for high-performance transactions, with the SOAP Data API available as a fallback, so even very large datasets with complex parent-child hierarchies migrate efficiently.
Getting started
Right-click a Deployment Arrow connected to the correct destination org and select Migrate Datasets. Select any of the global datasets from the list at left to see the objects and fields available at right. The next four tabs provide options for matching fields, scrambling fields, deactivating assets, and finally migrating the selected dataset.
Power user tip: right-click any object in the middle list to export its data as an XML or CSV file. These files are in the correct format for the Import Datasets dialog, so you can export a CSV, edit it as a spreadsheet, and import your changes back.
Matching fields
Snapshot uses the loaded fields to identify matching records in the destination org. If a source record matches a destination record, that record is updated; if it does not match, a new record is created. Snapshot selects common matching fields for you automatically, but you can also select them manually — for example, to match Accounts by Name and BillingCity, make sure both are loaded. The selected fields form a logical AND filter for matching destination records.
The most reliable way to match destination objects is with External IDs. Other common matching fields — object names, email addresses, and usernames — are automatically available to select. Some sandboxes share the same IDs as their production org, in which case you can simply use the Id field for matching. You can also use a Virtual ID to match hard-to-find objects that have no name; when those objects are created, Snapshot remembers the source ID and destination ID and always matches them during future migrations.
Beneath the dividing line you will see external references to other objects in the destination org. Snapshot connects these automatically during migration, and you can specify additional fields needed to match them.
Scrambled fields
Datasets are often moved into a sandbox or Developer Edition for testing or development, where you may want to scramble records that contain sensitive information — financial data such as credit cards or bank accounts, or personal data such as email addresses or Social Security numbers. On the Scramble Fields tab, move the fields you want to obscure over to the list at right.
Deactivate assets
When a record is inserted or updated, Apex Triggers, Workflow Rules, and Validation Rules may fire. These automated behaviors can cause undesirable effects during a migration — thousands of emails might be sent out, or some records might fail to update. The Deactivate Assets tab deactivates Apex Triggers, Workflow Rules, and Validation Rules in the destination org before the migration is attempted, and turns them back on afterward.
Running the migration
The next tab is the main migration interface. First make sure the migration options are set correctly (below), then click Migrate Datasets to begin. All the details of the migration are written to the report at the lower right. The last tab lets you migrate at a specific time in the future or as a recurring event.
Migration options
Delete behavior
- Upsert Records Only
- Delete Then Upsert
- Delete Records Only
The menu in the upper left controls whether the current dataset is deleted before migration, deleted and then upserted, or upserted only. Only destination records that match records in the current dataset are deleted. For production orgs, Snapshot confirms twice that you want to delete the data — be careful with this option.
Error handling
- Stop After Error
- Continue After Error
If an error occurs, Snapshot either stops processing additional files with the Bulk API or continues. All errors are written to the log files. Common errors include too many duplicate records, email addresses in the wrong format, and field data in the wrong format.
Field truncation
- Don't Truncate Fields
- Allow Field Truncation
A common problem when moving data between different types of orgs is text strings that are too long for the destination field. This option automatically truncates fields to the correct length, or otherwise reports an error.
Logging
- Log Migration Errors
- Log Errors and Success
All errors are written to the log files in the datasets folder of the Snapshot file system. You can optionally also log successful migrations. The log file contains the source and destination IDs as well as any error message.
Processing mode
- Bulk API Serial
- Bulk API Parallel
- Data API Serial
Bulk API Serial is the default. Bulk API Parallel is potentially faster but may cause database lock errors. If the Bulk API has performance or network issues, switch to Data API Serial, which uses the standard SOAP Data API.
Getting matching right
Pay special attention to the matching fields you select — they must identify a unique record on the destination org. On the first run, matching destination records are updated and non-matching records are created. On a second run, you should see only updates, because every destination record now has a unique match. If you see more records being created, your matching fields are not reliable. This is why External IDs are highly recommended: they create the record if needed and match forever after. If you cannot use an External ID, be absolutely certain you are getting unique matching fields some other way.
Video
Links
Snapshot Best Practices: Salesforce Relational Data Migration