Most enterprises do not lose money on bad ideas. They lose it to good ideas executed in the wrong way. Nowhere is that more visible than in data overhauls, where industry research suggests that only about 30% of large digital change initiatives hit their intended outcomes, while the rest stall, overshoot budgets, or quietly shrink in ambition. At the same time, recent studies show that outdated technology and legacy programs are draining hundreds of millions of dollars a year from large organisations through technical debt, failed modernisation efforts, and the ongoing cost of keeping old platforms alive.
So, when leaders decide to “replace the monolith,” the instinct is often to bet big and finish fast. That is exactly where many data programs come undone.
As someone who spends most of their time inside messy warehouse estates and fragile reporting stacks, I see a consistent pattern. The problem is not intent. It is the reliance on big-bang cutovers instead of deliberate, strangler-style journeys anchored by business slices and clear coexistence rules. That is where well-run Data modernization services should start.
Why is big-bang modernisation often risky?
The classic playbook looks attractive on a slide: design the target architecture, build the new platform, run both for a short overlap, then switch everyone over during a single cutover weekend.
In practice, big-bang change creates four kinds of risk:
- Blast radius risk: A defect in a core pipeline or a mis-modelled fact table can take out hundreds of reports or downstream models at once. There is no easy rollback, because the old platform has already been frozen or decommissioned.
- Requirements drift: Multi-year programs assume that business questions are stable. They rarely are. Pricing logic changes, product lines are reorganised, and regulatory rules tighten. By go-live, your beautifully designed model often answers last year’s questions.
- Human fatigue: Long periods of parallel build with no visible benefit erode trust. The Emergn survey on digital change effort shows high levels of burnout and “transformation fatigue” when programs promise a step change but only deliver more meetings and status decks.
- Budget opacity: When value appears only at the end, overruns are hard to challenge. It is common to see change requests pile up simply to keep the program moving, because no one wants to admit that the original plan was unrealistic.
Big-bang approaches wrapped inside large data modernisation services proposals usually underestimate these costs. They treat the data estate as a technical object instead of a living part of how people decide, report, and negotiate with each other.
Principles of the strangler pattern for data platforms
The strangler fig metaphor, popularised in application modernisation, is simple. You grow the new system around the old one, route real traffic piece by piece, and retire from the legacy once it has no meaningful responsibilities left.
For data platforms, the same pattern needs its own set of rules.
Three practical principles for “strangling” a data monolith:
- Route by decision, not by table: Instead of lifting a whole data warehouse, you pick a specific decision or analytic workflow to move first. For example, “quarterly margin analytics for the retail business” is a better unit than “all sales tables.”
- Hide complexity behind stable interfaces: Consumers should not need to care which platform serves their metric. That means stable views, domains, or APIs that keep report definitions consistent, while the physical source shifts underneath.
- Keep the old system honest: During the overlap, the legacy platform is no longer “the truth.” It becomes a reference implementation you can compare against. A strangler-oriented approach to Data modernization services always includes side-by-side validation windows, not just parallel loads.
Unlike generic platform refresh projects, strangler-style work accepts that you will have two or more partial truths for a while. The art lies in deciding where it is acceptable and where it is not.
Defining migration slices aligned to business domains
The unit of work in a strangler journey is not a project workstream. It is a slice that a business stakeholder can understand and own.
Think in incremental migration slices that match real business workflows, for example:
- “New margin stack for the consumer business”
- “Inventory ageing for top 500 SKUs”
- “Early warning indicators for loan defaults”
Each slice binds together four things:
- A clear decision or outcome
- The domain that owns that decision
- The minimum data needed to support it
- The consumers who will trial the new version first
Here is how that looks in practice:
| Business domain | Example slice | Primary consumers | First success signal |
| Retail merchandising | Markdown and promotion effectiveness for Q-com stores | Category managers, FP&A | Weekly reviews switch to the new dashboard |
| Credit risk | Early default risk signals for small business loans | Risk modeling team, portfolio lead | Models in the new stack drive pilot credit rules |
| Supply chain | Risk modelling team, portfolio lead | Supply planners | Old spreadsheet trackers retired for pilot SKUs |
Good incremental migration slices share three properties:
- Small enough to de-risk: You can move them from discovery to first production users in 8–12 weeks.
- Valuable enough to matter: They sit close to a revenue, cost, or risk decision, not just “nicer dashboards.”
- Traceable front-to-back: You can explain to an executive, on one page, how a data defect would show up in their world.
When I design data modernisation services, my starting point is often a wall of decisions, not a wall of tables. Only once those slices are clear do we talk about pipes, storage, and semantic layers.
Designing coexistence between old and new platforms
At some point, both the monolith and the new platform will claim to know “revenue,” “active customer,” or “order status.” If you do not design coexistence rules up front, your users will design them for you in spreadsheets.
This is where coexistence strategy design becomes real, not academic. In practical terms, coexistence needs to answer three questions for every slice:
- Who consumes which version, and when?: Example: finance uses legacy P&L for statutory reporting this year, but product teams use the new version for experimentation.
- How do requests get routed?: Often, this is a BI semantic layer or an API gateway that inspects report IDs, domains, or paths to decide which backend to hit.
- What happens when numbers differ?: You need a documented arbitration routine: which source is authoritative for which KPI, over what period, and who signs off on the switch.
A practical coexistence strategy design usually includes:
- A simple matrix of “KPI vs authoritative system vs time period”
- Feature flags or routing rules in the reporting layer
- An exception process when users find mismatches
- Clear language in executive packs about which engine produced which view
This is also the stage where strong data modernisation services vendors distinguish themselves. The best ones help you design governance and routing, not just move data jobs.
Managing data duplication and sync during transition
Running two platforms always creates duplication. Trying to avoid it entirely is unrealistic. The trick is to manage overlaps deliberately.
There are three common sync patterns:
Replicate raw data, compute twice: You ingest the same sources into both platforms, then run old and new logic side by side.
- Good for: complex financial logic where you want a reference model
- Watch for: doubled compute and storage cost
Upstream capture, downstream fan-out: You use a log or change data capture stream as the single ingestion path, then feed both the legacy and the new platform.
- Good for: operational data stores that serve many systems
- Watch for: tight ordering and idempotency guarantees
Selective backfill: Only the slices you are moving are recomputed in the new platform; other history stays in the old warehouse and is accessed through cross-platform queries.
- Good for: early slices where you want to limit blast radius
- Watch for: performance and semantic drift across joins
A few practical guardrails help during this phase:
- Put a visible “source and freshness” banner on critical dashboards.
- Maintain a living catalogue entry for each migrated slice, including known differences from the legacy numbers.
- Agree in advance how long you are willing to fund dual running for each slice. Open-ended overlap is how costs spiral.
This is often the most technically intricate phase of data modernisation services, but the most politically sensitive work is still ahead.
Success measures for incremental modernisation journeys
If you only measure “platform migrated” or “pipelines retired,” you will recreate the same problems that sink big-bang programs. Strangler-style journeys need different success indicators.
Think in three layers.
1. Outcome metrics
These are tied to the decision each slice supports:
- Margin uplift on the SKUs covered by the new analytics
- Reduction in manual reconciliations for a given reporting pack
- Faster time from event to action in a fraud or risk scenario
2. Flow metrics
These describe how reliably you can deliver the next slice:
- Lead time from idea to first production user
- Number of slices in progress versus completed this quarter
- Percentage of slices that required unplanned rework after first go-live
3. Reliability and trust
These show whether people rely on the new platform:
- Incident rate per slice, not just per platform
- Number of “shadow spreadsheets” created around a migrated KPI
- Attendance and engagement in review forums for migrated domains
A simple dashboard that tracks these across slices is more useful than a single go-live date. For example:
| Metric | Target | Current trend |
| Avg. lead time per slice | < 12 weeks | 10 weeks and steady |
| Slices with full user adoption | 80% by Q4 | 55%, rising each Q |
| Dual-running period per slice | < 6 months | 4–7 months, variable |
| High-severity data incidents / qtr | < 3 | 2, trending down |
The point is not to build a perfect scorecard. It is to create a language where executives, data teams, and domain leaders can talk about progress in concrete terms, slice by slice.
When executives ask how your program is going, you should be able to say something like:
“We have retired the old margin stack for consumer; we are halfway through credit risk, and we have three well-formed slices in discovery. Dual running is being reduced on schedule. Here are the specific business decisions that moved.”
That is the moment your strangler journey starts to look like a deliberate portfolio, not an endless rewrite.
Closing thoughts
Strangling a data monolith is not about copying a pattern from an architecture guide. It is about designing data modernisation services that respect how your business actually makes decisions, spends money, and handles risk.
If you:
- Define thin, decision-centric slices
- Make routing and coexistence explicit
- Manage duplication as a conscious trade-off
- And measure progress by outcomes and flow, not just by infrastructure
Then the old warehouse stops being an immovable obstacle and becomes just another system you are gradually outgrowing.
Treat your data modernisation services as a portfolio of small, reversible bets, and the “strangler” pattern stops being a metaphor. It becomes a practical way to move your data estate forward without betting the company on a single night of cutover.