The Salesforce Migration Survival Kit: 5 Must-Haves
This guest blog post is written by Drew Niermann, a certified Salesforce Administrator, User Group Leader, and an Account Manager at Capstorm, LLC. He spends most of his time building partnerships with consultancies and helping customers find Salesforce data solutions. You can reach out to him and his team by emailing info@capstorm.com.
If you are a consultant, solutions/technical architect, or leader of a Salesforce consulting team, chances are you’ve been involved in a few Salesforce migration projects.
Some of them may have ended well, but I bet many were quite challenging, over budget, and late on delivery. Why are these projects so difficult? Why do they leave you feeling like you are blindfolded and skittering through a minefield?
What makes migrations tricky
As you are well aware, there are a number of items that make these projects particularly interesting, including:
-
The differences in data between your platforms must be noted and accounted for, which requires hours of analysis and manual metadata recreation and manipulation.
-
Typically both the source and target Salesforce Orgs are still being utilized by multiple teams so any downtime must be kept to a minimum.
-
Much of the Salesforce Org’s automation must be disabled prior to importing or loading data.
-
Moving any amount of data, from 500MB to 5TB, is incredibly tedious and error-prone (not to mention the risks of moving to a live production Org without testing in a sandbox environment!)
5 must-haves for a Salesforce migration project
There is no one-and-done, easy solution for migrations. But we can help you prepare so you know what to expect. Here are five capabilities you must have when tackling a Salesforce migration:
1. The ability to extract and maintain historical versions of metadata for analysis and migration
You want to maintain a backup of metadata to account for any changes in Salesforce structure that occur during the migration project. This backup should be maintained in an accessible database. This makes all metadata components visible and queryable at the database level, and enables deployment of historical metadata versions.
Rather than building inbound and outbound changesets and waiting half an hour per upload, 3rd party tools can deploy metadata faster.
2. Tools to handle complex data extraction and loading- not Data Loader!
A truly seamless migration requires that data be maintained in such a way that end users never experience disruption! In order to do this, the data from the source Salesforce must be extracted and kept up-to-date in a separate database. Using an incremental extraction tool saves time, reduces API calls, and eliminates the need to shut down the source or target Org.
Most migrations require some level of data cleansing or transformation. Instead of manipulating data in spreadsheets, utilize a relational database. Once the transformation algorithms have been defined, rapidly transform data to fit the structure of the target Org. Then perform daily test migrations in a sandbox to ensure the final cutover is a breeze!
A robust data import tool is necessary in order to push records and corresponding relationships into Salesforce. It may sound a little crazy if you are a die-hard Data Loader fan, but there are tools out there that can maintain record relationships even when inserting records into a totally fresh production instance. If you made a mistake and overwrote some data or deleted some reports, restore historical versions with a few clicks.
3. Tools for intuitive management of Salesforce automation
It can be time-consuming to manually disable automation prior to each batch of record inserts. This should be handled by a 3rd party tool that is smart enough to detect triggers, validation rules, flows, restricted picklists, etc.
Make sure the tool you use gives the flexibility to disable all automation or selectively choose which components to disable.
4. The ability to migrate process builder, flows, workflows, approval processes, and translations between orgs
Clients pay to have these customizations built into their Orgs, and consultants spend lots of time developing them. Why recreate when you can migrate?
The amount of potential time savings makes this one a no-brainer, not to mention the difficulty of recreating these custom components exactly as they were in the original Org.
5. Ability to do an end-to-end replication test in a sandbox before touching a live production instance
This is nearly impossible without a tool that can move data and metadata between Salesforce Orgs while maintaining relationships. However, it is a crucial part of a successful migration.
Do you really want a 2 am emergency trying to find out why a few hundred records are missing? Instead, do a full migration test to a sandbox multiple times to refine the process, then do the production migration once!
Use a tool that supports standard and custom objects, notes, attachments, content version, knowledge, chatter, and tasks.
Make sure your solution already “knows” Salesforce’s data dependency model within a point-and-click interface. No one wants to deal with .CSVs, record patching, or manually analyzing relational dependencies prior to restoring data. Say goodbye to Data Loader!
Want to read more about the migration process and a few common gotchas?
The experts at Capstorm put together a Salesforce Migration Playbook we think you should check out.
Need a team of experts for your upcoming Salesforce migration project?
Idealist Consulting has a team of certified Salesforce experts experienced in complex migration projects on staff. If you have a migration coming up, we’d love to chat about your project and see if we’d be a good fit.
