Here is my personal top 8 of the biggest mistakes made when rewriting software systems:
-
Big-Bang Rewrite. All functionality must first be mapped to the new system before existing customers are migrated to the new system. Martin Fowler’s response: “If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.”
-
Put the best people on the new system, everyone else stays with the legacy system. Of course, they feel like they’re on the sidelines. “We’re just the cleanup guys here,” and “Why are the others getting so many resources when we’re the ones bringing in the money?” is what you hear over and over again.
-
Only plan the migration when the new system is “almost ready” and the pressure from the outside is increasing. At this point, you have already blocked a lot possible paths. A painless migration may no longer be possible. (“Oh, copying the data takes several days… we’d be down for that time…”).
-
Do not question features in the existing system, but blindly adopt them 1:1. Do not include users and customers in the process, or do so only to a limited extent. As a result, the entire accumulated business complexity is quickly transferred to the new system.
-
Underestimate the effort. It is easily specified: " Exactly like the old system" - but a lot of knowledge is in the details and in the code. 10+ years of development takes time to catch up.
-
Trying to replace the entire system. Maybe everything needs to be rewritten. But maybe there is a stable core that is not worth moving because it runs stable and there are almost no changes.
-
Taking too big a step for customers New system, new operating model, new pricing, no recognizable additional value for the customer for now → this leads to resistance.
-
Overengineering. This is the chance now to make everything work better and in a modern way! Nice. However, high expectations and overconfidence quickly lead to overengineering, also known as “Second-System Effect” (Brooks 1975 - Thanks Heiko Koziolek for the hint!). However, what is modern and sexy today will be obsolete in 3-5 years. Therefore, choose technology with a clear sense of perspective and far-sightedness.
The main mistake - in my opinion - is to think in an “old world” and “new world” and to consider both as separate systems.
But it is ONE PRODUCT, which is developed step by step.
There are enough patterns and approaches: Strangler Fig, Branch by Abstraction, Parallel Run, Decorating Collaborator, …
Books as well:
- Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith
- Patterns of Legacy Displacement
- Working Effectively with Legacy Code
What are your experiences with software system rewrites? What worked well? What didn’t? I am curious 😊