If you’ve ever opened a codebase and immediately whispered “oh no…”, this article is for you.
Over the years I’ve had countless conversations with developers facing migrations, all asking the same questions and sharing the same frustrations. And it hit me: we’re not struggling with legacy itself - we’re struggling with the myths around it.
Yesterday I spoke at JS Poland about different strategies for migrating old frontends into modern tools. And wow - what a day!
Thank you to everyone who came. I had a blast, and I hope you also learned something (or at least enjoyed my “ancient code archaeology” jokes 😄).
Inspired by all the conversations after the talk, I decided to write down the biggest myths about legacy — the things we, as developers, repeat so often that they start sounding like universal truths… even when they aren’t.
Let’s debunk them 👇
Myth 1: “Legacy means ancient or exotic.”
Nope. Legacy doesn’t have to be some mystical, forgotten tech from the 90s.
Sometimes it’s just… yesterday’s mainstream.
- A slightly outdated Angular version
- A React codebase full of class components
- A Webpack 3 setup that “still works, so don’t touch it”
Legacy isn’t about age - it’s about mismatch. A tool becomes legacy when the team, ecosystem, or business has moved on, but the codebase didn’t.
Myth 2: “Legacy is the previous team’s fault.”
This one always makes me laugh.
You almost never know the full story behind the code you inherit:
- Maybe the project was frozen for 6 years.
- Maybe the team didn’t have enough experience or time to migrate.
- Maybe the one person who understood everything left the company in 2018. (We all know That Person™.)
Blaming people is easy. Understanding context is harder - and way more productive.
Myth 3: “Migrating is just a dev obsession.”
I wish 😅
Legacy can silently harm the business:
- security issues
- performance problems
- rising maintenance costs
- slowing down delivery because every feature feels like defusing a bomb
A migration is not a vanity project. It’s risk management.
Myth 4: “A big-bang rewrite is always an antipattern.”
Big-bang rewrites have a terrible reputation - usually for good reason.
But sometimes they are the cheapest and fastest solution.
If the app is small, isolated, and not mission-critical, a clean rewrite can be:
- simpler
- safer
- quicker
- and less painful than dragging old code through a multi-year refactor
Not every migration needs to be a multi-phase Netflix-level saga.
Myth 5: “The strangler pattern is the only correct approach.”
Strangler migration is great for large, complex applications. But it comes with trade-offs:
- it takes time (a lot of time…)
- you risk a never-ending migration
- your team needs to know two technologies at once
- the boundary between old and new can become messy
It’s a tool - not a religion.
Sometimes strangler is perfect.
Sometimes big-bang is perfect.
Sometimes you need a hybrid.
The real skill is choosing the right strategy for your constraints.
Final thoughts
Legacy isn’t a failure. It’s just part of the natural life cycle of software.
Every codebase eventually becomes legacy - including the one you’re writing today 😉
The important thing is understanding the trade-offs, choosing the right migration strategy, and avoiding the myths that make legacy feel scarier than it really is.
Top comments (2)
Rewarding Tech debt solvers is a great option so that people stop seeing it as a hurdle .. For a car to run you need to replace old parts as well as sometimes repair and give new upgraded parts . That's something part of any building process and not to be actually given the scary tag of debt .
Totally agree! Tech debt is just normal maintenance - like replacing parts in a car so it keeps running. It shouldn’t be treated as something scary or shameful.
And yes, rewarding people who tackle it is a great way to make it feel like valuable engineering work, not a burden.