As the world’s #1 CRM platform, Salesforce is critical to thousands of organizations’ day-to-day operations, giving them a unified view of every interaction to deliver better experiences to their customers. Every day, these businesses rely on Salesforce to find customers, win their business, and keep them happy.
Beyond the daily value the platform provides, Salesforce also enables companies to grow and mold their business through large-scale, transformational projects. Sometimes the need for these projects is due to an internal business change, like a merger, acquisition, or divestiture. But it’s just as likely that an industry shift precipitates the need to evolve. A study by LogicMonitor found that 87% of global IT decision-makers will hasten their migration to the cloud, with 74% expecting nearly all workloads to be in the cloud within the next five years.
It’s no surprise then that the most significant digital transformation initiative a company undertakes is often its first move from a legacy (often non-cloud) system into Salesforce. Other examples of transformations include implementing a new org for a new business division, migrating data from one org to another, migrating to Lightning, and integrating third-party applications.
Whatever the reason, these projects mustn’t disrupt the day-to-day activities mentioned earlier by accidentally corrupting or deleting data. When you combine the risks that come with cloud complexity and your company’s responsibility to protect its data, the results can be disastrous, even if it resides in a reliable and secure platform as Salesforce.
In this post, we’ll look at some of the common risks associated with org migrations and implementations and how you can mitigate them, as well as the importance of having a cloud data protection platform in place before undergoing these projects.
What is a Salesforce org migration?
A Salesforce org migration is the process of moving data, configurations, and applications from one Salesforce org to another. This process can transfer data between different orgs or move data from a sandbox to a production org.
Common Salesforce org migration challenges
1) Identifying what needs to be migrated
It is important to identify what data needs to be transferred between the two Salesforce orgs. Migrating only essential data is typically a best practice; however, certain data retention requirements may require you to migrate certain data that you otherwise would choose not to.
2) Data quality issues
Data cleanliness is crucial when moving data from one org to another. Any data that is duplicated, inaccurate, or incomplete in the source org will be transferred to the new org. Migrating data from one org to another is a good opportunity to asses the data cleanliness of your source org and make any necessary clean-ups before performing the migration.
3) Mapping objects and fields
When migrating from one org to another, you should ensure that all objects and fields are mapped correctly. This includes making sure that the data types, field lengths, and picklist values match between the two orgs. Also, ensure all source system records have a unique Identifier (ID).
4) Data security
Security must be considered when moving data between orgs. For example, be sure to understand the data requirements that may pertain to specific regulations such as HIPAA. Also, identify any special fields that may note special requirements or contacts for breach or other security notifications and ensure they are carried over.
Tips for your next Salesforce org migration
1. Review Active Workflows and Triggers
Prior to a data import, you must consider how not just the data, but the metadata in your org will be affected. For example, in Salesforce you can create a trigger that sends an email upon the performance of a certain action. Not disabling active workflows or triggers that affect migration objects could cause you to send unwanted emails to hundreds or even thousands of customers.
How to lessen the risk: It’s best to disable any active workflows or triggers before a large data import. You should also check to see if you should add, modify, or delete any validation rules. Some validation rules may not be 100% compliant with legacy data (or the other way around). For example, one rule might have all state names abbreviated, while another requires spelling out. While the quick fix temporarily deactivates the blocking rule, the better solution here is to modify the data before uploading or slightly adapting the validation rule.
2. Import Objects in the Correct Order
When migrating data between Salesforce orgs, you need to make sure you’re keeping the relationships intact. Salesforce is a relational database, which means changes made to parent records (like Accounts) can have unintended effects on child records (like Contacts). If not done correctly, your business could be at high risk of moving corrupted data, including accounts that are missing opportunities, campaigns that are missing members, or opportunities that are missing products.
How to lessen the risk: Know the correct order of migration. In Salesforce, relationships that exist between objects and dependencies dictate the order of migration. For example, move Users first, then Accounts, then Contacts, then Opportunities. Doing this will ensure that you are keeping the parent and child data relationships intact, thus maintaining the integrity of your data.
3. Start in a Sandbox
Although data migrations and implementations are often necessary for Salesforce transformations, these migrations always pose a risk of incorrect data being overwritten, with large volumes of data being moved and/or consolidated.
As an example, a financial services provider almost lost critical attachments during their Salesforce Lightning migration. Even though their Salesforce admin had a careful process for converting their documents to files in batches, the admin missed one batch containing about 90k attachments due to an error in the tool.
Trying to clean up a data mess like this can take days, weeks, or even months of developer time. It would be better to spend this time developing new features and functionality. According to Stripe, companies lose upward of $300 billion because developers pour time into fixing bad software.
How to lessen the risk: Test in a sandbox. Migrate a small subset of your data in a recently refreshed full sandbox. This environment is a complete duplication of your production Salesforce environment, including all configuration, code, and data, and will ensure that all issues are exposed early. Testing in a sandbox will allow you to make any required fixes easily before they cause errors in production.
Why it’s critical to back up your data before a major project
In addition to these steps you can take, there’s one more way to lessen your data loss risk during these projects: have a solid data protection foundation. No matter how careful you are, mistakes are bound to happen when moving hundreds or thousands of records. Salesforce recommends that you keep a regular backup of your data and do a manual point-in-time backup “before proceeding with any major data project within your organization.”
When considering such a solution, it must have intuitive data identification tools and fast recovery times in a data loss scenario. It would help if you also were sure that the solution meets your company’s security and compliance requirements and provides accessible, reliable backups of your Salesforce data, metadata, and attachments.
One more thing: don’t wait until your “go-live” date to implement your backup. Many organizations wait to implement a backup solution until they have live data in their org. But having a solution in place pre-deployment will allow you to back up your sandbox environments and monitor any changes to your metadata as various developers and system integrators (SIs) prepare your environment for deployment.
Eliminate downtime during a migration or implementation
It’s important to mitigate your business risk during these transformative initiatives. At Own, we can help you minimize business disruption during your next major data migration or implementation by proactively protecting your Salesforce data with a solution that includes:
- On-Demand Backups: While Own performs daily, scheduled backups of all of your data, metadata, and attachments, you can also run an on-demand backup before a big migration or implementation. Just click a button to back up any or all data at any time instantly.
- See The Difference: If you suspect something did go wrong, or you made an error, those mistakes are easy to identify. With Own, you can review data and metadata side-by-side to see additions, deletions, or changes. Visual graphs illustrate how data changed over time, making it a snap to pinpoint when unusual behaviors occurred.
- Precision Repair: When recovering your data, maintaining data integrity is key. With Own, you can proceed with confidence knowing that your data will be recovered, with relationships intact, up to five levels deep. You can go back in time to restore the exact data you need without rolling back all of your records.
Own has helped many of its customers navigate Salesforce migrations and implementations, including real estate investment firm NorthMarq. Upon switching to the Salesforce platform, NorthMarq needed to migrate its existing pipeline generation activity and sales-related data into Salesforce. Before the migration, they had started backing up their Salesforce data with the Weekly Export but found that the processing time was becoming too lengthy.
With the help of Own, NorthMarq was able to identify any data that had been modified or altered during the migration process. Own supported NorthMarq as they seamlessly migrated all existing data from their legacy CRM system to Salesforce by reducing the risk of a data loss or corruption.
.avif)
