An occasional review of technology, markets, and ideas.

Application Rewrites, Part II

You made the "worst strategic mistake" that any software company can make and decided to rewrite your application. Now what?

In Application Rewrites, Part I, we talked about why rewrites are generally a bad idea. But, sometimes people became enamored with the vision (mirage) of a rewritten application. Forceful personalities inside your company will make a convincing case that right now, the product is at a local optimum and if you just take the leap and rewrite, you can make it to the global optimum. You'll get Flexibility! It will be featureful! It will drive operationally efficiencies!

A small number of people inside the company have the temerity to voice concerns about this direction but they are waved away as not really understanding the vision. After this, others get the message and bite their tongues for fear of retribution. And there we have it...a top-down decision to rewrite the entire application that does not have unanimous support inside the company.

Now what?


Assuming your company hasn't yet imploded from a mass exodus, you are going to have two versions of the product: V1 and V2. You need to announce the change to customers, determine the upgrade timeline and issue an "End of Service Life" notification, and figure out on a per-customer basis how to get them migrated and how to handle any workflows that you've inevitably broken.

Announce Pencils Down on V1. Because you are rewriting the entire application, it makes sense to go pencils down on V1 since failing to do so will fragment your engineering efforts and prolong the rollout of the rewritten application. This needs to be communicated to existing customers who are going to be reporting bugs, asking for features, and otherwise left wondering why all new releases stopped. This will be a tricky conversation and it's best to focus on the things that the customer can get from the new version.

Determine Upgrade Timeline + Issue EoSL Notification. Next, you need to figure out what the upgrade path looks like from V1 to V2. You probably won't have a fully baked version of V2 but you should also try to include some information about the timeline for these changes. At this stage, I generally recommend drawing a line in the sand 12-18 months in the future and sending customers an "End of Service Life" notification. You need to let customers know that as of a certain date in the future, you will no longer provide support for V1.

Some will likely claim that doing this is risky and could force a customer's hand and cause them to churn. This seems reasonable until you recognize that every day you spend managing and supporting the old version of the product is time that could have been spent making the new version better. Point is, if you've decided to rewrite your entire application, you've already made a hyper-risky decision. Better to go all in and let customers determine whether they want to continue as customers rather than pussyfooting around and delaying the day of reckoning. If you truly believe in the additional value of the rewritten version of the application, prove it and put real ARR on the line. As they say, "In for a penny, in for a pound."

Upgrade Plan With Existing Customers. Now comes the hard part. Assuming you are able to develop a production V2 system you will have made some dramatic changes (if you didn't that begs the question "Why did you rewrite in the first place?") and you will need to actually migrate customers over. When faced with these new changes, there are going to be customers who really like the old product and don't want to move to the new product. This is why having a concrete "End of Service Life" announcement is so important since it helps add urgency to the process. The last thing you want is to be supporting two versions of your product for 2-3 years since this is a drag on the entire operating cadence of your company.

Assuming the customers still want to work with you, you really need to understand how existing customers are using your product and how the new version might impact their existing workflows. Are there any changes to the way URLs are handled? Does the customer use any official or unofficial APIs that will break with the new product? If you break a workflow, you need to let the customer know 1) what workflow will be broken and 2) how you are going to help remediate this since you made the change.


Deciding to rewrite your application is a "bet the company" decision. From the company's perspective, getting existing customers migrated as quickly as possible is the key to ensuring that the decision to rewrite does not sink your company. Assuming you heed all the warnings and still decide to rewrite, the key is constant, proactive communication with your existing customers about what this means for their deployment. You need to determine the upgrade timeline, issue an "End of Service Life" Notification, and get each customer an upgrade plan with line items for how to fix any broken workflows. If you truly believe in your rewritten application, this EoSL – rather than being a risky move that forces a customer's hand – is the best way to ensure there is time pressure to migrate customers over as soon as possible.

Subscribe to Andrew Thappa

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe