Should I rebuild to use latest tech?

Question

I am a full stack developer in a very small company.

It has a custom built ERP software using PHP 4 (no framework). Currently, it works fine from the business point of view except for some bugs here and there. Presently, about 4-5 people use it. The company's plan is to offer it as a product to clients with some modifications.

The code is messy. Its partly also because 5-6 devs have worked separately on it in the last 15 years.

I am the only person on the tech team now and the chances of adding more people are negligible.

Should I recommend management to upgrade to PHP 7.1 and a framework ?

The thing is that building the whole thing from scratch can take around a year since I am alone here.

I repeat the business needs are being met to a great extent as of now.

---

Edit

Answering questions by jonrsharpe:

Currently our executives use this ERP. We are not selling this software now but the vision is to do that in future. I agree with you when you say "Given the size of the company it seems unlikely they could keep doing whatever it is and develop, sell and support a large piece of software". The major issue is that the management wants to see outputs that improve their day-to-day business (which relies on this ERP) . Their bias for action prioritises short term goals over long term ones. When I was hired, I was told that there is a working piece piece of software with a few bugs here and there. They wanted me to test them and fix them (now these bugs are really minor ones as far as the functionality is concerned). So, I am looking for a solid reason to first convince myself to upgrade. The old dev had left before I had joined and the management has little tech knowledge.

Answer 1

Consider this approach:

1. Document the existing code: Purpose, behavior, workflows, limitations, known issues, etc.
2. Based on result of #1, create test suite for the code. This will be helpful regardless of whether you decide to rewrite the code in new technology stack
3. Also based on result of #1, identify exactly what advantages the new technology stack will bring. Be specific, e.g. "the current stack can only handle X requests per second, with the new stack the number of requests that can be handled will be 5X".
4. Based on #1 and #3, talk to management to prioritize work. It may be that a lot of the problems / messy code you see are in parts nobody actually use, in which case the entire part can be eliminated, saving a lot of trouble.
5. Based on #4, start gradual improvements in short cycles. E.g. you may want to start by eliminating unused parts in the first few weeks, then improve the architecture of the main components in the subsequent few weeks, then change variable/function names that can cause problems in new technology stack, and so on. Run tests from #2 at the end of each cycle to ensure that whatever you change / rewrite doesn't break anything.

Using this approach is that you always have an working but improved version of the code at the end of each cycle. So it gives the company more flexibility and reduced risk. If for example at the end of month 5 the company wants to demonstrate the software to some potential clients, it can do so, and the version being demonstrated will already better compared to current version.