Data Migration from a Legacy ERP
When there's nobody who understands your old data, and you need it for the new system.
Challenge
A company was using a legacy version of Epicor ERP, and their parent mandated a move to another system. There was nobody in the company who knew how to extract the Epicor data in a form the new system could use.
Outcome
The implementation was completed on time, with all the data approved on the way.
When Farécla Products Ltd got in touch, their parent company required them to move from their old Epicor ERP to the standardised one the other companies in the group used. Implementations are often triggered by something like that.
The problem
There was nobody comfortable with Epicor's data, or who knew how to go about getting it out of the system, though.
Getting the data from one system to another is never as easy as it sounds. The assumptions and structure are usually different, and a successful transfer means understanding both, and working through the trade-offs of interpreting one in terms of the other in ways that users of the systems can understand and are happy with. Implementation teams know this, and are typically experienced in helping to make it happen ... but it always relies on domain experts within the company, since they know what's already there in ways that a team that's expert in the new system can't.
Those domain experts knew their areas but not Epicor. And as usual the team were stretched with their day jobs as well as the implementation. So we came in to help.
We were an exception in being willing to help, in fact, because it isn't good business ensuring that a customer has a smooth exit from the system you specialise in, so cases like this are tricky for companies. But there are advantages to asking a genuinely independent consultancy.
Making it even more complicated, the parent company's policies meant no third parties could have access to their systems.
What we did
The data itself was on a SQL Server database. Which we didn't have access to, or the system running on it.
So, one day, we signed for the secure delivery of a copy on a password-protected hardware-encrypted drive, and we set up a local server to work from.
We worked with the experts in the new cloud ERP on the defined shapes of the data they required, and had back-and-forth sessions with company stakeholders to find out how they saw that data in terms of what they'd been working with. Steadily, we refined SQL scripts that, when run, extracted the Epicor data and produced the new forms, testing them on our copy and then passing them to the in-house IT team to run live.
The advantage of doing it that way, rather than the more common process of extracting to Excel and then adjusting through spreadsheet formulas and manual adjustment, is that it's repeatable on demand, producing an up-to-date version every time. That meant the end-to-end transfer process could be tested, reviewed, and run again until everybody was happy with the results. The scripts could be modified until the final go-live, at which point everybody knew exactly what the results would be.
The outcome
Sometimes it's only over years that users discover errors and problems in the data after an ERP implementation. In this case everybody had complete confidence that they knew what they'd find as they switched.
"Thank you for all your help during the project, your knowledge of Epicor helped immensely and we would not have been able (with the skills in house) to complete the project, and your prompt response to all requests was always appreciated. Thanks for your professional and flexible approach to our project, it really helped."
— David Crossley, Farécla Products Ltd