What to keep in mind when rewriting software

When developing any products, the team often wants to stop struggling with the current state of the project and rewrite everything again, this time “correctly” and “in science”. Usually, such impulses are not approved , but this time I would like to read a translation of the post by Hugo Baraúna, devoted to what questions you need to ask yourself if you still decided to rewrite.

Just like great refactoring , rewriting a product is not an easy thing. Over the years, we have gained enough experience to indicate what you should consider when planning and implementing the rewriting process.

Will both platforms exist simultaneously or not?

Do you plan to support outdated and new versions on production? If so, for how long? You should avoid serving two versions of production for a long time due to operating costs.

Who will do the rewriting and who will support the old version?
Developers prefer to work on promising projects (green field projects). You should keep this in mind when deciding who will support the old version and who will work on the new one.

It doesn’t make sense to rewrite everything at once.
It is not rational to have a 1-to-1 mapping between the old and new versions. In other words, exactly what features should you start rewriting?

Consider how customers with less features will have an impact.

Rewriting will slow down or stop the introduction of new features into the old version.
Most likely, you will not introduce new features into the old version during the process of rewriting it. Not only end users, but also internal customers (commercial and product departments) will not receive new opportunities. Your internal customers and shareholders will demand new opportunities from you.

Make sure that the interaction before and during the transcription is established and that all interested parties agree with the final goals.

Keep secret or publish?
Imagine that you are a potential client of a software product. You are planning to buy it, but you just discovered that a completely new version will be presented in three months. Will you buy an outdated version or wait three months? Multiply this by dozens or hundreds of potential buyers. The supplier may lose a ton of money.

Therefore, if you are a product supplier, you should carefully consider how and when you are going to publish information about a fundamentally new version.

Data Migration
Rewriting is not just about developing features. You should also plan data migration. People usually underestimate the complexity and cost of migrating data from the old version to the new one. This activity should not be just one task on your list with the heading "data migration".

For example, suppose you need to migrate user accounts. If your legacy version is managed by a third party, most likely you do not have access to the encrypted user passwords, so you will not be able to transfer them. You will need to ask each user individually to reset his password in the new version. This is also part of the data migration process.

Be prepared for a possible reduction in conversion.
You will launch a new version with new features. Who can guarantee that the conversion will remain the same? Conversion is vital in some areas, such as e-commerce.

Ideally, you should be able to keep both versions, new and old, for a while, in case the conversion drop is too strong.

Take the time to train internal users.
This is also often overlooked. The rewriting plan should have a phase dedicated to educating internal users before releasing your new product to production. This also cannot be underestimated. It may take a long time before your internal users can give you feedback on what might need to be changed.

Internal users can be found in various areas, such as customer support and sales.

And what about you? Do you have any tips on what to worry about when rewriting a product? Share with us!