During my MSc in Digital Transformation, I presented a technique inspired by nature, the “Fig Tree (Strangulation) Method” as a way to migrate away from legacy systems burdened with technical debt. Since that point, my data migration journey has taken a complete new direction.
The concept is simple, but powerful.
In nature, a strangler fig doesn’t destroy a tree overnight. It grows slowly around its host, extending roots downward and branches outward, gradually replacing the host’s structure. Over time, the original tree disappears but the ecosystem continues.
This is exactly how we should think about modernising legacy systems.
The Real Problem Isn’t the Application : It’s the Database
When organisations talk about legacy systems, they usually focus on:
- Outdated UI
- Unsupported frameworks
- Slow performance
- Difficult integrations
But in my experience, the real risk sits beneath all of that:
The database.
In many long-running systems:
- The schema has evolved organically.
- Fields have unclear meaning.
- Business rules live in stored procedures nobody fully understands.
- Data transformations happen implicitly.
- Documentation is incomplete (or non-existent).
- Only one or two people really know “how it works.”
Before you migrate anything, you must answer a fundamental question:
What does the system actually do with the data?
If you don’t understand that, you’re not migrating, you’re gambling.
Applying the Fig Tree During Requirements Gathering
Most projects treat requirements gathering as a functional exercise:
- What screens do you need?
- What reports do you run?
- What workflows exist?
The fig tree approach reframes the exercise around data behaviour instead of features.
Step 1: Grow Around the Existing System
Instead of ripping out the legacy core, build new services around it.
Start by:
- Mapping data flows
- Identifying inbound and outbound integrations
- Tracking CRUD behaviour (create, read, update, delete)
- Logging database interactions in real time
You are not replacing anything yet.
You are observing.
Like the fig tree sending roots down.
Step 2: Make the Invisible Visible
This is where real transformation happens.
During requirements gathering:
- Ask what decisions are made from the data.
- Identify derived fields.
- Trace how data mutates across processes.
- Document implicit business rules.
- Capture edge cases triggered by historic data.
Often stakeholders don’t know these details, the system does.
By instrumenting and replicating functionality outside the legacy core, you expose hidden logic.
This builds:
- A clean conceptual data model
- A validated understanding of business rules
- A migration-ready target architecture
Step 3: Build the Replacement in Parallel
Once behaviour is understood:
- Create new microservices or modular components.
- Replicate functionality with explicit rules.
- Redirect small portions of traffic.
- Validate outputs against the legacy system.
Gradually:
- Reporting moves first.
- Then low-risk workflows.
- Then high-value transactional processes.
Eventually, the legacy database becomes a read-only archive.
Like the original host tree, it remains structurally present but no longer alive, and importantly no longer technical debt.
Why This Reduces Migration Risk
The fig tree method works because it:
- Avoids big bang migrations, can even support parallel phased implementations.
- Turns unknown data behaviour into documented knowledge.
- Surfaces hidden technical debt early, a key hidden ROI on your transformation.
- Creates a validated target data model before cutover.
- Builds stakeholder confidence incrementally.
Most importantly:
It transforms requirements gathering from a “what do you need?” exercise into a “what actually happens?” investigation.
When we perform requirements gathering, we focus on the why and what we do, often told the how is not relevant as thats the incoming solution’s problem. But this is not actually correct, we need to know how we did it, even if we are not immediately concerned with how we will do it; otherwise we will not get a true translation of processes, especially complex immutable processes.
The Strategic Shift
Digital transformation isn’t about replacing software.
It’s about understanding data.
When organisations rush to modernise without deeply understanding their data layer, they recreate the same debt in a new technology stack.
The fig tree approach forces discipline.
It respects the complexity of legacy systems while building a path out of them.
And like in nature, it works because it grows patiently.
If you’re facing a legacy migration and the database feels like a black box, perhaps the solution isn’t to cut it down.
Perhaps it’s time to grow around it.
© Rowan Tree Scientific Limited All rights reserved.