Key Takeaways:
-
A new front end does not replace a legacy system. It hides it. The effort moves, it does not disappear.
-
Data debt is the actual scope. Fields with two meanings, status values nobody documented, rules that exist only in code.
-
Every field needs an owner in the business. What nobody can explain, nobody will approve.
-
Staged replacement beats the big cut. Martin Fowler described the pattern as the Strangler Fig Application back in 2004: grow the new system around the old one until the old one can be switched off. The condition is that the data stays in sync while both run.
-
What is not migrated still has to be decided. Archiving is a decision, not an omission.
Anyone planning a legacy data migration underestimates the ratio of interface to data. A modern front end is built in weeks. Establishing what the data behind it actually means takes months. A system grown over years contains rules documented nowhere: in fields with two meanings, in status values whose meaning changed once, and in logic that exists only in program code.
We just costed a front-end migration project and saw the usual effect. The interface was the smaller half of the proposal.
The reflex toward a new front end
It is understandable. The interface is what everyone sees, what everyone complains about, and what can be demonstrated. A new front end produces visible progress immediately.
Except: if the same data sits behind it, the same constraints are still there. The field with two meanings still has them. The process that only works if steps are taken in a particular order still only works that way. The symptoms have been treated cosmetically and the cause carried forward.
The failure statistics reflect this. Around 70 % of digital transformations fall short of their goals, and the recurring diagnosis is the same one: the projects that fail are the ones run as technology programs instead of business programs. The data questions are business questions.
How to recognize data debt
A few questions that surface it quickly:
- Is there a field whose meaning depends on what another field contains?
- Are there status values nobody can explain that still occur in the data?
- Are there records that only work because an exception in the code handles them?
- Are there fields repurposed years ago because a new one could not be created?
- Are there two places where the same information is maintained?
Five yeses do not mean the project fails. They mean the clarification effort belongs in the plan, ahead of the interface.
Every field needs an owner
The most effective single step we know: walk the field list and write, next to each one, the name of the person who can explain what it means and who maintains it.
In a grown system, roughly a third are left without a name. That third is the project scope. These are the fields for which nobody will confirm a migration rule, because nobody knows what correct would be.
For that third there are three routes: reconstruct the meaning from the data, carry the field across as an archive field with no business use, or deliberately drop it. All three are defensible. Making no decision is not.
Staged rather than one cut
The big cut has an appeal: one date, and then it is over. It also has a risk: if something does not work, nothing works.
Fowler's strangler fig image describes the alternative. The new system grows around the old one, takes over one function after another, and the old one is switched off when nothing depends on it any more. Every step is individually verifiable and individually reversible.
The condition is the synchronization. If both systems are in use at once, there has to be a clear rule about which system holds the truth for which entity, and a reconciliation that runs without manual work. If that is not feasible, the big cut is the more honest choice, with a correspondingly longer rehearsal period.
What happens to the rest
Not everything has to come along. But everything has to be decided.
We work with three categories: migrate (the working set), archive (read access, no new system), discard (with justification and approval). The third is the one most people shy away from, and the one that reduces effort most.
The only thing that matters is that the archive access genuinely exists before the legacy system is switched off. An archive meant to be built after the shutdown does not get built.
What that means for estimating
We estimate these projects differently now. The interface is estimated like an interface. The data clarification is carried as its own block, with a number that comes from the field list rather than from instinct. It makes proposals less comfortable and projects more predictable.
If you are looking at a legacy system and wondering where to start: start with the field list. We do this walk with customers regularly, and it is the cheapest week of the whole project.
Sources
- Fowler: StranglerFigApplication, martinfowler.com, 2004
- Tabrizi, Lam, Girard, Irvin: Digital Transformation Is Not About Technology, Harvard Business Review, March 2019