Lack of Upgradeability: Legacy systems are typically older and may no longer be supported by the vendor. They are not regularly updated, which can lead to security and compatibility issues.
Business Critical: They are often critical to the operation of the business, as they have been developed over the years and integrate many business processes. Replacing them suddenly would be expensive and risky.
Difficult to Maintain: Legacy systems can be difficult and expensive to maintain. Often, their writing style is outdated and unreadable. Changes require a lot of debugging time.
Lack of Flexibility: These systems are typically inflexible and difficult to modify or integrate with modern technology solutions.
Security Issues: Legacy systems may have security holes that are no longer patched, exposing the company to the risk of attacks.
Dependence on Outdated Technologies: They may be dependent on technologies that are no longer used or difficult to acquire, making them difficult to maintain and develop
Pattern description: Embedded Parallel Models involves creating multiple models in one application at the same time. These models results can be compared, for example, taking into account different architectural drivers, choose the right one for your needs. Models can be temporary. In my case, this pattern was to enable gradual migration of data and functionality without interrupting the system, and comparing the results returned by the new model to what is returned by the old model.
https://martinfowler.com/eaaDev/ParallelModel.html
https://tinyurl.com/iteo-legacy-calculator
Detailed debugging of existing code
BDD approach to describing ECSO features
Identification of places where we can hook in to integrate with the old system via the so-called ACL (Anti-corruption Layer)
Debugging and understanding the old model
Extensive layer of functional tests using characterization testing approach
The goal of characterization tests is to help developers verify that the modifications made to a reference version of a software system did not modify its behavior in unwanted or undesirable ways.
We test all behaviors we want to rewrite in existing/legacy system even if behaviors seems to not working as we would expect from them
The Anti-corruption Layer (ACL) creates a layer isolating the old system from the new one, protecting it from potential “corruption” by unwanted dependencies and differences in data models. (Check also Bubble Context)
https://tinyurl.com/iteo-legacy-acl
Profiling with blackfire
Create new entrypoint in new Symfony application and move it on infrastructure layer (nginx proxy) - Stranger Fig Pattern
Rewrite old not performant entrypoints to new application, use event driven architecture with async messanger
Provide CQRS in some model parts, to be able to write performant indexes read model without changing write model
Method of gradually replacing the old system with a new one by slicing off and replacing specific functionalities. It ensures continuous operation and minimizes risk
In our case using infrastructure, we could redirect particular REST entrypoints to the new application.
Method of gradually replacing the old system with a new one by slicing off and replacing specific functionalities. It ensures continuous operation and minimizes risk
In our case using infrastructure, we could redirect particular REST entrypoints to the new application.
https://tinyurl.com/iteo-legacy-strangler
https://www.linkedin.com/in/leszek-prabucki/
https://phpc.social/@l3l0