Core conversions are never an easy process. It takes months of work and planning to successfully convert a credit union. For those of us on the programming end of things, there are a lot of steps to go through and challenges to overcome in the short time before a conversion goes live. Personally, I like to think of the conversion process as putting a puzzle together. Programmers work closely with the coordinators, take the pieces from a current core processing system, and place them into the new processing system. For those of you not on the programming end of things, here’s an inside look into the conversion process from a programmer’s perspective.
How we accomplish a conversion:
Collecting data and making a plan
Before we can truly begin the conversion process, we must receive the first set of test files, along with reports, from the credit union’s current core. There are two situations: if we have converted from this core processor before, we import the files and verify that we received all expected files and check for any new ones. We also analyze each file to see if there have been changes since the last conversion.
If we have not converted from this core before, we then look at the data to make sure it is in a readable format and start creating what is needed to convert from this core processor. If we have any difficulties in trying to read the data we receive, then we will be in contact with the credit union and possibly the current core system to help us out.
Once the programmer has the files uploaded, the coordinator can start to look through them and start work on what we call the Data Conversion Plan, which is what the programmer will use to convert the data.
Next, the coordinator and programmer perform a test run. This is where the programmer will run their process to convert your data into a testing environment and the coordinator will verify it, similar to what will take place on live conversion day, when the credit union is officially switched to their new core. Performing this test run allows us to uncover any issues that might occur during the conversion, allowing us to fix them ahead of time. Typically, we will do two to three test runs depending on how many sets of test files we receive from the current core.
We then start to look at third-party vendors: ATM or debit cards, online credit cards, ACH posting files, draft posting files, bill pay, and any other third-parties you might currently have. Some third-parties might require us to send them a file that contains the old account number and suffix along with the new account number and suffix for them to run a conversion on their side. If they do, then we will typically send them a test file and then what we call a renumbering file on live day which contains the old to new account numbers.
The next step involves training the credit union on their new core system and how to use it. About a week before training is set to begin, we create a training environment in which the credit union can see their data while training and do data validation in order to find things the programmers might have missed that are not correct. This is vitally important. If we are inputting incorrect information, the information coming out will also be faulty. Or, put much more simply, “Garbage in, garbage out.”
Some of the challenges that we face could include:
We often run into issues with how different names are entered into the system. One person might enter names in one format while another person enters them differently. If the current core member names (first, middle, and last) are all in one field, we need to split that one field out into three separate fields: first name, middle initial, and last name. Though it’s a pretty simple task, doing it for thousands of members can be very time consuming.
Existing core settings
If the credit union’s existing core didn’t require them to have membership shares, but the new core requires a membership share for every account, then we would have to create a membership share when one does not exist.
We have also run into situations where the membership might have an open date greater than the open date on a share, draft, CD, or loan which can cause issues. Therefore, we have to change the open date on the membership to be before any of the accounts.
Whenever you introduce another business into the mix, things get more complicated. Third-party vendors can be challenging to work with when their timetable is different from ours. This can mean setbacks in getting necessary data or information from them.
Sometimes we get questions from the credit union as to why we need a full set of files with every test set or why we need the test files to come from a static environment. The reason is so that we can make sure we are converting the data correctly by balancing the data to the reports that we receive.
If the files are extracted at a different time than the reports, it is possible to have balances in the files not match up to the reports. If you are extracting data from another source outside your core, those files still need to be at the same time as your core files as they are something linked together on our side.
Once we get to live weekend, the credit union will have had two management configuration sessions and we would have all the programs ready to go. We will receive the credit union’s live files, the programmer will run the necessary programs to convert the data, the coordinator will verify the data converted, and we run the first Beginning of Day. Then, the credit union will go through a critical sign off where the coordinator provides information on what was converted and they give their approval.
The programmer and coordinator do their best to interpret a credit union’s current core to convert into the new core, but sometimes we don’t always have it correct. If you are a credit union going through a core conversion, remember: you know your data the best. The more you can validate during the testing period, the smoother your transition will be.
Going through a core conversion or considering one? Melissa Robinson wants you to keep some things in mind during the process.