I promised myself that starting this week I'd switch to lighter topics. But on Monday, my JSNation adventure officially came to an end, and I reali...
For further actions, you may consider blocking this person and/or reporting abuse
Excellent article! This reminded me of one of my own migrations.
My last migration was from an old PowerBuilder desktop application. In our case, migration was no longer optional: the only developer who truly understood the app had already retired, there was almost no documentation and the codebase was a mess. š
We tried to follow the Strangler Fig pattern, but the business logic was so tightly coupled that we had to take a more waterfall-like approach and migrate large features end to end. It was not necessarily the safer approach, but without it, we would have ended up with hundreds of feature flags and an even harder system to manage.
That made the risk very real and it showed exactly why waiting only makes legacy systems harder and, in some cases, ultimately much more expensive to replace.
That's so true. We all love talking about patterns and best practices, and then reality shows up. š
Sometimes the textbook solution simply doesn't fit the constraints of the project, and you have to adapt. In the end, getting the migration done is more important than following a pattern perfectly.
And honestly, your story reinforces what might be the main message of the article: don't postpone migrations. The longer you wait, the fewer options you have, and the more expensive and risky everything becomes.
Exactly. As always in software development, it is all about trade-offs.
I agree, but at the same time, I understand why migrations get postponed, a running product still needs to generate revenue and migrating a legacy system can require a significant investment.
Maybe the better approach is to continuously maintain and modernize the product before a full migration becomes unavoidable. That also requires budget, but in the long run, it can be much cheaper and less risky than being forced into a large migration later.
Exactly! These things are never easy.Ā
But I've seen migrations postponed even during relatively quiet periods because they were considered annoying and disruptive. Product owners would complain that they were a burden for developers, testers, and everyone involved. That's when my favorite argument came into play: security. š
I'd scare them a little, and later they'd thank me when customers started running security audits. What a surprise. š
And yes, continuous maintenance is definitely the best approach. A migration from Angular 7 to 21 is a nightmare, but going from 21 to 22 is almost trivial. That's the beauty of keeping things up to date: future migrations become boring, which is exactly what you want.
Hey Sylwia!
When I read the title, I was already hooked ā which is hardly surprising... you've done it again. I absolutely loved your article; it captures the pain of a migration so well!
Personally, I hate migrations. Every single time, they turn into a nightmare ā regardless of how good the existing codebase is.
In fact, I recently completed one myself, both frontend and backend, and even for a relatively small application it took weeks of work. And that's without having to maintain two versions in parallel.
In my case, there was a v1, and the v2 introduced so many changes that the only thing worth keeping was the customer data; everything else had to be thrown away. I don't even want to imagine what an incremental migration would have looked like. Working on my own, I simply couldn't have pulled it off ā or what took weeks would probably have turned into months of transition.
Hey Pascal, that's exactly how it is! Incremental migrations easily turn into months of work, even when the application is relatively small and the business is supportive.
But then there are those huge systems built with old technologies where a Big Bang rewrite simply isn't an option. You can't just freeze development for two years and hope everything goes according to plan. In those cases, migrations become multi-year journeys.
And honestly, that must be a special kind of torture. š At least with a Big Bang approach, you suffer intensely for a while and then it's over. With an incremental migration, you wake up every morning knowing you'll be living in two worlds for the foreseeable future. š
That "temporary" adapter joke hurt š We had one of those bridge solutions hanging around for three years before someone finally killed it. Nobody even remembered what it was for anymore. Thanks for writing this.
Hahaha, exactly! š That's how those "temporary" adapters usually end up.
And honestly, the only thing worse than finding one after three years is realizing that it's still needed after three years. š
And nobody dares to touch it because 'it still works' š until it doesn't.
Hahaha, exactly! š Or some nasty security vulnerability shows up and suddenly everyone is shocked. š
This reminds me of something I've been realizing recently while working around mainframe and enterprise systems.
From the outside, it's easy to look at an old system and think, "why hasn't this been replaced already?"
Then you start digging and discover years of business rules, dependencies, edge cases, and decisions that aren't obvious from the code alone.
The technology is usually only half the challenge. Understanding why the system ended up the way it did is often the harder part.
Really enjoyed this article. The "temporary adapter" sections gave me PTSD and I haven't even done a migration yet š
That's the truth about legacy systems. š There are often years of history hidden behind those decisions.
I still remember the times when everyone was becoming a software developer after a short course and then getting thrown straight into serious projects without much mentoring. They did the best they could, but they rarely had the chance to properly grow into the role. And years later, we're all dealing with the consequences. š
So I try not to judge old code too harshly. Most of the time, there was a reason things ended up that way.
And yes, beware of "temporary" adapters. They have a habit of outliving entire frameworks. š
Every legacy system has that one file named
utils.js,helpers.java, orfinal_final_v2.cs.Nobody knows who wrote it.
Nobody knows what it does.
But everyone agrees touching it requires a change request, a rollback plan, and a prayer. š
Hahaha, exactly! š Every legacy system has one of those files. Even the coding agent takes one look at it and submits its resignation. š
š Somewhere inside that file is a comment from 2018 that says:
// temporary fix
And everyone is too afraid to ask temporary for whom.
š¤£
Hahaha, exactly! š Maybe they meant temporary on a cosmic scale. š
Like, "temporary" for the remaining lifetime of the Universe.Ā š¤£
Sylwia, this brought back memories š
I've worked on legacy systems before, and one thing I've learned is that they usually look much simpler from the outside than they actually are. Once you start digging, you realize how many decisions, dependencies, and business rules have built up over the years.
A lot of the time, there is a reason things ended up the way they did, even if it isn't obvious at first.
Exactly! š And until you've spent enough time in the project, you usually don't know what those reasons are.
People often assume that legacy code exists because somebody was incompetent. Then you dig into the history and discover that, six years ago, half the team left and two juniors were left on their own for six months, doing the best they could under the circumstances. š
Most of the time, there is a story behind the mess. And understanding that story is often harder than understanding the code itself.
Great read! You make a lot of excellent points about the psychological and technical friction of migrations, especially on the front end, where frameworks move at lightning speed.
But your post also made me think about a completely different tier of "legacy" code, the kind that doesnāt just predate modern frameworks, but actually predates the public internet entirely.
Iām talking about the deeply buried back-end bedrock, like COBOL systems or AS-400 applications. These are the quiet, invisible giants running our global financial institutions, municipal supply chains, airlines, and government agencies every single second of the day.
In those ecosystems, "the longer you wait, the worse it gets" takes on a terrifyingly literal meaning. It's not just that the codebase grows sprawling; it's that the pool of engineers who actually understand the business logic and syntax is literally aging out of the workforce. When a critical corporate ledger or transaction system relies on logic written in the 1970s or 80s, a migration isn't just a refactor; it's high-stakes digital archaeology where a single misstep can halt critical infrastructure.
It really puts the definition of a "legacy system" into perspective. Working on those deep back-end monoliths feels less like maintaining tech debt and more like defusing a bomb made of decades-old logic.
Have you ever had to bridge the gap between a modern front-end layer and one of these deep, ancient enterprise back-ends?
Thanks for this comment! And yes, I completely agree. The scale of some of these systems is truly mind-blowing.
Someone in the comments here mentioned that they once joined a COBOL project as an intern and discovered that part of the code had actually been written by their mother, who had long since retired. š That really puts things into perspective.
Personally, I've never had to build a frontend on top of a COBOL or AS/400 system, but I can absolutely imagine the challenges because I once worked with a Java backend that had originally been created as a proof of concept about 15 years earlier. Then the project kept growing and growing, and eventually people discovered that making even simple changes had become a nightmare. Adding a single form meant touching more than 80 files. š
And I don't think that was necessarily because the original developers were incompetent (although, like in every project, that probably played some part). More likely, nobody expected the project to reach that scale when it started. There were discussions about fixing the architecture, maybe splitting it into microservices, but deadlines kept coming, priorities shifted, and eventually I moved on. I honestly don't know how that story ended.
Which, I guess, is exactly how legacy systems are born in the first place.Ā
First of all, it is always reassuring to learn that other developers face similar challenges in their projects and that I am not the only one who regularly ends up in impossible situations š
In my experience, front-end migrations pose an additional non-technical challenge: they directly affect the user experience. The moment anything looks even slightly different than before, screenshots have to be retaken, manuals have to be updated, and users have to be retrained. It is even possible that UI changes touch on legal issues, and you need approval from a governance body first. Accessibility is another topic I will not even get into now.
Back-end migrations are easier in this respect, but on the other hand, the customer is far more afraid that you will break the business. Shortly before the advent of AI, I was asked to consult on a COBOL migration project. The last of their developers was about to retire. After a long and winding road, the project decided to post a job advert for a new programmer. You should never underestimate how many red flashing warning lights humans can ignore for how long š
Oh yes, absolutely. š Frontend migrations almost always end up changing something in the UI, even if you're using a standard component library like Material. Fortunately, my experiences have generally been positive. Customers were happy because things looked cleaner and more modern. Of course, that's only true as long as the changes are relatively small. God forbid you change something significant, even for the better, because then everyone suddenly starts missing the old version. š
And I love that COBOL story. What resonates with me most is the part about humans being able to ignore red flashing warning lights for years. I've seen that so many times.
To be honest, I consider myself a fairly average senior developer in terms of pure technical skill and architecture. But I do have one thing that often pushes me into tech lead roles: social skills. š Sometimes I'm actually able to convince the business to listen to reason and deal with problems before they become catastrophes. Not always, of course, but often enough to make a difference. š
We've worked with legacy for automation user onboarding with agents and from what I've seen the truth is the cost of migrating all the data from legacy to the new system is higher stake than the cost of building the new modern platform.
Take walmart -> If they moved to a new supply chain platform and in the data migration they lost data that could cost them millions of dollars much more than the cost of building the new system.
Holy words. š In large systems, building the new platform is often the easy part.
building is the easy part and data migration and onboarding users onto the platform is a sh**t show ahha
You canāt really look at legacy to modern migration as just a front-end problem. There are so many other teams involved like business, back-end, QA, APIs, security, performance, marketing, DevOps, BAs, product owners, you name it. Once you factor all of that in, the cost of migrating can get pretty high pretty quickly.
Because of that, a lot of the time the business just isnāt willing to invest in a full migration. Maintaining what already exists ends up being cheaper (at least in the short term), so it becomes the easier choice.
Honestly, thatās a big reason why IT services companies still do so well as most of their revenue comes from maintenance and support rather than full modernization efforts.
I both agree and disagree. š I completely agree with your first point: migrations are never just "let's rewrite it!" There are so many stakeholders involved that the technical side is often the easy part.
But I'm not convinced that applications are always left alone because there isn't enough time or money. Sometimes I feel it's because developers fail to communicate the business risk. They mumble things like "the code is unmaintainable" under their breath, while the business hears nothing actionable.
And I've seen the opposite too: Strangler migrations dragging on for YEARS, teams maintaining two stacks, temporary bridges becoming permanent, and the whole thing slowly turning into spaghetti. That's expensive as well, just in a less visible way.
So I don't think it's as obvious as "maintenance is always cheaper." Sometimes we're simply very bad at explaining the true cost of doing nothing. š
I'm with you on the migration part. But convincing business is altogether a different level. Right now the success rate is very thin. Hopefully with AI the success rate should go up š¤
Yip. The age old question of 'just redo it', or 'maybe we change just a little at a time'. Imo, try strangler first, until you are certain your changes are permanent. Eg. There was a case where we were implementing CSLA, because it just makes sense for ERP systems right? Wrong, it was a slow, problematic, buggy mess, that made feature adding for clients a 5 day process, instead of 2 hours... If you're going to commit to a complete rewrite, you need to be 100% certain on your architectural choice, because if you choose a mess, you're stuck in a mess...
100% true. A Big Bang rewrite isn't always the best answer, even though it has worked well for me in some cases. For example, when I'm mostly doing a large framework or library upgrade, I'm reasonably confident that the Big Bang approach will actually be faster.
Also, sorry for editing my previous comment. I accidentally replied to your comment with a response meant for someone else. Apparently, I'm not getting any younger. š
No stress, what I tend to do is modularize first (improves reliability and maintainability) and allows you to do module wide rewrites, while testing in production without an entirely separate channel. But of best of both worlds, as you get clean rewrites, without months rewriting a 10m LOC codebase neglecting production.
I wonder if simply showing the article's title image would be enough to convince stakeholders to migrate to a new stack. It looks surprisingly convincing! š
Hahaha, exactly! š We all prefer living in the shiny city of the future rather than in a gloomy industrial landscape that feels like Eastern Europe in the 90s. š
This really resonated ā especially the "temporary" adapter joke, because we all know temporary in software engineering means forever š
The point about migrations being an iceberg is so accurate too. From the outside it always looks like "just upgrade the framework," and then you open the codebase and realize the real problem was never the framework itself ā it was the entire ecosystem that grew around it over the years.
The house renovation analogy at the end is perfect. The only truly bad strategy is doing nothing, and waiting until a production incident forces your hand. Saving this one for the next time I need to convince someone that migration debt is real. šø
I'm glad you enjoyed it! š And yes, if you ever need to convince people that migration debt is real, remember that my favorite argument is always security. š
Nothing gets stakeholders' attention quite like vulnerability reports and security audits. š
Haha noted ā "security" going straight into my toolkit for future convincing situations š Nothing cuts through "but it still works" quite like a red vulnerability report staring someone in the face. Thanks for the pro tip!
I remember that I had a former friend where his father used to work with Cobol system.
Hahaha, from what I've heard, that's basically a gold mine these days. š
I mentioned COBOL to my father and he burst out laughing. He learned it back in the 1960s. Meanwhile, the Canadian government is finally moving away from those legacy systems and leaning into AI these days.
Hahaha, I always say that if AI has made its way into government systems, then it's officially everywhere. š
Governments are usually among the most conservative organizations when it comes to technology, so when they start embracing AI, you know it's no longer just hype. The future has already arrived. š
hahaha. Yeah, my current premier minister is huge in technology. He want to modernize the public civil serve and make productive like the private industry. He is a business man in most of his career.
Hahaha, that's nice. š Unfortunately, ours is more of a career politician. š
I think I prefer the big band approach because of how I am wired, it's even exactly the approach I am using now for a clients real estate website. I built it with pure PHP, and now want to rewrite the whole thing in Laravel in 2 months š , wish me luck š©. But it's good to know that refactoring too is a good choice, you can't just break your entire app if your business heavily depends on it.
Lovely article!
I'm rooting for you! š And yes, one of the biggest advantages of the Big Bang approach is that once you're done, you're done. You're starting with a clean slate, and life becomes much easier afterwards.
With incremental refactoring, you always have to be careful not to turn it into an endless migration. š That's probably my biggest fear with that approach. At some point, the "temporary" coexistence of two worlds starts feeling a little too permanent.
Good luck with the Laravel rewrite! Hopefully, two months from now you'll be enjoying the clean new code instead of maintaining two applications at once. š
Thanks a lot Sylwia, that's the aim, looking forward to it!
The name of the pattern isn't "Strangler Pattern" (gruesome! š) but "Strangler Fig Pattern", named after the parasitic plant that slowly takes the shape of and eventually replaces its host tree. Here's Martin Fowler's article on it.
Yes, exactly! š Although in practice people often shorten it to just "Strangler", so I shamelessly dropped the "Fig" part in my talk.
And if you look closely at the slide screenshot, the fig is actually strangling Backbone there š
But you're absolutely right! Thanks for the clarification and for adding the historical context behind the name!
The 'longer you wait, the worse it gets' framing is about to get sharper with AI in the mix. Legacy used to accrue from humans taking shortcuts under deadline. Now agents generate code faster than anyone migrates it, so you're building tomorrow's legacy at machine speed while the old legacy still sits there. Your rewrite-or-refactor judgment matters more, not less: the deciding factor is still whether you understand why the existing system does what it does, and AI-written code tends to arrive with that understanding already missing.
Exactly! That's pretty much what I was wondering myself when AI coding agents started taking off.
In one of my articles, I asked developers how they actually use AI at work. Not the polished LinkedIn version. š One reader told me their team was instructed to migrate a system as quickly as possible using coding agents. The result? The new system wasn't even six months old, and it had already become legacy because nobody really understood what was going on inside it. š
That story has stuck with me ever since.
Thank you! I'm in half but decided to comment before I forget š
I have quite a legacy to migrate (scala-js chrome extension, written from 2013 till 2023) so your article seems very spot on.
Keep up the g00d work and I wish you this beer with WesBos in Amsterdam š»
Thank you so much! š And good luck with the migration! A scala.js... that sounds like a lot of fun ahead. š
Few years ago I was involved in migrating a oracle forms app to a React app. It was a total mess. Before us one of the leading tech company has tried to do it and failed. We, the in house team started the migration on top of that code base. When I read this article I understand why it was a mess. Learned so many things that I shouldnt do in a migration, from that project.
Thank you! š And that's exactly how I see it too. When it comes to architecture and migrations, I often catch myself realizing that people have already encountered most of these problems before us. There are patterns, best practices, and lessons learned, and it's usually much better to learn from other people's mistakes than from our own. š
Of course, reality always finds ways to surprise us, but having those battle-tested ideas in the back of your mind makes things much easier. If my article helped you put some of those experiences into perspective, then I'm really happy to hear that. š
The big challenge nowadays is that technologie is moving fast, and sometimes it's difficult to keep the project up-to-date. The time you build a project, the dependencies become obsolete ...
Oh yes, absolutely! š Although I feel things have slowed down a bit recently, and people are less likely to panic and declare, "Redux was great yesterday, now it's garbage!" š
š
Very Very Great Article Sylwiaš The longer you wait, the worse it gets this is the most honest truth in software We had a 2,000-line process() function that no one touched for years We called it The Heart of Darkness. When we finally had to change it, we learned more about the codebase in one week than in two years of avoiding it.
The code wasn't scary because it was complex. It was scary because we didn't understand it. And the only way to understand it was to touch it.
Thanks for the reminder. š
Hahaha, I love "The Heart of Darkness"! š Every legacy application seems to have one of those.
And you're absolutely right. Sooner or later, somebody has to touch it. The code itself usually isn't scary because it's inherently complex, but because nobody understands it anymore. And unfortunately, the only way to understand it is to dive in and start changing things.
Which is exactly why I'd rather do it sooner than later. š
The ālonger you wait, worse it gets" framing names the symptom ā the underlying mechanism worth surfacing is decision cadence. Every āwe'll handle it next sprint" is a deferred decision, and deferred decisions don't sit still. They accumulate context that nobody on the future team has, then get re-litigated from scratch when migration finally happens. The migration cost isn't really technical debt ā it's compounded decision debt that lost its rationale.
The Strangler pattern works because it forces small, repeatable decisions instead of one cliff. Each cutover is a fresh micro-commitment with current context, which means the cost of being wrong stays bounded. Big bang rewrites fail not on technical merit but on the impossibility of one team holding all the decisions the original system accumulated over a decade.
Ken's COBOL/AS-400 example sharpens it: when the workforce that made the original decisions ages out, the decisions themselves become unverifiable, and migration becomes archaeology, not engineering. That's why āthe longer you wait" compounds faster than linearly ā you're not just losing time, you're losing the people who could explain why anything is the way it is.
Exactly! š Waiting hurts on so many levels, and yet businesses often postpone migrations indefinitely.
My project is in the midst of modernizing from an ancient legacy framework to a modern framework.
We're doing the Strangler approach.
It's working. Making progress. Slowly but surely.
Exactly! š The Strangler pattern is a great approach, and perhaps most importantly, it's battle-tested. Slow and steady progress may not be glamorous, but it beats a failed rewrite any day. Good luck with the migration! š
Working with legacy systems can be challenging because outdated code, dependencies, and poor documentation make maintenance increasingly difficult. Delaying modernization often raises costs, increases security risks, and slows development, so addressing technical debt early saves time, money, and future frustration.
Exactly! š And sometimes money is the only argument that really gets through to the business.
Exactly! š Ignoring the problem is probably the worst thing we can do, especially in huge systems.
Legacy code itself isn't the enemy. Every successful product eventually accumulates some. The real danger is pretending that it will somehow fix itself while technical debt keeps growing in the background. The larger the system, the more painful that becomes.
That's why I strongly believe in continuous maintenance and incremental improvements. They may not be exciting, but they're usually much cheaper than waiting until you're forced into a massive migration under pressure. š
Really Insightful!
Thank you š
Sylwia, the Big Bang framing in your table is more nuanced than most give it credit for. When an Angular 7 app sits untouched in maintenance for years, the real cost is not the eventual migration but the invisible cost of every new feature landing on a frozen stack. Junior devs cannot learn modern patterns, code reviews cannot enforce modern conventions, and hiring gets weird because nobody wants a 7-year-old Angular badge on their CV.
One thing I would push back on: LLMs shift the Strangler side more than Big Bang. With pattern-matching AI, you can incrementally rewrite modules that previously needed a full Big Bang. But review surface area explodes because the AI does not know your internal contract invariants. We end up needing parallel shadow tests that run old and new code paths side by side.
The endless migration risk on Strangler is underrated. Without a hard deadline, scope keeps growing. How do you set a "good enough" line without it becoming a quality regression?
test