5 Reasons Why It Is Not Worth Rewriting IT Systems From Scratch

When clients are seeking IT services, they are usually in one of two situations: They have a new business idea based on an IT system, or they currently have this type of business and the system is seriously suffering. In the first scenario, there is no dilemma over whether anything should be rewritten, because nothing exists.  Just determine what technology to use and proceed. However, the real conversation revolves around a business that has an established technology requiring a number of IT solutions. Buried in the details are the answers to how a system optimization solution beats out starting over from scratch. Let us give you a 5 Reasons Why It Is Not Worth Rewriting IT Systems From Scratch.

Stage Zero, when everyone is unhappy…

When an IT based business runs aground due to technological problems, deciding how to approach IT solutions is basically a business decision.

A poorly operating system is a poorly operating business, leading to slower growth and damage to a business’s image.  Not only is this frustrating for the owner, but the failures of the system affect the daily routine of employees and customer satisfaction.

No business owner running on an internet platform or other IT solutions will “close” the business for weeks, or months, to create a completely new system from scratch, just sitting  and waiting for a new solution. What about their existing customers? What about cash flow? What about the employees who support the existing system?

Stage One, when the decision is made …

In every faulty IT system you can find healthy elements which are essentially holding the business’s head above water. A strong team of developers can optimize such a system step by step, developing new functionalities based on modern technologies and innovative  solutions.

Here’s an example.

Computer Repair Doctor, a network of electronics repair shops, used an IT system to organize their repair orders. The system was old, and emergency maintenance was expensive.

When we began cooperating with Computer Repair Doctor, their IT system was consistently reporting errors, built by two different companies and based on outdated technologies.

After our initial cooperation, we offered to shift the system to a new framework.  This involved diagnosing the elements that worked correctly and setting a manageable schedule for updating the system with new functionalities.  Our partner whole-heartedly agreed to accept the plan.

Stage Two, when you see improvement…

Before even seeing improvements in a system’s operation from the customer’s side, it’s worth communicating proper expectations. When customers fully understand the improvements, the deadlines and our dedication to fulfilling them, the easier it is to accept the changes.  Or even better, they will come to expect them.

Systematically adding new features allows users to gradually test functionality and work it into everyday use.  Changes  leading to improved efficiency in the system can then be experienced much earlier than in a system built from the ground up.

What’s going on at this stage of the project at Computer Repair Doctor?

After addressing the old system’s most critical errors and installing new functionalities in the new system’s architecture, our partner’s employees began using two systems. The systems  shared the database in parallel, in terms of the most important functionalities (eg login and views). The systems were also integrated in a way that couldn’t be noticed by the user. By adapting the system for new technologies and adding new functionalities, 90% of the initial scope was reached within two years.  This avoided exposing the business to crisis or engaging their partner’s employees in the long and tedious task of testing the new system.

After passing the critical point of upgrading 90% of the system with new technology, we decided to rewrite the remaining 10% of the system as soon as possible.

Key points to remember when carrying out similar projects:

1.   Code compatibility – be sure new modules are written in such a way that the previous elements mesh with the system.
2.   Module adaptability – if old modules require major changes, systematically rewrite their code to cooperate with the new technology.
3.   Update fragmentation – avoid big changes, by introducing smaller updates at a higher    frequency.

Stage Three, when everyone is happy…

Currently, the system is working flawlessly for both the client and the employees. From the very first moment the customer enters the repair shop, data regarding the customer’s hardware and it’s issues are reported to the system. Furthermore, the system delegates tasks to employees regarding the repair of equipment, checks and supplements stock levels, saves notes related to the repair process, and finishes the service by handling transactions. Additionally, the owner of the system has access to extensive reports, which he wasn’t receiving from the old system.  This has lead to better organization of team workflow and more efficient management.

The decision to go with system optimization instead of a total ground up approach allowed for partners to utilize the system trouble-free, giving ample time to migrate the new functionally expanded system architecture into place.

Both our partner’s customers and employees, received useful and innovative functionalities pre-tested and ready for everyday use, without the shock of losing a familiar work environment.  By cooperating with us during the production stage, our partner was able to make important decisions regarding the system’s development, budget, and project deadlines.  Ultimately this processes built trust, assured a good working atmosphere and a satisfying result.

5 reasons why it is not worth rewriting IT systems from scratch:

1. Starting a project from scratch, requires launching a project as technologically advanced as the previous one, which assuredly will cost more time and money with the added pressure of delayed results.
2. There’s a risk that the project you start with may not be the one that you end with. You won’t know the results until it’s finished.  These project are susceptible to a number of unforeseen risks, including employee turnover affecting the project outcome.
3. The current system has occasional problems, but is still on it’s feet. It still functions as it should a majority of the time, so your business is not exposed to a total crisis.
4. Employees don’t always take kindly to new systems.  The reluctance to change systems from the effort needed to relearn what they already know how to do.  Additionally, continue to use a broken system while waiting for a new one can be frustrating.
5. And in todays world of business, technology changes so quickly that what starts out cutting edge may be outdated by the time your finished system is up and running.