What to Keep in Mind When Migrating Financial Data to JD Edwards
According to McKinsey & Company, a management consulting firm, company acquisitions fall into six main archetypes. Here at Surety Systems, we know that no matter which archetype your acquisition falls into, there are some things you’ll need to keep in mind when it comes to migrating the financial data of your newly acquired company (NAC) to your JD Edwards system. Specifically…
Buy-in (and Training) Is Key
As is the case with anything to do with business acquisitions or data migration, you’ll need buy-in from key players in both the NAC and the parent company to ensure your financial data migration goes smoothly. JD Edwards has a number of tools to help out in situations like these, but if users on both sides of the migration don’t dedicate time/effort to the process, everyone’s probably going to have a much rougher time.
Additionally, you’ll need to have a change management and training strategy in place for the NAC’s finance team to help them get up to speed in JD Edwards. After all, what’s the good of migrating all that financial data over to your new system if the NAC’s Finance team doesn’t know what to do with it anymore?
Ensure Your Data Is Mapped Correctly
A key thing to remember when migrating any kind of data from a legacy system to JD Edwards is that all of them are different. That being said, the fact that you’re dealing with financial information means there are some commonalities, no matter where you’re migrating from. If you’re dealing with financial data, you’ll most likely be dealing with CSV files, for example, and your primary concern will be migrating information from the legacy chart of accounts to the one in JD Edwards.
Your biggest concern in this situation is making sure that you’ve mapped your data correctly. Your first step is to ensure that you’ve set up all your accounts correctly in JD Edwards. That’s where mapping comes in. JD Edwards has a number of tools and kinds of reports to help you with this, but proper mapping will save you time and headaches later.
Next, and just as important, is data validation. Although all data is important, correct financial data is especially important to the continued and healthy operation of your business—you’ll want to ensure that all of the legacy financials from the NAC made it safely into your JD Edwards system. This is made more difficult when you realize that data validation isn’t always a one-to-one process when you take into account the splitting or condensing of…well…accounts.
You may find that the way an account was organized in a NAC’s legacy system made sense for that system but not for JD Edwards. (Or maybe you’re dealing with an older form of JD Edwards.) Whether the legacy system organized several accounts as separate when you’d like them to be condensed into one in JD Edwards, or vice versa, managing this issue properly will affect the success of your data migration.
Luckily, JD Edwards has a feature to help you make the process a bit easier: category codes. Most categories have a limit of around three codes, but some (account category codes 21-43) all have a limit of 10 each. Codes 21-23 even have inquiry and reporting features out of the box. Use these larger codes for legacy accounts to help clean up navigation. Also, there is a third account number field that is free-form and can be used and reported on for data validation.
Avoid These Common Data Migration Issues
No matter what type of data migration you’re performing, there are some common potholes companies seem to always end up falling into. Luckily for you, we’ve outlined below some tips and tricks for avoiding these all-too-frequent problems, including…
Risk of Data Loss
Any time data is moved from one location to another, there is always a risk that some data will be lost (once the source data set is no longer in use). To mitigate this risk, Count Reconciliation and Key Financial Column Reconciliation can be used.
This type of reconciliation depends on comparing the number of records in the legacy system and the target system. It’s possible that the data migration process may require the rejection of some records, so these numbers don’t need to match, so long as the number of legacy records is equal to the number of rejected records plus the number of final records.
Key Financial Column Reconciliation
This type of reconciliation depends on comparing key financial closing information (closing balance, available balance, etc.) and comparing that information between the legacy and the target system. If there’s a mismatch, you can drill down deeper to figure out which record or records are missing.
Data Corruption/Integrity Issues
If the format or the content of data in the legacy system changes during the migration process, the integrity of that data can be affected (or even corrupted). There are a number of data validation strategies that can solve this issue, which include Sample Data Validation, Subsets of Data Validation, and Complete Data Set Validation.
Key things to keep in mind about data validation strategies includes project stability, how much data is being covered, how long it will take to execute the validations, and data validation query/script efficiency.
Sample Data Validation
Picking either random records to validate or profiling samples of records to ensure more data coverage and then comparing those records to the same ones in the new system.
Subsets of Data Validation
Picking larger sets of sample records to validate (the first thousand records, for example, or sets twenty-five thousand to fifty thousand) to improve data coverage.
Complete Data Set Validation
The ideal way to validate data (though it’s essentially impossible), is to check all the target records to the legacy records and vice versa. Due to mapping constraints, however, this is pretty much just an ideal.
Issues can arise if the source data set and the target data set agree on the meaning of a field (Currency, for example) but not the units. While something might be €100 in the source dataset, it would be a mistake to migrate €100 as $100. Another issue might be decimal points. If the source data set has two places after the decimal point but the target data set doesn’t, important information could be lost.
An organizational risk more than anything else, interference risks result from people interacting with the system in a way that unintentionally disrupts the data migration process. For example, if someone is working in a table and they lock that table, no one else can interact with the table to perform data validation or perform count reconciliation, etc.
The solution, like the problem, is also organizational. Key stakeholders involved in the process should understand what is expected of them during data migration and to be mindful of the fact that normal work processes may be disrupted or need to change until data migration is complete.
Accurately migrating financial data to JD Edwards is a critical maneuver for any company involved in an acquisition. Obviously, migrating any type of data is important, but companies need to have a clear picture of their finances to know what their assets, liabilities, and equities are at the end of their financial reporting period, not to mention the financial condition of the company in relation to creditors, investors, and capital providers.
To help you with this process, Surety would be glad to connect you with our team of senior-level JD Edwards financial consultants.