Technological obsolescence projects: migration or reengineering?

Technological obsolescence projects: migration or reengineering?

Technological obsolescence can bring several problems within an organization. In that case, implementing transformation projects such as migration or reengineering are two kinds of solutions. Which one is best? Discover it here.

Technological obsolescence projects migration or reengineering

Technological transformation projects have become increasingly more popular in the IT industry. Technologies such as Visual Basic and Visual Fox Pro that were used to develop systems 15 years ago have completed a cycle and a technological upgrade is necessary.

This upgrade is critical not only for technical reasons, such as older languages, platforms, data structures, and support but also for several major problems in the companies, such as process recruiting, the possibility of integrating with other businesses or technologies, and adjusting to changes in the market or the users’ needs. These situations can be classified into distinct patterns of problems: technical, recruiting and retention, UX, and maintenance. 

Technical problems  

The maintenance of software is very challenging with obsolete technologies. The documentation and support are limited, and the design of the solution is possibly old, with initial requirements being very different from the current conditions after 15 to 20 years. Generally, the languages are procedural and use old constructions and practices. Frequently, they are desktop solutions or vertical architectures running over mainframes. In addition, now there are many requirements of external integrations, and usually, the solutions with obsolete technology do not have the facilities to resolve it efficiently and require a lot of effort. A similar situation happens with scalability requirements. 

Recruiting and retention problems

Solutions with obsolete technology require professionals with specific knowledge in technology outside of the market, and they are very hard to find by HR. There is a revolution in new technologies, such as Mobile Platforms, Micro-service architectures, SPA solutions with Angular/React, Data Sciences, IoT, Game Development, etc., and professionals prefer to work with them. Retaining professionals in the IT industry who work in obsolete technologies instead of new ones is very hard. It is necessary to be creative to keep or employ them. Generally, their salary is higher than those professionals with knowledge in other new technologies.

UX Problems

Now, the final users are sophisticated. They use several solutions on the web and mobile platforms. Unfortunately, the new visual patterns or interaction patterns are very hard or impossible to develop with obsolete technologies. Any solution requires a lot of effort, and the final result is far from ideal.  

Maintenance process problems

Generally, applications with 20 years of maintenance with different people generate solutions with known anti-patterns such as complex code (spaghetti code), high cyclomatic complexity, no modular design, limited documentation, or few specialists in the solution. These problems affect the on-time delivery and the quality of the final solution. Therefore, it is a real problem with a very high cost. 

unLgyY PrWRFUAQXUdEbVCoBUNf7z9Rd2ONgEf6D28xgXQD2YmZ59l hFMXDbbUoEXoosdf vE9qAh1i4uPNX17209w iotravf8p4 bmZ WPmiRElVFDh4AV4yIRIk5mqyfZJY L NkbdCXjC8

The companies that have these problems need to evaluate the need for implementing transformation projects. There are two kinds of solution strategies for those implementations: migration and reengineering.  

  • Migration strategy 

The main idea of this strategy is to make the fewest necessary changes and only modify the technology from an obsolete one to a new one, for example, from COBOL to Java+Angular or from Vfoxpro to .NET+React. It is a process with many advantages and risks. The languages are widely different, and it is impossible to migrate them line by line. The result would be a disaster, for example, migrating software with structural programming to object programming.  This effort could be a waste of time. The maintainability and extension in the new solution is hybrid, with logic coded originally in structural programming and applied nowadays in objects, without having to think about and design the best approach using the tools of the paradigm. 

  • Reengineering strategy 

The principal idea of this strategy is, apart from changing the technology, to redesign all the main processes while collaborating with final users and product owners. Additionally, it has advantages and disadvantages, such as process analysis strategy, testing and deploying strategy, the initial baseline, and its evolution. 

The reengineering process is a tough job but comes with great improvements. Not only has the technology changed, but the solution is likely re-thinking it and using new patterns of solutions. The effort is an investment in the future, and the key is to analyze and divide the solution into an incremental project with tiny pieces of software running and add on solutions little by little. 

This approach is harder with microservices Solutions. Migrating is impossible to think about in microservices; however, with reengineering strategies, this may be possible, but it is certainly not very easy. 

8muNKVxJyuSo2cNHEzQ4YheTUiR7cUKVuPQZqQ3aQNV8J9zp730BwaQeKvij33rBR7 AkC 2mP7AGY4OTtUFEstytDr wXDWKOqkhj

In conclusion

Nowadays, the migration strategy is a bad decision with a lot of problems in the short-, mid-, and long-terms. The solution would be to think of smaller solutions from the reengineering approach and try to divide the responsibility into microservices (pure or hybrids). In a real-life scenario, it is not always possible to implement the theory, but it is extremely important to head towards that north.

Stay tuned for my next article where I will tackle the transformation of the reengineering strategy from monolithic to microservices using very well-known and documented patterns, like the strangler pattern, refactoring architectures, solution from scratch, FTGO application, and the database per service pattern, just to mention some of them.

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.