Legacy Modernisation & BI Platform Migration
Modernise the systems you cannot replace and move reporting platforms without losing the logic buried inside them.
Key benefits
Off unsupported technology
End-of-life runtimes, databases and reporting tools retired on a planned schedule.
Logic preserved, not guessed
DAX and stored-procedure logic extracted and translated with output compared side by side.
Incremental, not big-bang
Strangler-pattern delivery so value lands early and risk stays contained.
Lower licensing spend
Commercial database and BI licences replaced with open or lower-tier alternatives where it makes sense.
Portable deployments
Containerised workloads that run the same in every environment.
Nothing switched off blindly
Legacy systems are decommissioned only after parallel-run sign-off.
Scope — what we cover
Methodology
- Assessment — inventory applications, reports, dashboards and database objects, and rank them by usage and business value
- Rationalisation — retire unused reports and dead code before migrating anything, so effort goes where it counts
- Logic extraction — document the DAX measures, stored procedures and transformations that hold the real business rules
- Modernisation roadmap agreed with stakeholders, sequenced by risk and dependency
- Incremental delivery — containerise, re-platform or rebuild each unit, converting logic to the target platform
- Parallel run with output compared line by line against the legacy system until results reconcile
- Cutover, decommissioning of the retired system, and handover with documentation and training
Deliverables
Frequently asked questions
Common questions we hear before starting a migration or architecture engagement — click a question to reveal a short, clear answer.
Yes — this is a common engagement. We extract the DAX logic, convert it to LookML, rebuild the reports and run both platforms in parallel until the numbers reconcile.
They get retired. Rationalisation happens before migration, and on most estates a substantial share of reports turn out to be unused — migrating them is wasted effort.
Parallel running. The new platform runs alongside the old one and outputs are compared row by row until every discrepancy is explained or fixed. Nothing is decommissioned before that sign-off.
Usually not. Containerising and re-platforming is often enough, and a strangler-pattern approach lets you replace components incrementally instead of attempting one high-risk rewrite.
Yes — including schema conversion, stored-procedure translation and data migration, with reconciliation to confirm integrity before cutover.
Frequently. Moving off commercial database engines and high-tier BI licences is often a large part of the business case, and we model the saving during assessment.
It scales with the number of reports that survive rationalisation. A few dozen reports is typically 6–10 weeks; larger estates are delivered in waves by business domain.
That is the normal case. Logic extraction is a distinct phase precisely because the knowledge usually only exists in the code and the reports themselves.
Yes — embedding dashboards into your own applications or portals, including the access model and row-level security that goes with it.
Yes, and it often should. Modernising a workload as part of the move avoids lifting technical debt into the new environment.
