Transforming a Legacy Project Into Multiple Products
1 Legacy System = Multiple Products
Hello 👋, It’s Vibhor. Welcome to the 🔥 paid member only🔥 edition of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. Many subscribers expense this newsletter to their Learning & Development budget. Here’s an expense template to send to your manager.
I used to be Legacy-Phobic.
I used to stare at legacy systems like they were written in hieroglyphics.
My wake-up call came when an insurance company hired me to help them move their Legacy Project to Products. Their system was a monster. It was decades old, with tentacles reaching into every corner of the business.
My immediate thought?
“We need a detailed value stream mapping exercise just to make sense of this chaos.”
I was wrong.
That's why I cringe now when I see companies spending months (and mountains of money) on consultants to map their value streams before making sense of their legacy systems.
Let me be clear.
Value Stream Mapping isn't bad.
But!
It is not required everywhere and doesn’t have to be the first step.
Like most others, I believed we needed to map every single flow before we could even think about breaking things down.
After years in the trenches, I learned how to simplify the legacy complexity.
Today, whenever I face a legacy system that needs breaking down, I don't start with complicated mapping exercises. I start with something basic.
Simple steps any team can start using tomorrow morning.
In this post, I'll show you how to simplify legacy systems without getting lost in (or before starting with) value stream mapping exercises.
Because if a former legacy-phobic like me can learn to see products where others see clutter, so can you.
Let’s get started
What is a Legacy System (or Project)?
Before we dive into breaking things down, let’s start with the obvious question:
What exactly is a legacy system?
It’s not just “old code.” Although, yes, legacy systems are often old.
But more importantly, they’re systems that are hard to change.
They’re the systems your team dreads touching because even a small change can break something critical.
Let’s say you own a very old house.
Over the years, you’ve added extensions, patched the roof, replaced some plumbing, and rewired parts of the electrical system.
Now, every time you try to fix one thing, something else breaks.
That’s a legacy system.
It’s tightly coupled. Messy. Full of dependencies that no one fully understands.
And yet, just like that old house, it’s still standing, and people still live in it.
Why?
Because they’re still running important parts of the business.
Organizations can’t just “throw them away.”
Which is why breaking them down into products is so important.
But where do we start?
We start with Step #1.
Step #1: Listing Legacy Components
The first step to breaking down a legacy system is simple:
Make a list.
What does the system actually do?
Identify all the functions the legacy system supports.
Don't worry about dependencies yet
Don't think about technical architecture
Don't stress about how things are connected
Just list the functions.
For example, if you’re working with a Legacy ERP System, your list might look like this:
Warehousing
Sales
HR
Finance
"But wait," you might say, "isn't this oversimplifying?"
Good question.
And yes, it is simple.
But that's exactly the point.
Because here's what I've learned: The moment we start thinking about connections and dependencies, we get stuck.
We start seeing problems instead of possibilities.
So for now, just list everything.
Your Legacy System’s team probably knows most of these functions already. They deal with them every day. They just haven't listed them in one place.
That's all we're doing in Step #1.
We are making things visible.
We are making an inventory of raw materials, which we will organize into potential products.
This is our foundation.