Moving from Legacy Mindset to Engineering Excellence: Why Big Bang Rewrites Fail and Sustainable Change Wins
Over the years, I’ve seen countless organisations wrestle with the challenge of moving from legacy systems to modern engineering practices. There’s a persistent myth that this is a purely technical journey—just swap out the old code for the new, and voilà, you’re modern. But the reality is far more nuanced. Engineering excellence isn’t just about technology; it’s fundamentally about culture.
Let’s be honest: if your teams don’t have a culture of absorbing change, rolling with the punches, and continuously learning, you’re going to struggle. If you’re not continuously improving, adapting your processes, your products, your vision, and even your backlog based on what you learn and how your users engage, then you’re stuck. You’re anchored to a legacy mindset—the idea that you write it once and it’s there for posterity. That’s not how modern, sustainable software is built.
The Big Bang Rewrite Fallacy
I’ve lost count of how many times I’ve seen organisations attempt the infamous “Big Bang” rewrite. The thinking goes: let’s build a shiny new system off to the side, then switch over when it’s ready. In theory, it sounds clean and efficient. In practice, it’s a disaster.
Here’s why:
- It almost never works out as planned. The costs spiral, the timelines slip, and the business value is nowhere to be seen.
- You’re often using the same people who built the legacy system. If the same team, with the same mindset and practices, builds the new product, why would you expect a different outcome? Maybe you’ll get a marginal improvement, but the fundamental issues remain.
- It’s a business risk. When budgets tighten, what gets cut? The cost sink of a rewrite that’s not delivering value, or the existing product that’s still bringing in revenue? It’s a no-brainer. The rewrite gets axed. I’ve seen organisations go through this cycle five, six times—each attempt more expensive and demoralising than the last.
Sustainable Change: Fixing in Place
So, what’s the alternative? You fix your application in place. Yes, it’s harder. Yes, it can feel slower. But it’s far less risky, and it’s the only way I’ve seen real, lasting change take root.
Here’s how it works:
- Identify a piece of your application to improve.
- Build the new component, following solid engineering principles—adaptable, testable, maintainable.
- Integrate it with the existing system.
- Test, validate, and deploy.
- Repeat.
With each iteration, you’re adding value. The system becomes faster, more scalable, and more sustainable. The new capabilities emerge from the old, and over time, your legacy system is transformed—piece by piece—into something modern and robust.
If you have multiple teams, you can tackle several areas at once, accelerating the process. But the key is that you’re always delivering value, not just burning cash on a speculative rewrite.
Building a Culture of Engineering Excellence
This approach does more than just modernise your technology. It builds a culture of sustainability and engineering excellence:
- Teams learn to clean up their own messes. When you have to refactor and improve what you’ve built, you quickly learn to do it better next time.
- Continuous improvement becomes the norm. You’re always adapting, always learning, always getting better.
- You reduce risk. There’s less chance of cancellation, because you’re always delivering incremental value.
I’ve worked with teams across industries to make this shift. The organisations that succeed are the ones that embrace the hard work of fixing in place, that see every improvement as an investment in both their product and their people.
My Advice: Make Change Stick
If you want your people to be as ready as your platforms, focus on building a culture that values sustainable change. Don’t fall for the Big Bang rewrite myth. Instead, invest in continuous improvement, in-place refactoring, and a mindset of engineering excellence.
It will take time. It will require discipline, patience, and a willingness to learn from your mistakes. But the payoff—a resilient, adaptable product and a high-performing team—is worth every bit of effort.
If you’re ready to make that change stick, let’s talk. I’ve helped teams navigate this journey before, and I’d be happy to help yours do the same.
Moving from a legacy mindset to modern engineering practices is more than just technical, right? Engineering excellence isn’t just technical. It’s a cultural thing within the context of your teams.
If there isn’t a culture of absorbing change, rolling with the punches, if there isn’t a culture of continuous learning, of continuous improvement, if there isn’t a culture of continuously adapting your processes to what you learn, continuously adapting your products and your vision to what you learn, continuously adapting the work items that you have based on what you learn and how users engage with it, then it’s going to be very difficult to move from a legacy mindset, which is write it once and it’s there for posterity, to a continuously refactored code base that adapts to your business’s needs in the same way that your business’s needs adapt, right? Or at least as close behind as you possibly can.
And that migration from “I’ve got a legacy system”—because the reality is that the Big Bang rewrite is a complete fallacy. It hardly ever works out and it hardly ever costs what you think it’s going to cost. It’s usually the most expensive way to rebuild your software. And worse, if you take all the software engineers that built your existing legacy, poorly coded, poorly architected product and you have them rebuild a new product, why would you think the outcome would be any different? Why would the new product be any more scalable, sustainable, adaptable, testable, maintainable, right? All the ables. Why would it be more of those things than the old one? I mean, it may be a little bit more because people learn over time, but it’s not going to stick with it more.
So, the way it does work is you need to change your product in place. You don’t replace your product wholesale. You don’t build a new version off on the side. I see teams, organizations do that all the time. I worked with an organization quite a few years ago and they were on their fifth attempt at Big Bang rewrite of this one product, but they were on their fifth attempt of it. Every few years they had another attempt, and usually when times are good, we’re making a lot of money, and then something happens in the market or whatever and we’re not making so much money. So what’s the project that we cut? This current existing product that’s providing us value and cash flow, or this cost sink of an attempted rewrite that is not providing any value right now? It’s a total no-brainer business decision. You cancel the new thing. And they’ve been through six attempts of it, right? This is super common.
So what we do is we fix our application in place. Yes, that’s harder. Yes, that costs more, but it doesn’t cost more than six attempts at rewriting because you do each thing right. You’ve got your application, you build a new piece, you hook it in to the main application, you do all the testing, validation. Awesome. We’ve replaced that piece. We’ve added value to the system. The system is now faster, more scalable, more sustainable because we’ve added this new piece in and we designed it in the way that solid principles, that it’s adaptable and all those kind of things.
So we’ve got a new piece in, but the rest of our application is still legacy. What’s the next piece we need to go fix and the piece after that? And if you have many teams, you can tackle many pieces at once and continuously progress. Your new application emerges from the old one, right? Your new capabilities emerge from the old one. And that’s how you build sustainable change. That’s how you build a sustainability mindset into your teams, into the culture of your organization, that you’re fixing things as you go, that you’re adapting things as you go, that you’re having to go back and clean up your own messes, so don’t make the next mess.
And that work to do that is what teaches us, right, to do it better the first time, the second time, right? When we’re refactoring, “Oh no, now I’ve built this thing. I realize how I should have built it and I get a chance to refactor it. I get a chance to change it,” and do that continuously for your application within the context of we’re still adding new features to our application and you’ll get to where you need to be.
It will take time. It will probably take longer than just focusing on a Big Bang rewrite, but it’s less risky, less chance of cancelling. And you do both things. You rebuild your product and you rebuild the culture of your organization and the mindset from a legacy mindset towards one of engineering excellence.
And that’s something that I work with teams often on, that idea of fixing things in place, of adapting the things that we already have. So, we’re adding value, not cost. And if you want your people to be as ready as you need your platforms to be, let us help you make that change stick.
