We all know that selecting and deploying a contract management system (CMS) for your finance business is most likely going to be a long, and at times painful, undertaking. Whilst many vendors are working hard to improve and accelerate the implementation process, by its very nature it is difficult to find short cuts: many tasks necessarily need to be carried out sequentially and take a certain amount of time, and the most time-consuming of all, as well as the most commonly underestimated, in terms of both duration and human effort, is the portfolio migration.
… is perhaps the most polite way of putting it.
And technically, the "garbage" is better known as data.
The larger, older, and more diverse the portfolio, the greater the chances of data inconsistencies, and as with many humans, the more numerous the wrinkles are likely to be!
Many businesses only "remember" some of their more historic milestones and events after a migration attempt has failed. It could be that the business acquired part of its portfolio, possibly even already migrated it (at least) once, and in the meantime has forgotten the workarounds or re-labelling that took place, "just that one time". Or there's that marginal product that was quietly dropped in the mists of time, but with a couple of old contracts still live.
All of these features, and many more, mean that the preparation for the migration is critical to its success.
Naturally, this means effort with data cleansing. Still, it should also provoke a ruthless cost/benefit analysis and evaluation of the value of migration, especially the incremental cost/value of migrating the historical contract data.
There are also conflicting guidelines to consider. On the one hand, good customer/contract data recovery requires that you retain historic data, whereas on the other hand, data privacy dictates that you be prepared to forget customers after a certain period of time has elapsed.
In any case, it is one thing to retain the data and information – it might be prudent to do so – but it is quite another to migrate it all to your new system of record for new customers, with your current business channels and product portfolio.
But you still have options.
One option is to leave the existing portfolio on the original CMS and let the agreements run off to maturity, whilst only writing new business in the new system.
As well as avoiding the tricky migration design and development, where old deals of many vintages need to be force-fitted into the new CMS, this approach is almost always faster to market. It means the business (and its clients) can start to realise the benefits and efficiencies from the new technology, and users can see the advantages, process improvements and automation the new system should bring.
It removes the complexity and effort of testing all types of converted deals in all scenarios on the new system, reduces project risk, and avoids the 'big-bang' reconciliation and cutover that always seems to happen when your best people have booked a holiday.
The most common objection is the perceived cost of paying for two systems to do the same thing for different parts of the portfolio.
However, the speed of go-live with the new system and new business almost certainly means reduced project duration and reduced project costs.
There is also the human cost, with a certain subset of the user community, such as Customer Service, having to access both systems in parallel and recognise which one is correct for the customer they are dealing with.
Management information must be aggregated across the two CMSs, but this is achievable, and most reporting systems already routinely combine data from different sources into one view.
Another option is to dispose of the existing portfolio to a third party, either through a sale or an outsourcing arrangement. This approach has particular merit for non-core or legacy rundown portfolios. It removes a strategic and/or operational headache, avoids the ongoing dual-system scenario, and releases lending capacity.
Using this approach, the migration challenge literally 'goes away' and generates near-term cash flow.
Even if your preference remains to include a migration within your CMS implementation project, careful and realistic planning and scheduling of the migration component is absolutely essential.
And even if that planning foresees a "big-bang" go-live and migration in one, the planning of both elements must be sufficiently detailed and differentiated so that you have the possibility to decouple at a later stage in the project should circumstances change.
In the meantime, the alternatives above are worth consideration, particularly if maximum speed and minimum risk are your highest priorities.
As we've explored, the decision to migrate your portfolio to a new CMS is not one to be taken lightly. Each option – full migration, running systems in parallel, or divesting the portfolio – comes with its own set of advantages and challenges. The key is to align your choice with your business objectives, considering factors such as:
Whichever path you choose, detailed planning and execution are crucial. A well-thought-out strategy can help you navigate the complexities of CMS implementation, whether you're migrating data or adopting a different approach.
At Finativ, we understand that every finance business has unique needs and constraints. Our decades of experience in selecting and implementing contract management systems position us to guide you through this critical decision-making process. We can help you evaluate your options, develop a tailored strategy, and ensure a smooth transition to your new CMS.
We also offer the expertise required to assist clients in optimising their portfolios and cash flow through divestment and syndication.
Get in touch if you would like to know more.
