Guide to a (Less) Painful Technology Switch I

Just like a salami: go slice by slice!

A few months ago, one of our partner companies asked for our help in a technology switch project: They wanted to switch from Delphi, C#, WPF and MS SQL technology to JavaScript. As most members of the developer team used C# for their work, they contacted Green Fox because of the lack of experience. During the years at Green Fox, and even earlier, as a developer, I have worked on several similar projects. During these projects, I saw many traps and many excellent solutions, and I am collecting all these experience in my next two articles. 

‍More satisfied developers, faster development – this is the reason for starting!

Switching to a new programming language is usually a difficult decision for a company. It is a painful process, it might be expensive and time-consuming and, if wrong decisions are made, you might come to a deadlock. On the other hand, there might be significant benefits in the medium term, for example, more satisfied developers, quicker and more efficient development projects, a better rate of return.

Technology switch projects are usually initiated by developers, whose work is made more difficult by the old system over time, so they do not like it. It frequently happens that there is no up-to-date documentation to the technology, old documentation needs to be dug out, or the technology is simply not supported any more. This makes it difficult to change a code, and modifications often break something else. It is not effective, and, on the other hand, might be very frustrating for the developers. In these cases mostly the technology switch is the best solution.

Ground up vs. function by function

Although it might be an attractive solution to re-write a previous application from scratch, my experience shows that this is one of the biggest mistakes you can make. It is incredibly time-consuming to re-write a 5- or 10-year-old system, you might be almost sure that something will break, and the new system will know less. The old application – despite all its faults – is well-tested, has many features and is impossible to be reproduced within a few months.  

So, instead of throwing out the whole system, choose a precisely defined feature, and re-write it with the new technology in a way that fits the other elements of the system. Moreover, it helps us to validate the new technology: What are the advantages compared to the previous system? How much quicker will this function be? How much will the quality improve? 

If the first function had been successfully re-written, you may start with the next one. Just like cutting a salami, you re-write the system slice by slice. By the end of the project, only a negligible part of the codebase will have the old technology. 

How to choose a feature

It makes sense to start the technology switch with a feature that:

• may be precisely defined,
• needs a little tweaking anyways,
• is old-fashioned from the viewpoint of UX.

So you will not only start the technology switch, but you will also make an outdated function more user-friendly – which means that you will enhance the value of the product. 

Create an architecture diagram

Before you start re-writing a function, create an architecture diagram which shows how the system is constructed, what the main components are and which parts are affected by the technology switch. In the next step, check how the other parts of the system will connect to the new technology.

This knowledge is often missing at companies. In most of our previous projects, we were asked to help in connecting the old system to the new technology. 

In my next article I will list the aspects that need to be considered when choosing the new technology.

‍

Download our related case study that describes a technology switch project.‍

‍