To rewrite or not to rewrite a software

To rewrite or not rewrite a software ?

Writing a software is a incredible difficult task. When the time has come for the software to know the retirement : should we rewrite it ? or have an progressive approach ?


Here are my thoughts on that subject.

In a previous article, I wrote about how to migrate a legacy software. I have planned, programmed, handled several software progressive migrations using dedicated tools in my career. I have created a small company Byoskill, to handle these subjects.

Since, I have been using some facts to decide between a full rewrite and a progressive migration.

The presentation below has been produced for a customer software some time ago and I will use it as an example.

Why writing a software is difficult ?

Let’s be honest together. Writing a software is incredibly difficult. Your latest framework choice won’t change the thing. Neither the most beautiful functional language.

A good software takes team players, the right environment, some skills and experience, efforts and luck. Capers Jones has written several interesting articles about the success and the failure of Software projects.

Probablity of On-time Software Delivery

Probablity of On-time Software Delivery

These tables illustrate the difficulty to lead to a successful project.

Probability of software project termination in six subindustries

Probability of software project termination in six subindustries

Capers Jones interesting articles here and here.

My first argument to be taken into account in the debate pro or con rewrite is the following :

A legacy software is a software that had enough success to ages. Thereby a convergence of facts allow ed him to born, grow up with new features, get fixed and finally ages.

My second motivation based on Capers Jones observations and a lot of similar experiences I encounted in the business of software migration.

Big software projects aka big rewrite are doomed to fail.

The fluctuating market

The conditions that enables the current software to live have probably changed in the recent years. Basically, our software is fighting against the following tendencies :

    • Complexity is the software is increasing
    • Market is not waiting for releases and its appetite is growing for new features
    • Disruption is everywhere : competitors, startups , pricing war
    • ROI law has changed in favor of the scalability and the  number of users rather than higher license prices
    • Low-qualified workers used for maintaining an existing software  are not a appropriate answer to create state of the art technologies.
    • Creating new software (aka rewrite) requires true software leaders and informed product owners
    • Change management is a tricky and nasty affair

The situation has to be evaluated precisely. Will your customers wait for this brand new version ? How will you managed their expectation for the new features ?

Can all the software be saved ?

This tricky question is probably the real rationale behind the pro/con debate in favor of a rewriting.

Basically you have three choices in front of you :

Software migration choices

Software migration choices

Outsourcing developments

The easiest and safest choice for a manager. To not decide anything 🙂

Basically, transfer your legacy software to a company that will promise cheaper rater and cost. Keep the possibility to switch when the outsourcing company will increase their rates.

Blame them and plan your future new projects while keep the cost indicators low for the current solution.

Sole problem : you do not know when you will be able to launch the new projects. Your budget is most likely melting as your maintenance cost.

The Big Rewrite


The Big Lebowski

The Big Lebowski

To enable a big rewrite, you need to basically have the following warranties :

  • You have enough time to build your new software
  • You have the full endorsement of your customers, your users and your stakeholders
  • Your business knowledge is perfect and synchronized with the current market need
  • Your users are not expecting the same software ( features, workflow and yes bugs)
  • And all basic conditions to lead a project (cleancode, software craftmanship)

I believe that a successful rewrite project is basically not a rewrite.I would even recommend to not call it “new version” of the product. Rather a new name, a new UI, a new customer/user journey. Calling it a new version of a product where most of the features are missing is always a bad idea.

Progressive migration and automatic migration

Even if these two approaches are fundamentally different, the progressive migration and the automatic migration shares the same goals.

The goals to achieve could be the following ones :

  • Reduce the time of migration : shorter is the project, higher will be the success probability
  • Keep the most useful features, saves money for the new ones
  • Performs critical technical debt operations
  • Avoid any complications in the change management (political issues, conservative users)

I would recommend these scenarios when you have optimal working conditions. Indeed you will have to handle some highly technical software re-engineering.

  • a great motivated team
  • a supporting management (refers to point 1)
  • a whole set of features
  • difficult constraints (time, political, market)
  • some experimented programmers and architect oriented.
  • a evolutionary technology stack allowing easy interactions with a new stack (no proprietary languages, no 4GL)
  • possibility of functional data layering

This article has been already too long to detail the refactoring steps.  I will encourage you to reed the other articles on my blog like this one for a preview.

I hope you will have learn one thing or two about the decision process about rewriting a software. If you have arguments in favor or against what I have advised it, please let a comment!

All these informations are extracted from my experience with byoskill.com. I am offering cleancode courses and support for automatic software migrations.

About me

You are on this site because we are sharing the same passion : Software

My name is Sylvain Leroy and I am software programmern, startup funder. My speciality is to save software from all kind of sickness.

about me

About Me in Switzerland 🙂

What is defining me the most precisely is my passion for Software and coding.

As explained on my company site (byoskill.com), I have three passions :

  • Software craftmanship (SQA)
  • Legacy software migration
  • and startup environments

I have been doing that from so long

I discovered coding something around 10, on our family Commodore 64/128.

Commode 64/128

Commode 64/128

Back in these times, I didn’t know about coding, I learnt how to use it to get what I wanted. Games, interests. I was curious to manipulate and understand this strange creature.

Basic program

Basic program

Of course I had normal activities, friends, sports. However this machine fascinated me. We had two big books, in English, a foreign language to me, full of code listing. I spent numerous to painstakingly type them on this computer. Some code were games, some revealed to be funny noise / sound effects, plane engine.

I had the chance to be from the generation who grew up with computers and incredible progresses. We switched one day to x86, a 286 with single coloured screen. I remember the screen was pale glowing in my room at night. I made obvious progresses in Basic, QBasic, Visual Basic (my college passion),  switched to Pascal(Delphi) at 14 during the middle school. At 16, I was efficient in Delphi and I tried the C language without enthusiasm.

I discovered at the same time ASM/Z80 programming to use on my Texas calculator and I switched from Pascal to ASM, with all the set, TASM, TLINK.

The book “the Art of Assembly Language” had a huge impact on me. I printed it with our good old printer in 4 big binders. And started to love it.

I continued until 18 my experience of assembly programming on two fields :

I finally has switched to C/C++ late 19 using Visual C++. I have been slowly mastering it. I was always tempted to switch to ASM using asm statements. To program with limited resources is so much funnier than with high level languages.

A lucky meeting changed my life and course

I have been following a Computer science diploma in two years at the University of Rennes 1 (Lannion). And then I discovered I could not work in industrial automation because a wrong choice of course. I switched to a general computer sciences Licence (3rd year).

During my master degree, I choose as exam project, a technical project in which we were supposed to write a Java syntactic analysis tool (linter). This meeting with this professor, Francois Bodin, had a influence of my final year of study, and at minimum the next ten years of my life.

Together, under his tutelage, we imagined a research project, a project of company creation, and we launched it. It was Tocea, which lived from 2009 to 2015 before being absorbed by a Software Editor, Metrixware. In my mind; I am and will be eternally grateful, for the opportunity – the seed – Francois offered to me. It has been an  incredible adventure. This environment was totally new for me, my family, my surrounding, given our social origins.

Serenitec : research project

Serenitec : research project

Tocea : my passion, and my initiatory route

Offically Tocea has been created in March 2010 after 3 years of research project and one year of incubation.

Research project Serenitec

Research project Serenitec

We were three at the beginning, and the project was called Navis.

Against, there, Marie-Anne  and Florent, have been of a great help and influenced positively the view of what could be Tocea, both socially and professionally.

Tocea / modele_carte_recto2

Tocea / modele_carte_recto2

A french article here of this period.

Francois Morin, is also important to me, since we brought Tocea to its maturity together. Co-founding a company is never simple. We had to learn from each other, to be able to work together. The stability and the trust of our relationship has been like the warm fireplace that attracts the frozen voyagers. And we simply attract the best to reach together our ambitions as a small software editor we were.

Our company had his life , successes and failures , joy and pain but I remember it as a wonderful social experience. I have seen students coming for their first experience, getting their first job, growing up and becoming our real assets. Tocea has been a success (humanely) thanks our people. They gave us our trust, and we tried together to create something great.

Links :

The transition

Tocea ended peacefully to become a more serious business under the acquisition by Metrixware. Fair enough, Metrixware, a well-known software editor specialized in Legacy system and migrations, saved us at that time, our business was in a full transition after some critical mistakes and a hard business year (for the whole sector).

I learnt much from being there about processes, change management and also company culture. Three things crucial for the success of any projects.

Now in Switzerland

I am enjoying my new road, currently in Switzerland.  I have been discovering this great country and particular job environment since the begin of 2017.

I have been since working full time as IT Consultant for large institutions. Recently, I created a small structure www.byoskill.com in which I am providing my experience for dedicated missions.

Each encounter, with either a Software Developer either a team, is pushing me forward to what I love the most :

Empowering people, saving Software and developing great tools.



How to do a legacy software migration : a successful checklist

Legacy Software migration

Here is a small checklist about how to migrate a legacy migration and to ensure its success.

This article is part of my work to explain my knowledge about Software migration in the company Byoskill.

Continue Reading


How to make a software developer happy ?

Leave your comfort zone

To be or not to be (happy), that’s the question. In this article, I expose some thoughts about what could make a software developer happy in his work. I wrote this article with several targeted audience in mind : Junior developers, Senior Techleads and H&R resources.

Continue Reading