I think doing a full rewrite is the least thing you should consider. You should think first the least risky things to this mess. Remember your team is small and

I think doing a full rewrite is the least thing you should consider. You should think first the least risky things to this mess. Remember your team is small and the revenue is huge(20M/year lol). I will list some things to consider (importance order) and the others can consider more points, of course: - git: More productive and more control over the code base and the each member team responsibilities. Don't change the structure of the code. If it's a monorepo, leave it as it is. Just create simple branches like, prod and dev. Consider putting nginx configuration into the repositories as well (since it's part of the application). - Documentation Via Comments: In this part you should improve a little of culture in this team, new code should be documented at least using comments. - Test environment: now you have a dev branch you can push all the code to this new test environment and test things without worries. If it's possible start to write configuration environment case it's needed. - CI/CD: now everything is traceable by git, you can write a routine to deploy every branch on it's place. Some tools self hosted you can consider: Jenkins or Drone.io are great and requires almost no maintenance(no need to hire a devops to work on this) - Database: you have test environment and ci/cd, now you can TEST(what a great news) your database migrations. In php I can remember of phinx to starting to write migrations for this application. - Auto Tests: I think unit testing could be considered when adding new code. Old code just leave as it is. If you apply at least 3 things of this list I think at this point you will see that's a rewrite could be not that necessary.