Introduction

Rabobank is ambitious in the leasing market. For a bank, leasing assets is not only financially interesting, it can also help build long-term customer relationships.

Within Rabobank, DLL was a business unit that focused on factoring, leasing as well as vendor leasing. In 2017, leasing and factoring were integrated within Rabobank. With this, DLL focused entirely on vendor leasing.

To support the entire leasing process, Rabobank acquired leasing software from Liscor. The contracts of the existing leasing portfolio were migrated from DLL to this new environment. This involved more than 39,000 contracts.

In this article, we share some insights into this migration.

One team project launch

The project was a joint effort in very good cooperation between DLL, Rabobank and DX. What contributed to this was the way the project was launched: with the 'One team' project launch. A structured start in which in three sessions everything was gone through about working together, who does what, etc. This start contributed to the integrated team immediately emerging as a team. This worked better than the well-known 'just-jump-into-it' project start: a cooperation that starts with taking infrastructure hurdles and other hassles.

The good collaboration manifested itself in remarkably many socials. The game room was also put to good use in the project!

What makes the leasing domain special

Leasing is a form of lending, so in that respect there are many similarities with the lending domain. There are some special aspects to leasing.

  • Knowledge of the asset is important. The depreciation is an important aspect in determining the lease term. In the case of operating lease with services, maintenance of the asset is also included.
  • Exceptions are the rule. Leases have considerable diversity and complexity.

These particular aspects are reflected in the administration and can cause problems during migration. For example, how the target system handles impairment may not match how the source systems do. This may have balance sheet implications.

A dynamic project

In general, the challenge is greater if the migration starts while the set-up of the target system is still in progress. Of course, there can be good considerations for doing so anyway - and that was the case here!

DX coped well with these dynamics by using an iterative approach. Each iteration contained defined pieces of functionality and completed their migration from front to back. This ensured good anticipation of Liscor's ongoing implementation project.

An iterative approach is more costly than a waterfall (design-analysis-build) approach. This cost implication is factored into the choice of approach.

A three-step migration strategy

The migration was carried out in three tranches:

Inactive contracts

Started with the contracts whose lease term had ended. These contracts were necessary for reporting purposes.

Current contracts

The second tranche included many of the ongoing contracts. A number of difficult contracts were excluded.

All contracts

The last tranche included all contracts not yet migrated. This involved over 34,000 contracts. A limited number of difficult contracts were migrated manually.

DX chooses a multi-stage migration strategy in about 1 in 5 projects. The fact that a multi-stage strategy was chosen in this case had everything to do with the fact that migration and implementation ran in parallel. You can read more about the trade-offs in our manifesto.

It seems so nice: using views as a source.

Using a view as a source seems nice: instead of having to plough through all kinds of technical tables, nice views are available that have all the data available bite-sized!
And so it started: initially, available views on database tables were used as a source. During the project, this was partially abandoned:

  • The views were not sufficiently complete. It turned out that we needed more information than the views offered.
  • The available knowledge (documentation, people) was not in sufficient supply to deploy the views effectively.

Tip: migrating based on views is fine. But take note:

  • Is the information in the views sufficiently complete?
  • Are the views documented completely and up-to-date?
  • Are people with sufficient knowledge available?

So set the same requirements for views as for database tables.

Want to know more about lease migration?