Hi! My name is Dmitry Pankin, I am the founder of the companyResolventa. We create complex IT products for clients: marketplace sites, B2B portals, personal accounts, applications, custom CRM and ERP systems.

When a company wants to update its IT system, it gets a lot of bad advice from programmers: delete, throw out, re-write in a different language. This approach is 99% beneficial only to the developers themselves, businesses go bankrupt because of it. And now for more details.

Almost no IT system can run forever on only one technical support - neither an online store, nor a CRM system, nor a personal account. That's why the service will need a complete upgrade or replacement sooner or later.

The business has grown or changed. Sometimes, at the start, it is difficult for an entrepreneur to assume that a small "garage" project will grow into a huge company with several departments. Therefore, technical specifications for an IT system are often written as if it will always be small. The developers do not take into account the subsequent scaling:

• They don't use automated tests.;
• They are not building a sustainable architecture;
• they don't conduct a cross-code review;
• they don't keep the code clean.

At the start, this approach can even be beneficial: you can quickly create a minimally viable version of the service and enter the market with it in order to test it in real conditions. But if you skip the moment when the scale increases, endless bugs will start popping up, the service will process requests slowly and stop coping with the amount of data.

Technology is outdated. Since the writing of the IT system, several new versions of the programming language may be released. As a result, your version will become outdated and will be without official support. This means that the vulnerabilities in it will not be eliminated and new features will not be added. This is critical for the development and scaling of any business, so you need to update the service and switch to a new version of the language.

We use PHP at Resolventa, so we will talk about it in the article. For example, we strongly recommend updating the service if the PHP version is lower than 7.0. The same applies to outdated frameworks, for example: Yii, CodeIgniter, CakePHP, Symfony 2.0.

To find out if the language version you are using is supported, look at the list of releases on the official website. In the case of PHP, you need to go to php.net , and for the Symfony framework — on symfony.com .

The screenshot shows an example of how we updated the PHP version when upgrading one of the projects. As a result, the site started loading 2.5 times faster.

The project was written by an insufficiently qualified team. It happens that the service is initially written carelessly and hastily. As a result, the code is dirty, programmers don't do refactoring and review — there's no time. This may be the fault not only of the developers, but also of the managers: they may set too short deadlines and constantly adjust the team, provoking new mistakes.

Sometimes, at the start, a business simply does not have the money for an experienced development team, and the IT system is ordered from someone who offers a more affordable price. While the service is small, the low quality of the code is not noticeable, but with the development of the business comes the collapse. This does not mean that the approach was wrong. It's just that the team didn't react in time and didn't update the system before problems arose.

So, if any of the above is about your service, then it needs to be updated.

Imagine: the logistics company Transportation noticed that the internal system for employees began to slow down due to the large amount of data, and contacted the IT agency with this problem. In addition, she needs to add a new feature to her personal account and make an adaptive version so that the service is convenient to use from a smartphone, but current technologies do not allow this.

There is a 90% chance that the following dialogue will take place at the agency:

— What stack is your service currently written on?

— The developers say that in PHP…

— Hence the problems. Let's write everything from scratch on a modern Node.js. This will allow you to use a single JavaScript language to write code both on the client side and on the server. As a result, it will be much faster, and it will be easier for developers on the frontend and backend to collaborate with each other.

— Is there really no way to save what you have?

— It will be unprofitable for you. Trust our experience.

— Okay…

Introduced? This is how negotiations on how best to recreate your service usually end. Writing from scratch is beneficial for programmers, but more often than not it's a critically bad idea for a business.

I'll explain why programmers give such advice in general.

Each company has its own technology stack: one agency specializes in PHP, another in Python, and the third in Node.js . If the customer has a different stack, the developers simply cannot immerse themselves in his project, because the team does not have specialists who work in this programming language.

A screenshot from the Resolventa website, which shows the stack of our specialists. You can find a similar list on the website of any IT company. This will help you find out if they are working with the same technologies as your developers.

The developers are not competent enough. Understanding someone else's code is much more difficult than writing a project over again. We need experience in solving similar problems and a personal approach, not just the practice of solving typical tasks. This requires qualified staff. If you are offered to rewrite the project from scratch, it is possible that the company simply does not have senior programmers on staff to modernize it.

It is beneficial for the agency to take your order, but it is too stressful to modernize the service step by step. As a result, programmers naturally begin to push through their decision to completely rewrite the project. This is how they get paid and don't complicate their lives by working with someone else's stack and legacy. This is usually argued by the fact that the agency's technological stack and approach to solving problems are the most modern, while the customer's are dense and outdated — that's all that slows down.

We believe that the task of a conscientious developer is to preserve the service if possible. Let's find out why in most cases it is more profitable to modernize an old IT system and when you still have to rewrite everything from scratch.

It usually takes about the same amount of time to develop a service from scratch as it took to create it the first time. For example, if an online store was built in a year, then its new version will not appear earlier.

All this time, the business must live with the old IT system, which, although it does not fully perform its functions, is still necessary. There are two options for what to do with it: leave everything as it is — at tech support — or put crutches and fix the service in parallel with the creation of a new one. Each solution has its own significant disadvantage.:

If you do not touch the old service, you lose the possible profit. For example, in our practice, there was a customer with a B2B portal, he sold subscriptions to his service. It was assumed that while we were making a new version of the portal, customers would use the old one and wait for the release. But some were not satisfied with bugs and non-adaptive design, so they unsubscribed from the service. As a result, the customer missed out on a portion of the profit.

If you fix an old service along with creating a new one, you double the costs. You will have to maintain two development teams: pay twice as much and spend management resources to control both. This is a big burden on the business. And there is also a risk of conflict: the developers of the current version feel that the outdated service will be buried with them, so they can sabotage cooperation with the new team.

In my experience, there are almost no situations where the system cannot be restored: you can always go through the old code and upgrade the platform. But there are cases when it is impractical. Here are two circumstances in which it is better to rewrite the system from scratch.:

The technologies used are hopelessly outdated. The project will have to be recreated if the technology is not just obsolete, but dead. This happens if the version of the language in which your service is written has not been supported for a long time. For example, when the product is written in PHP 5.0, which was deprecated back in 2008.

If your service's code looks like this, you shouldn't upgrade it. It's better to bury it and write from scratch

CMS is used. Designers such as WordPress and Bitrix are good for small or typical online stores and other simple IT systems. If a business is growing, over time it will need new customized solutions that cannot be implemented on a CMS.

Alas, upgrading a service originally written on a CMS is incredibly expensive and difficult. To do this, you need to know the device of a particular CMS from the inside and not just configure it, but be able to rewrite important parts of the source code. There are very few such specialists on the market.

In all other cases, when the service is written in a language version that is still supported and the CMS is not used, I recommend upgrading. For a business, rebuilding an old service is almost always better than building a new one.

If management chooses a step-by-step modernization strategy, it will be possible to expand and increase business efficiency in parallel with the reconstruction of the IT system. You won't have to pause processes for a couple of years while writing a new software platform for the company.

It may seem to business management that it is more expensive to modernize a service than to develop it anew. This is not always the case. The final price is influenced by several factors. Let's first consider those that increase the price of a phased recovery.:

• Payment of qualified personnel. Upgrading is more difficult than creating a project, so higher-level specialists are required here. Their cost is higher, so salaries can increase the budget.

But, on the other hand, a low—budget team is unlikely to be able to write even a new project well - there is a risk that in a couple of years it will have to be rewritten again.

• Time costs. Upgrading the system step by step is laborious, and it can take a considerable amount of time. Businesses will carry this financial burden for longer, withdrawing money from other budget items.

But there are points that reduce the cost of modernization work.:

• Using ready-made parts of the code. When restoring, you do not need to rewrite the sections of the old system that are functioning well. This reduces development costs. This is not possible when creating a project again.: one hundred percent of the code must be written from scratch.
• The work of just one team. There is no need to keep individual developers to support the old service and create a new one, you do not inflate the staff of programmers.

To determine exactly which option is optimal for the business, I recommend conducting a qualified external IT audit. Experts will look at the condition of your service, calculate the cost of writing from scratch and upgrading, and help you make a conclusion.

• Update the service if the business has grown or changed a lot, the technology is outdated, or, for example, 10 years have passed since the last upgrade.
• Upgrading the project step by step is the most profitable solution for the company in most cases. This way you won't have to double your expenses, lose profits and customers, or freeze business growth.
• Rewrite the service from scratch if it is made in PHP 5.0 and earlier versions or written using a CMS. In these cases, upgrading the service will be more difficult than writing it over, which means it will take many hours for programmers and will be too expensive.

At Resolventa, we have been helping startups and large businesses around the world restart services and create new ones since 2012. We also conduct a technical audit: if you have not yet decided whether to modernize the system or rewrite what exactly to change and how to optimize it.

Write in person — we will analyze the problem and set a date for consultation on your IT project.