What to keep in mind when rewriting software

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

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

Will both platforms exist simultaneously or not?

Do you plan to keep outdated and new versions in production? If so, how long? You should avoid servicing the two versions in production for a long time because of operating expenses.

Who will be engaged in 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 the impact on customers of a product with fewer features.

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

Ensure that the interaction before and during the rewriting is established and that all interested parties agree on 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 introduced 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 lot of money.

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

Data migration
Rewriting is not just a design opportunity. You should also schedule data migration. People usually underestimate the complexity and cost involved in migrating data from the old version to the new one. This activity should not be just one task on your list with the title "data migration".

For example, suppose you need to migrate user accounts. If your outdated version is managed by a third party, you most likely do not have access to encrypted user passwords, so that 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 decrease 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, like e-commerce.

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

Take time to train internal users.
This, too, is often overlooked. The rewriting plan should have a phase dedicated to educating internal users before transferring 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 different areas, such as customer support and sales.

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