> I know a full rewrite is necessary, but how to balance it? A full rewrite of a functional 12-year old application? Yea, you're going to waste years and deliv

> I know a full rewrite is necessary, but how to balance it? A full rewrite of a functional 12-year old application? Yea, you're going to waste years and deliver something that is functionaly worse than what you have. It took 12-years to build it would realistically take years to rebuild. Fixing this will take years and honestly some serious skill. What you want to do is build something in front of your mudball application. For the most part your application will be working. It's just a mudball. Step 0. Make management and HQ understand the state of the application. To do this I would make a presentation explaining and showing best practices from various project docs and then show what you have. Without this step, everything else is pointless. If they don't understand how bad it is. You will fail. Failure is the only option. If the team is not willing to change and you're not able to force change then you're going to fail. So once you have the ability to implement changes. Step 1. Add version control. Step 2. Add a deployment process to stop coding developing in production. Step 3. Standardise the development env. If you have views and not intermingled php & html: Step 4. Start a new frontend and create endpoints that reuse the original code to return json for all the variables. If not: Step 4. Add views. Copy all the html into another file and then make a note of the variables. Step 5. Start a new frontend and create endpoints that reuse the original code to return json for all the variables. ... Carry on moving things over to the new frontend until everything is in the frontend. Probably a year later. Step 6. When adding new functionality you can either rewrite that section, do a decorator approach, or edit the original functionality. That's without fixing the database mess or infra mess.