As well as a big software refactor, a rewrite is not a simple thing either. After many years, we have gotten experience enough to point what you had better consider when planning and executing a rewrite process.

Will the two platforms live together for some time or not?

Are you planning to maintain the legacy and the new version in production? If so, for how long? You should avoid maintaining two versions in production for too long because of opportunity and operating costs.

Who will work on the rewrite and who will work on the legacy version?

Developers usually prefer to work on green field projects. You should take that into account when planning who will maintain the legacy version and who will work on the new one.

It’s not viable to rewrite every single feature at once

It’s not viable to have a 1 to 1 feature mapping between the legacy version and the new one. That said, what features should you start rewriting?

Take into account how current clients will be impacted by a product with fewer features.

A rewrite will slow down or stop the launch of new features in the legacy version

Chances are you won’t launch new features for the legacy version during the rewrite process. Not only will end-users not get new features, but neither will internal clients (commercial and product departments). Your internal clients and stakeholders will pressure you to deliver new features.

Make sure that the communication before and during the rewrite is clear, and that every stakeholder is aligned with the end goals.

Keep it secret or public?

Imagine you are a potential customer of a software product. You’re planning to buy it, but you just found out that a completely new version will be launched in three months. Would you buy the legacy version or wait for three months? Multiply that by dozens or hundreds of potential buyers. The provider could lose a lot of money.

That’s why if you’re the provider, you should think carefully about how and when you’re going to publicize the launch of a brand new version.

Data migration

A rewrite process is not just shipping features. You also need to plan the data migration. People usually underestimate the complexity and effort needed to migrate data from the legacy version to the new version. That activity should not be just one task on your board called “data migration.”

For example, imagine that you need to migrate your users’ accounts. If your legacy version is managed by a third-party, chances are you won’t have access to the users’ encrypted passwords, so you won’t be able to migrate them. You’ll have to ask every single user to reset their passwords in the new version. That’s part of the data migration process, too.

Prepare for a possible decrease in conversion rates

You’ll launch a new version with fewer features. Who guarantees that the conversion rates will stay the same? Conversion rates are vital in some domains, like in e-commerce.

Ideally, you should be able to keep both the legacy and the new version running for a while so that you have a backup plan in case there’s a huge decrease in conversion rates.

Plan time to train internal users

This is another overlooked subject. The rewrite plan needs to have a phase of internal user training before taking your new product to production. Don’t underestimate that, either. It can take a long time since your internal users will give you feedback about stuff that might need to be changed.

Internal users can be found in a variety of areas, such as help desk and inside sales.

What about you? Do you have any more tips on what to worry about when doing a rewrite? Share with us!