How do you change technologies in a long-term project?

Question

Project management

There is an enterprise management system in which everything - billing, customers, employees, managing third-party services, accepting payments, etc. The system was developed over 10 years ago. In order to keep up with technology, we periodically introduce something new, but the old one still comes as a burden, since it is unrealistic to redo everything, but often you have to refine it in the old code. As a result, we now have 2 frameworks on the backend - the ancient CodeIgniter and the not-so-new Symfony, which turned out to be not quite suitable for us. On the front end, a mixture of regular pages + jquery with a new interface based on Angular 1.3. And 3 different designs. It all works, and it works more or less well - there is a clear understanding of where to finish what in which case. But due to a bunch of technologies, development is slower, in addition, some opportunities are not used or are not used to the full extent. I want to clean it all up so that everything is monotonous and as transparent and modern as possible.
Do you have experience of changing technologies in large projects? Tell us about your experience, how did you sort out such a pile?

Answer 1

1. A module is selected in the system
2. A copy of it is created on a new system / technologies
3. It is debugged, configured, adapted for the main one.
4. Old - disabled, new - included in production.
5. GOTO 1.
PS: In no case do we single out microservices! This will violate the integrity of adjacent architectures within the system! We change - only with functional blocks that work according to a predetermined and well-established business process scheme.

Answer 2

Start extracting microservices from the main application.
In the long term, maintaining such a system will be easier than a monolith.

Answer 3

the online store was written in joomla, then cms was replaced with codeigniter 1.x, then with codeigniter 2.x, now it is planned to switch to frameworkless.
In fact, each shift, as a rule, took place with a pool of large tasks, design changes, implementation of the admin panel, etc.
New tables were created, old data was migrated to a new table structure. A list of main pages was created and what should be, how it should work, to check after the migration. A new sitemap was created, redirects were configured from old pages to new ones.

Answer 4

One can only add that technologies are changed by the willful decision of the project manager.
At the same time, of course, the manager should have an idea of ​​how long it will take, which employees will be loaded to what extent. Those. will have to juggle the implementation of new functions and the correspondence of old ones.
Or agreements are reached on a break in the implementation of new functions until the old functionality is ready.
Until a decision is made on the need for a transition and some kind of transition plan is drawn up, this will all drag on.

Answer 5

It is important to write an API for interaction between modules. Sometimes you have to make proxy layers to change technologies via API.
Everything else is simple.
A small module is being changed.
In particular, microservices are suitable for this.

Answer 6

To change technologies, 2 main resources are needed: money and time. And time is also converted into money. In order to get these resources you need to:
1) Clearly understand the purpose for which you are going to do this.

I want to clean it all up so that everything is monotonous and as transparent and modern as possible.

- that's not the goal. A reasonable person will not allocate resources for it. Everything will remain as it is until another goal is revealed. Examples of valid goals in this case: a) Reduce the cost of product development b) Reduce the cost of quality (this is the case when the technology zoo does not allow maintaining quality at the proper level).
2) Depending on the goal, you will have to make rough calculations: to evaluate by expert means how many losses due to old technologies you have per unit of time (day, week, month) compared to as if all this had already been written in a new way. Losses can grow over time. Put it on the timeline - get a graph of savings.
3) Calculate the investments required for a technology replacement project: design, rewrite, integration, testing, documentation, management, training, etc. Make a project schedule, including necessary funding.
4) Match the savings schedule from the start date of its receipt with the investment cash flow schedule. Provide a risk analysis for the "redo" and "leave as is" cases. Then the sponsors of the project will conduct the usual analysis of the investment attractiveness of the project and tell you whether the game is worth the candle.
5) If they do not give money, change the approach to rework and repeat the iteration, starting from step 2.