Skip to main content

Characteristics of application modernisation projects


Following my first post on the reasons that lead our customers to consider application modernisation and migration projects, in this second post I will summarise the characteristics that are common to the projects that Xeridia undertakes in this field.


If I had to single out just one characteristic, it would be automation. Although there are cases where full automation is not possible, it always plays a key role in the approach to this type of project. This results in a high-quality, uniform solution that is verifiable and cost predictable.


Running the project in technical assistance mode is a bad option because this requires more time, involves more of the customer’s teams, increases costs and affects quality, which at best will not be uniform.


Something akin to an “industrialisation” approach, where activities are standardised and certain technological aids are incorporated into the migration, is also often not sufficient. Parameters are being improved with respect to technical assistance, but an ironclad discipline around management and execution is required to guarantee minimum standards in uniformity and quality of the resulting product.


It is not always easy to “measure” the degree of automation in this type of project. One criterion that can be used is the involvement of the customer's development teams, which should be low. The most highly automated projects are run in conjunction with an Architecture department, with the customer's development team providing high-level, mainly functional support.


I have detailed below other characteristics that crop up frequently in this type of project:


  • Project and application inventory

Most projects have a long preparation and analysis phase that is undertaken by the customer. This phase should include pilot studies. Certainly, the knowledge gained from these preliminary phases is highly desirable, as is involvement from the supplier to provide the required functional profiles.


In these early stages, an assessment phase will look at the inventory of applications to be modernised or migrated, including all their components, not just the main ones. An incomplete inventory will increase the time and cost of the project and may lead to its non-viability.


  • Technological tools

Although the suppliers usually have tools used in previous projects or have other more general tools, these will always have to be tailored to the needs of the specific project. Given the usual concern from customers regarding the cost of software ownership, the use of Open Source tools is often proposed. However, we should not be dogmatic and should instead use the tools that are best suited to the migration, especially if the data being processed is in demanding transactional environments.


It is also not uncommon for projects to include some tools for managing the new platform. A forward-looking approach will fit in with or help other customer strategies, such as DevOps.


  • Iterative process

Running migration processes usually requires several iterations. The tools are tailored to the specific project, applications are converted, problems are detected during test processes, further adjustments are made to the tools, etc. The outcome from these iterations covers almost 100% of the requirements, although there is a reliance on factors such as,


  • The quality of the source platform’s architecture and the knowledge about it within the customer’s teams.
  • Effective monitoring by the development teams of the standards defined and/or required by this architecture.
  • Knowledge about the target architecture, which should always be extensive. Usually, the target architecture is better understood by the customer and has been documented more thoroughly.


  • Management of migrated applications

Customers need to have control over their modernised or migrated applications as well as the ability to change them. There should be no dependencies forced upon the supplier who carried out the process.


The automated processes and tools used should not generate code that cannot be understood by the customer’s technical staff, or any other strange situations for that matter. This, together with the project documentation and if necessary customer training, will allow the migrated applications to evolve and be maintained.


Some projects start with an initial lack of documentation and a lack of functional knowledge about what needs to be migrated. Migration processes should include the necessary documentation that will normally be accessible through browser-based systems.


  • Performance

There is one hard-and-fast rule: the performance of the modernised solution must always be the same as or better than the old solution. All projects, but especially those that modernise or migrate the data management system (files and databases), will include performance optimisation.


  • Risk control and monitoring

As in any other project, and even more importantly in cases where no functional improvements are obtained, a risk analysis and associated mitigation measures will be made available from the outset. A well-defined set of objective indicators will allow project progress to be closely monitored.


If the characteristics of your project are consistent with some of those described in this post, Xeridia can help you with modernising and transforming your applications. We have the best teams and the right experience to assist you.


is Head of Financial Services Consulting at Xeridia



Designed by vectorpouch / Freepik