In your 4 person company, how many people are developers? Is it just you? With no offense to you, a junior dev leading a rewrite of a large messy application i

In your 4 person company, how many people are developers? Is it just you? With no offense to you, a junior dev leading a rewrite of a large messy application is almost guaranteed to result in a different messy application. That's really the most likely result regardless of who is doing it. I would add on to what everyone else is saying and say don't do a full rewrite. Instead, refactor small chunks at a time. > One of the primary complaints we get is that our current system is too slow. In part, this is because most actions trigger a full page reload. Full page reloads don't really need to be slow. Measuring and improving web page speed is well established, and IMHO you should work on this and understand it before you build something new; there are a lot of ways to build a page that will be difficult to make fast, having experience making things fast will help you start on the right foot towards fast pages. You should be measuring at least time to first byte, time to last byte, and data size on the server; times in ms. On the client side, assuming you've got client side analytics, you want to measure the kinds of things that Google PageSpeed Insights measures: https://developers.google.com/speed/docs/insights/v5/about https://developers.google.com/speed/docs/insights/v5/about If you can get this from (possibly sampled) real clients, that's best; but if not, at least test occasionally with the tools inside your browsers. A very fast PHP page can be done in < 10 ms, server measured. But more realistic is time to first byte < 15 ms, full page content in 50-100ms. If you're much beyond that, you need to measure parts until you find the time, and fix it. You can work this problem at the same time as some refactoring by including timing with refactoring; chances are, a lot of the server time is in database queries, and instrumenting timing on database queries and centralizing the database interface into a single place can go well together. Ideally, you can push this timing information into your access logs, and you'd have a list of timings in each log line; time to first byte and total request time are best measured by your webserver rather than in PHP itself; especially if you're using frameworks that do a lot of initialization on each request, you must include that in your total, but it can be difficult to measure from within PHP. Since your users are all in US/CA (and I assume your server is too), if you get your time to first byte under 15 ms on the server, you should see it under 100 ms on the client. And if your pages aren't too big and the dom isn't too complex, a 100 ms server page time should be at your clients within 0.5 and rendered in < 1 s. You can probably do better with partial page updates, but see what you can do with making full page updates fast first.