Skip to main content

Reasons to address application modernisation and migration


We are increasingly finding that inherited/old/legacy IT systems are becoming an obstacle to the digital transformation of businesses. Many customers come to us to ask how they can adapt their existing applications to meet the current needs of their business. For this reason, we are going to publish a series of articles in which we will provide you with some tips for modernising and migrating applications.


These posts will be based on projects undertaken by Xeridia mainly in the financial and insurance sector. However, there is no doubt that the ideas, approach and experience can be used by customers in any sector, as this is an activity that clearly applies across the board.


And without further ado, I'll get straight to the point. Below, I have grouped and described the most popular reasons why our customers ask us to assist with this type of project. The requirements for modernising and migrating applications usually come from the IT teams themselves, and not from the business units. I will therefore describe these reasons in detail to promote greater understanding.


  • Obsolescence of languages and tools, both in-house and third-party, integrated into the customer’s development and operational architecture.

IT vendors are constantly upgrading their products with new versions that leave the oldest versions without updates or support for potential problems, such as security incidents. Here are some examples of application modernisation initiatives that our customers have requested to avoid this obsolescence:


  • An old solution for creating financial terminal applications that the manufacturer no longer includes in their catalogue and therefore no longer updates.
  • An application that was purchased to serve a specific business need and used a language that was non-standard for this customer. This language was only used by this application, whose maintenance agreement had also expired.
  • A technological change in terms of programming languages, made by the customer, moving from C to Java.
  • A customer who needed to stop using an old version of Visual Basic.
  • An extreme and somewhat anecdotal case involving a customer who, a few months ago, asked us to quote for migrating from the RPG II language, which he felt provided him with very few opportunities for digital transformation.
  • A piece of software that was an important part of the customer's application development architecture, and whose manufacturer announced its end of life. In this case, the customer asked not only for an alternative tool and the associated migration, but also for the programmers’ interface to be exactly the same to avoid any loss of productivity in the programming team.


  • Bringing an application that has functional value into a new technical environment.

Our customer has an application belonging to corporate IT systems that provides a very important service, for which no one in the business requests improvements and which was on a problematic platform (cost, performance, obsolete technology, etc.). In this case, the migration included significant involvement from the Systems team.


  • Simplifying the technological environment, for example by reducing the number of databases or operating systems used.

Our customers usually make their decisions with the aim of simplifying their technological environment. But this is not always possible and, as time goes by, this simplification, if desired, has to be done through specific projects that require our support.

Reducing the types of databases or operating systems being maintained will significantly reduce the associated costs. And it is common for this reduction process to involve application migration.


  • Difficulty in having the right skills to create or maintain applications, in the short or medium term.

There is no need here to fall back on the well-documented problem of having COBOL programmers available for mainframe environments. In most cases, we find that our customer does not want or cannot have people dedicated to specific technologies. Sometimes they do not have the people, full stop; at other times the customer may not see any benefit in dedicating people to this technology, either because it is a minority technology or because it has no future for them in the medium term.


  • Missing documentation.

We have included this type of request within the scope of application modernisation. We provide the customer with a set of automated analysis routines that output a lot of information, including details on dead code and uncalled functions, resources for understanding the code and proposed application structure. This data can be an end in itself, or it can be the starting point for a migration process.


  • Problems with the performance or resource consumption of a specific application.

When a customer comes to us with a performance problem, we typically use specific analysis tools to solve the problem in the short term and monitoring tools for subsequent follow-up.
However, sometimes the solution is to modernise the application by changing a certain component or migrating it to another platform where resources are cheaper and more readily available. We also include improvements to development environments in this group.


  • Cost reduction.

I don’t want to pull the wool over your eyes: in most of these types of projects, our customers either have a significant technical problem or are interested in cost reduction.


Xeridia's offerings include current and future technical improvement of migration and modernisation projects, and an optimum financial cost. This approach, rather than focusing exclusively on cost reduction, helps our customers with the internal sales process for their projects

On a positive note, in virtually all projects, this optimum cost has led to a drastic reduction in the current cost of ownership. By using other platforms, by eliminating or reducing language ownership costs, by changing tools or eliminating their cost, by automating our migration processes as opposed to using more manual methods, by reducing resource consumption by improving performance, etc.



In upcoming instalments, I will highlight some features of these types of projects, include some significant examples and share the lessons learned at Xeridia by delivering them.


At Xeridia, we can help you with the modernisation and transformation of your applications, and we give you a great reason to take on these projects: they are technically, functionally and economically viable, and can be carried out while fully managing the associated risks.



is Head of Financial Services Consulting at Xeridia