“Everything simple is false. Everything which is complex is unusable.”
As we have seen in the previous posts, the modernization can be performed using different approaches and techniques. We have also seen that it always starts with the exploration, analysis and understanding of the existing legacy source code before initiating the transformation itself. Whatever the size of your application is (hundreds of thousands or tens of millions of lines of code), a mature product is needed in order to accelerate the whole project, limit human errors, build and share a knowledge repository, and setup the project basics without the need of deep application-specific expertise. In other words, before contracting a project, ask for a product demo or even better, ask to test it by yourself (if you have qualified teams). That is said, the product will not do the project by itself and qualified people are needed to successfully run the project.
Tip: Most of the modernization actors promote proven products and methodologies. One simple way to verify their assumptions is their ability to get back to you with initial insights about your source code within a few days (hours!), not weeks. Actually, if they don’t have the tools to explore the code, they probably don’t have the tools to transform it.
A modernization project needs products that have been developed, tested and approved specifically for your source legacy environment (languages, database, scheduler, etc.) and your target modern environment (languages, frameworks, databases…). In other words, the tools have to be able to read the legacy application and to produce the modern application while preserving the business rules and the data integrity. You will also need other more common tools to manage your project, define and run test scenarios and manage a CI/CD pipeline.
Unlike classical software projects -usually initiated from scratch- modernization projects start with millions of heterogenous lines of code to be explored, understood and transformed. In fact, the deep understanding of the legacy assets to transform is one of the key steps to building a successful modernization strategy. Without having a clear understanding of your legacy source code you’ll not be able to build a strong and realistic project roadmap! Thus, before you even do anything, ask for analysis tools demonstrations that are able to swallow your assets, examine all inputs, extract added value details out of the overwhelming amount of information… These insights should include the detection of the programming languages, the number/percentage of lines of code per programming language, the number of lines of code, entry points (start of transactions, batch chains…), direct and indirect dependencies through data, calls, main programs, isolated programs, static and dynamic calls, etc.
Unless your modernization partner has proven automated tools and hands-on experience with all parts of a modernization in actual use-case context, the learning curve will be steep and the project will be jeopardized before it even starts.
Tip: Graph-based tools are a very good option when it is about displaying thousands of items (files, data…) and their dependencies.
As you can imagine, the paradigm gap between the legacy environment on one side and the modern on the other side is huge. It is not about rewriting all the code from one technology into another but rather about keeping the accumulated business rules and getting rid of the other technical components.
Understanding, extracting value and transforming millions of lines of legacy source code is not a simple task, especially when the performance and accuracy of the results are not an option (see next paragraph). Doing it manually is expensive, error-prone, complicated and may lead to personal interpretation of each statement.
So, ask your modernization partner about his transformation products: what are the supported languages, how they are transformed? What are the supported target platforms? How many lines of code can be transformed per day?
Ultimately, as a customer, you don’t have to care “a lot” about what is happening in the back end of the product. You want the solution that powers your transformation project. Actually, you can define patterns to be respected for the modernized applications (e.g. naming conventions, number lines of code per class/function, inheritance management, etc.) but understanding the complete process of how to get there is not important to succeed your project. However, you need to be able to automatically check that your patterns are respected at each delivery and for the whole modernized application. Consequently, your modernization partner has to provide such tools/environments to let you verify the compliance of the transformations.
In most cases, your data should be migrated from legacy databases or files to relational databases. Your modernization partner should be able to perform such migration without losing data and without making wrong insertions.
From another perspective, your modernized application will use the migrated data in order to reproduce the exact same behavior as the legacy application using the original data. This means that you should be able to run both of your applications (legacy and modern), generate data from both of them and compare the two outputs (e.g. Compare compressed flat file with a relational database).
Ask your partner how does this comparison will be performed. Does he have a product for this? If yes what are the supported formats? Ask for comparison samples with performance metrics (i.e. how much time do I need to compare 1GB of data?). Actually, when you will have to manage hundreds of GB to be compared, you need efficiency and high performance.
This is one of the most important phases of a modernization project. In fact, testing the modernized application should be tackled as a top priority. This phase relies upon two important success factors: Tools (automation) and inputs.
Your modernization partner should be familiar with manual and automatic tests leveraging CI/CD environments (GitLab, Jenkins…) and other testing frameworks (Selenium, Cypress…). A detailed report of the different test scenarios and their status during the whole lifespan of the project is not an option. In a very simplified way, all your test scenarios should be successful at the end of the project, otherwise your modernized application will not behave as the legacy one.
Your modernization partner needs inputs from your teams (technical teams and end-users) in order to be able to compare the outputs of the legacy application to the modernized one. For example, they need the generated data after running a series of batches, a user scenario to validate the displayed data when a screen is filled with a precise list of information, etc. Without such detailed inputs, your modernization partner will not be able to fully cover the testing of all the modernized source code.
If you want a successful modernization project, share quality inputs (detailed reports, detailed user scenarios, videos, etc.) to let your partner know exactly what is expected while running your application.
Thousands of files, millions of lines of code, 2-5 different legacy programming languages, dozens of team members (Testers, Developers, Architects, Project Managers…) both on your side and your partner side, deadlines, 6-8 different tools, etc. These are the artefacts to be organized, shared and managed to run a modernization project during months or years. Classical project management tools are not suitable because they do not consider the main input of a modernization project which is the legacy portfolio.
You need an all-in-one solution that build a transparent, collaborative and integrated ecosystem to run your project. Without such solution, the learning curve on your side will be steep and the project time-consuming.
Ask your partner on his management approach. If he starts talking about Excel sheets, Trello, Asana, MS Project or any other tool such those, run away or ask him to look for a true project management platform for modernization projects.
A proven methodology is an identified and tested way your partner will propose to go through your modernization project without hassle while proposing all the aforementioned products (which are ultimately the project phases). First and foremost, the methodology should adopt an iterative and incremental process. A modernization project needs to be organized as a set of iterations based on the whole application analysis. Such iterative process allows testing phase to begin early in the process and continue throughout. This way, functional equivalence and adequate performance can be assured long before the application finally goes live.
The methodology should offer a visual, collaborative and transparent way to allow all stakeholders to see the progress, the achievements and the test results at a glance. In other words, project metrics should be permanently tracked to allow a better project management on one side and to celebrate achieved successes on the other side.
A stress-free modernization project is divided into iterations (an iteration is related to a core feature or a whole application). Each iteration is composed by a set of work packages (small groups of programs technically dependent). Each work package has one or many test scenarios to validate its correctness.
Being able to see all these artifacts in a simple way while keeping an eye on the status of each file (modernized, in progress, tested, not assigned yet…), each test scenario (automated, tested, validated, etc.) and each iteration (start, end, scope…) should be easy and flexible, otherwise your project will shift to a nightmare.
At this stage, you should have a better vision of what a modernization project looks like as well as a better understanding about why it is not only about technical transformation. Many tools have to be leveraged to run the project. For this reason, limiting the number of required tools is important to avoid the risk to get lost in your own processes, and you should probably ask yourself this question: can my project be led using a limited set of tools (at least on my side)?
Obviously, the “all-in-one solution” for the whole project is not feasible, but gathering a large part of the project within a single application is possible. Why does this matter? Reduce friction for you, no learning curve… Friction is the enemy of scalability (i.e. it costs money for you). It slows down lightweight processes and can cripple larger decisions. And, crucially, software that creates friction for its users is just unpleasant to use. Thus, you measure by this all-in-one solution test how good is you modernization partner in building products within a customer perspective in order to enable your teams to do their jobs more efficiently without hidden costs. That’s why the one-solution is so important. Transparency, Collaboration, Iteration and Automation are the pillars of a modernization project.
No setup. Free trial. No credit card required.