0

My vanilla PHP backend app needs to be rewritten due to very poor design and lot of unstructured code. The legacy app is very large and the team small, so doing full rewrite in limited time is quite risky.

I need to introduce PHP framework into the codebase and as a result the design of almost everything will change (routing, database access, OOP, MVC pattern, code conventions, need for testability...) For this reason it's not worth to make incremental changes in the current codebase. I just need to start a new codebase and maybe reuse some parts of legacy code.

But now the question is what to do when moving all of the functionality into new codebase isn't feasible (due to time, money etc.) So I was thinking of simply rewriting only a part of the backend app, thus effectively splitting the app into legacy and modern part. Both parts would run simultaneously (at least for some time), sharing the same RDBMS and database schema. (I also consider writing the new app in different technology stack - like Node.js instead of PHP. It should not prevent the 2 apps from running simultaneously in my opinion.)

The best would be to decompose the app into easily separable modules. The core functionality however is large and coupled. It has to be (partly) implemented in the modern app, but also has to keep running in the legacy app. Therefore some of these functionalities will be redundantly implemented in both apps.

I admit the drawbacks of such solution:

  • team needs to understand and maintain 2 systems
  • business logic gets duplicated (entities, user roles, utility functions...)
  • operation logic gets duplicated (authentication, logging, file storage, emailing, i18n...)
    • some of these features could be implemented only in one app, and the other would just delegate it to the first one (necessary for authentication)
    • delegation could be done by REST API calls or communicating via the the shared database (e.g. first app authenticate the user and saves his session cookie into db., second app verifies it by reading from db.)

Should I still go this way, or rather take the risk of full rewrite?

(Benefit of the full rewrite is that it could introduce deep changes into database structure and app functionality, since the new version wouldn't have to be backwards compatible.)

1
  • This description of your situation sounds a lot more sensible than the reasoning you told us in the comment section of your former question.
    – Doc Brown
    Dec 9, 2023 at 11:48

2 Answers 2

5

What would the situation be if you did nothing - that is, neither split the codebase nor rewrote the whole, and just worked within the legacy framework?

It sounds like you don't have the resources for a full rewrite as a single unit of work, so there will have to be some kind of transition process if you introduce this modern framework.

Can you realistically transition the codebase (from legacy to entirely modern) with a reasonable amount of effort within the likely tenure of your employment?

If so, you might want to proceed with the transition if the new approach would show real benefits.

If you can never make a complete transition in a reasonable time, then with your current proposal you face leaving the codebase in a condition where it has a confused mixture of legacy and modern.

I would only risk this if the "modern" framework is either doing something important which the legacy part absolutely cannot do, or if the simplicity of the modern framework is simply overwhelming compared to the legacy approach.

If you add additional frameworks and cause permanent confusion in the whole without substantial justification, it's really just a form of vandalism, and you're very likely to leave the code in worse overall condition than you found it.

2

In my experience, replacing an old system by a new one incrementally in parts (which are brought into production), whilst keeping a common database, is a lot less riskier than trying to rewrite a system from the ground in one step. It may be actually the only working approach for lots of systems and teams, and from what you wrote I guess your system and team could fit into that category.

I think Steve is right that you should be extremely cautiuous before making a decision to go that route, and that your end goal should be to replace the legacy code in full. Still isolating a certain part of the application, reimplementing it and bringing it into production will give you useful feedback how much time and effort the whole process will require, allowing you to make a better estimate for when the full transition will be completed (or - if it may be better to stop the project).

One thing to consider here is indeed how well it is possible to decompose the app into separate, replaceable modules. Obviously, you have to evaluate this yourself, this is nothing we can help you with.

Let me finally add several years ago I was also in the situation to replace an old desktop app (~200K lines of code plus some unmeasurable BLOB of 4GL components.) Half of the application got rewritten. Especially the 4GL parts were an almost unmaintainable mess before, without the possibility of using text comparison between different versions / commit. The other half was ported to a more modern technology, but saving most of the existing code.

The whole process took us around seven years and it would not have been possible if we had not done this incrementally, releasing regularly new parts, even when those parts had some overlap with the old ones. Since then application has evolved a lot based on the new technolgy (which has not been possible on the old one), it is used very successfully by a growing user base and the rewrite/port, though taking us a lot of time, has proven itself to be worth it. So if you think your situation is comparable, go ahead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.