FinancialForce Data Migration: How To Avoid Pitfalls?
Should migration be a separate project? Before we find out the truth, let’s quickly get rid of the three most common misconceptions in data migration to avoid mistakes that could lead to data migration disasters. The three misconceptions that everyone has about data migration are as follows:
- Direct migration to live system is faster – Data that you need to transfer from FinancialForce to another system or from another system to FinancialForce is directly done live. The larger your database and the more error it has, the longer it takes.
- Migrating data is a one-time activity – Migration on the live system is not all about copying data from one system to another.
- Data is good – People assume their data is perfect and that there are no missing records. Unfortunately, there’s always a high chance of error and inconsistencies in all company records. Therefore, you need to double-check data quality before it’s transported to the new system.
Not Making Data Migration A Separate Project
Most of us think the data migration process can be done at the push of a button. However, as we’ve already busted this myth above, we know now that it’s not so easy. So to answer the initial question above, yes, data migration must be a separate project because there’s no predefined mapping between two targeted systems. We can’t just press export and import data buttons to finish the whole process instantly.
Data migration is a complex activity that should be handled carefully. It needs a separate project plan, budget, and a solution approach from start to finish. You’ll need weekly deadlines to ensure that your plan is on track and your data is correct so that your final results are predictable and accurate. Read further to find out the right way to systematic planning.
FinancialForce Data Migration Framework
Whether you are migrating data from FinancialForce to another system or from any other system to FinancialForce, below is the framework or blueprint you need to follow.
There are six stages that you need to go through in this process. The good thing is that either your internal team or your hired consultant will benefit from this guideline.
Step 1: Governance
This is the stage where you see and identify stakeholders and key team members for your data migration project. Those stakeholders can be your business users and teams from different business units (marketing, sales, or accounting team). Collaboratively you have set the goals on what you’re trying to achieve on this data migration project. Once you’ve decided on a clear goal, it’s time for you to move to the next step.
Step 2: Understand FinancialForce and Your Data
Before you start the process of migrating your data from one system to another, try to classify the data. Only transfer data that must be transferred and archive or delete the ones that can be left out. You must come to this step after you’ve gone through the governance step because it’s the stakeholders who are going to identify and tell you which data is necessary for them and what’s not required. Also, your FinancialForce team who is part of the data migration process should very well understand the object’s nature and limitations so they can take care of the customization as per your company requirements.
Step 3: Prepare Data & A Destination ORG
Now, the third step is to prepare data both at the source and the destination end. At the preparation stage, you need to consolidate the existing data before you export it and cleanse it from the source system. For example, there may be several missing records in your existing source system, there may be inconsistencies, or some records may be invalid. If you don’t get rid of those bad data initially, you might end up transferring all those data records to your target system. So it’s very important to understand your data, clean it and then do a proper field mapping before you move to the next step.
Step 4: Complete & Verify A Test Migration
Once you’re done cleansing and preparing your data, it’s time to run a test migration. We always suggest you not to proceed with the entire records migration in one go. Divide them into phases and follow a step-wise process. For example, if your system needs 100,000 records to be migrated from the source system to the target system. Divide them into chunks and start by migrating just about 1000 records and ask the business users to test them out. Move to the next step if they approve the accuracy of data. Otherwise, correct the scripts of those 1000 records if any problem arises. Taking such small steps will allow you to save yourself from a bigger disaster because it’ll be easier for those business users to test out the 1000 records rather than the 100,000 records in one go.
Step 5: Migrate & Validate
After you’ve migrated, validate that data and never do a direct migration from one live system to another. Make a Sandbox environment. Migrate first in Sandbox, get it tested by your business users, and only then move to production because your production is something that impacts your live users. Therefore, you don’t want to mess it up. So the tip is to try on a testing environment before you go live.
Step 6: Post-Migration Activities
Then the last and final step is to make sure that any triggers or workflows that are disabled in the pre-migration process are enabled again in the post-migration activities.
This blog demonstrated a basic framework that everyone can use while migrating data that is not limited to just FinancialForce. Use it for Salesforce, your accounting, or any other system. Now that we’ve covered the first part of this blog series, Data migration: How to avoid pitfalls, you can move to the next part to find out how important it is to get help from experts in this field and other revelations to up your game in data migration.
