Asset finance software: Migrating legacy data without making a mess

The big challenge for many finance organisations is making sense of their legacy systems. Many have had their system in place for 10 or 20 years, perhaps more. There might be products in there that they no longer offer. Regulatory changes have come in impacting their old data, making it non-compliant. They might have client portfolios on there from an even older system or perhaps purchased from a third party. Quite often the data isn’t as fully fleshed out as is needed in today’s world. So, finance organisations need to work out what data they want to migrate and often they’ll have to be very pragmatic to do it effectively.

Users are nothing if not creative. When a system doesn’t fully support user processes, teams will find ways of bending them to fit. This might involve entering dummy values to clear validation on a property they’d rather leave blank or ‘overloading’ a single property with multiple business meanings depending on the value or context. Combine these often-undocumented use cases with unintended issues such as incomplete or outdated addresses, typos and system defects, and the cleansing task could become quite involved.

Most important is to recognise that data migration isn’t just the lift and shift from one place to another. The tech guys can’t just do it on a whim. The most successful migrations are the ones where a business sees it as more of a cross-functional exercise that includes your finance and accounting experts and some business experts who are going to help interpret what that data is supposed to mean and therefore what it should look like in the new system. Having that team in place means having experts on hand who can tackle difficult questions and keep things moving.

For acquisitions, the format and quantity of data is agreed at a high level, but the finer details of data quality are probably left for the implementation team to uncover. I’ve even seen a scenario where the purchase involved a guarantee of no loss-making contracts only to discover that there were several of them in the portfolio provided. That finance director was less than pleased to hear the news.

Much of this analysis is likely already being done somewhere in the business, so it’s often a case of talking to the right people. Understanding the ‘shape’ of the data, such as relative volumes of different products and geographies or contract status and age banding, isn’t a migration-specific requirement. There’s probably existing management information (MI) reporting within the business that can be leveraged to get a high-level view.

Similarly, when looking to identify data that may need cleansing, there’s no need to reinvent the wheel. The first port of call should be the list of any open support tickets relating to the legacy system, as they’ll be a great indication of potential problem areas in the data. Talking to experienced business experts that use the legacy system day-to-day will also reveal a lot about challenges in the existing data. Inevitably, some ad-hoc custom reporting will be required along the way, but answers to many of the big questions are probably already out there if you know where to look.

For the mapping exercise, the key is to remember that the goal is not to take every data item and find a home for it in the new system. The goal is to identify the appropriate sub-set of existing data to migrate to support future use cases. There will be redundant data that can be excluded, and it’s here that a good understanding of future processes, and the real-world meaning of the data, are essential.

For me, the two main drivers here are accelerating the delivery of business value and de-risking the overall delivery. Large migrations will likely involve several associated dependencies, be they complex mapping or configuration exercises, system enhancements or integrations. Where these dependencies only block sub-sets of the portfolio, why keep the rest of the population waiting? Where it’s feasible, the business can start getting the benefits of having the simpler subsets migrated sooner. This also then serves to familiarise the business users with the new application and ensure any teething issues in the landscape are discovered and addressed before they risk impacting the full volume of contracts. Lessons learned from small, early deliveries can constantly feedback to improve data quality, mappings, and configuration for future phases.

There’s always a possibility that it just makes sense to do this manually. For some clients that have a very small pilot phase or have just acquired some dataset, then perhaps the most pragmatic thing is to just key them manually.

For the middle-tier of volume and complexities, we look towards an integration-based approach, either building integration from another system or some form of upload, like a spreadsheet. That can then make use of the rich web service API that Alfa Systems has on offer, and it will be much quicker than a manual entry. Once the integration is in place it’s available for repeat use and can be quite effective, particularly for acquisitions.

For higher volume and higher complexity where you want data to look functionally rich, the tool we propose is the Alfa Migration Suite, which makes contracts look like they’ve been in the new platform from Day One. So, you’ll have original start dates, origination charges, the payment history, historic invoices, summary details of any historic changes in support, or on the historic credit reference information — and a lot more. It’s very powerful.

The ability to build some flexibility into your project is important. What if the priorities of your project change? What if you need to pause the project? Go after a different acquisition? Having these agile approaches helps you to be more flexible, helps you pivot to different market conditions, or prioritise other areas of the business without having to invest in a ton of work for no reward. A considered approach to software migration allows you to release business value periodically and then pivot and go after different elements. That’s key for challenging economic conditions.