[taway2012]

Been in a few orgs. I now think "no rewrites" is a good policy for all but a few orgs. Few orgs have the (1) business luxury (time and money) or, (2) the caliber of people and, (3) team motivation (few teams people even want to improve things) to pull off rewrites.

The best orgs do a rewrite usually in the face of sea changes to the technology stack (e.g., containers vs. VMs) or business use (number of users is now 10X of original etc). Bringing key infrastructure in-house is also a decent reason, but the benefit of building expertise in an existing ecosystem vs. full rewrite should be carefully weighed.

You probably have read spolsky's article. It's quite dated by now, but it's still more right than wrong. http://www.joelonsoftware.com/articles/fog0000000069.html

[k__]

This reads like they tried to replicate 100% of the features in a big monolithic application, which is rather time consuming. :\

When I start a rewrite I check which are the essential features and try to iterate my way to 100% (sometimes the 100% aren't even needed) with many small releases, but every executive fears "rewrites" like the devil....

[judk]

Sadly, this often leads to a 50% rewrite where key features are missing because I he rewrite team ran out of budget or willingness to code the non-fun parts. Which drives users to misery or competitors.

[k__]

True story.

But I have the feeling, that a prio-list of the needed features is all that is needed.

People say what they need, you implement it, done.

I mean the way other companies steal your customers IS that they implement a better version of stuff you did. So it's either, they do the rewrite (in their case a first write) or you.