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.


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.

  • 3
    Certainly you need to get them off PHP 4. That version has been out of support since before I last worked in PHP. Which was over 10 years ago now. The security risk of running internet-facing software that far out of date is staggering.
    – Jules
    May 19, 2017 at 7:51
  • 1
    no. it will be boring and difficult. recommend the business start a proof of concept app in the tech of your choice
    – Ewan
    May 19, 2017 at 9:01
  • 2
    If you only have one developer, don't have a custom ERP; buy a more modern one.
    – jonrsharpe
    May 19, 2017 at 13:35
  • The more I think about this, the more questions I have, so please edit to answer: What does this company currently do; do they sell software now? 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, so what's the plan? What were you hired to do, and how can you do that and upgrade the ERP (a year seems very optimistic)? What's the market for a buggy program built on software that hasn't been supported in a decade? What you have should probably be thought of as a liability, not an asset.
    – jonrsharpe
    May 20, 2017 at 9:18
  • @jonrsharpe What would buying a modern ERP mean for the single developer ?
    – tsh2017
    May 22, 2017 at 7:07

1 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.

  • Thats a good way to go ahead but my question is should I continue with PHP 4 ? I've read in many places that there are security risks but do they trump the time and effort needed to rebuild the whole thing from scratch using contemporary technologies ?
    – tsh2017
    May 22, 2017 at 7:13
  • It seems like it have to be rewritten, partly due to apparent level of technical debt, and partly because potential clients may be reluctant to buy a software solution based on PHP4 today. The approach I suggested will reduce the time and effort needed to get an initial working version in PHP7+framework of your choice (maybe covering the requirements of the first client).
    – gprana
    May 22, 2017 at 9:18
  • @tsh2017 no, you should not. You should even decide if PHP is still the right language.
    – Laiv
    May 22, 2017 at 20:03

Your Answer

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

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