Home / Showroom / New Data Platform for Reporting at Uniper SE
DE EN
Case Study · Energy Utility

New Data Platform for Reporting at Uniper SE

Uniper SE
Duration2.5 years
TeamMultiple parallel streams, coordinated delivery
StackMicrosoft Azure · Snowflake · dbt · Azure Data Factory · Terraform
+84%
Reporting performance uplift
−76%
Monthly platform cost
Zero
Critical incidents in production

Starting point

Uniper SE's central reporting data warehouse ran on Oracle and BODS. After years of organic growth, the platform had hit its performance ceiling: reports got slower, data volumes kept rising, and ongoing operating, infrastructure and administration costs grew disproportionately.

Extending the legacy stack was no longer a realistic option. At the same time, reporting was business-critical – a big-bang switch would have caused outages and reconciliation gaps that neither controlling nor the executive board would accept. The brief was clear: rebuild the platform from the ground up without putting day-to-day business at risk.

Delivery

We coordinated the platform redesign across multiple parallel streams and established a consistent target architecture that holds across all sub-projects. The migration ran incrementally – with parallel operation and continuous quality assurance against the legacy system.

  • Scaffolding-first – an early platform skeleton delivered immediate business value while additional streams were built out in parallel
  • A free zone for delivery – an organisational protected space with short decision paths and reduced governance overhead enabled zero-friction execution
  • ~30% AI-assisted coding – a meaningful share of code was generated with AI coding tools, accelerating senior engineers rather than replacing them
  • Parallel work streams – ingestion, modelling, reporting migration and infrastructure progressed in parallel, not sequentially
  • Consistent target architecture – every individual decision in every stream was measured against the overarching architecture vision
  • Incremental go-live – new reporting paths went into production while legacy reports were still served from Oracle/BODS
  • Parallel run and reconciliation – every migrated data path was business-validated against the old system before the legacy report was switched off
  • ~450 newly built ETL jobs – consistently structured, tested and documented, as the foundation for stable post-project operation

Technologies in use

The new platform is cloud-native on Microsoft Azure, with Snowflake as the central data warehouse for analytical reporting. Data integration and orchestration run through Azure Data Factory; the business modelling layer is built with dbt — versioned, tested and documented. The entire cloud infrastructure is described as Infrastructure-as-Code in Terraform – reproducible, auditable and a foundation for stable CI/CD pipelines.

Results

After 2.5 years, the new data platform was live in production for reporting. The legacy stack (Oracle/BODS) could be retired without disruption to the running business. The new platform scales – technically and organisationally: additional business units can plug in without breaking the architecture.

  • Performance up >84% – reporting pipelines run substantially faster than on the legacy system
  • Monthly platform cost down by ~76% – through cloud-native architecture and the removal of legacy licences
  • Zero critical incidents – not a single critical incident during the running operation of the new platform
  • Immediate business value via scaffolding – the first productive paths went live well before the final go-live

Business-side reconciliation was the decisive quality anchor: no reporting figure changed in any material way as a result of the migration – and where one did, we worked with the business to determine which version was correct. That built trust in the new platform – trust which carries forward into follow-up projects.

Lessons learned

A platform migration of this scale stands or falls with the coordination of parallel streams against a consistent target picture. Let the streams work fully independently and you end up with patchwork; centralise too much and every individual decision gets bottlenecked.

The second lesson is about parallel run: it's more expensive and more effort than a big bang. But it's the only realistic option to build trust in a reporting-critical environment and resolve discrepancies cleanly. Cutting that phase short means saving in the wrong place.

A great collaboration with the Uniper team – in particular Peter Boldt, Surya Ayyagari, Kim Jongen and Bernd Hausmann – and our partner companies. Thank you for that.

Similar challenge in your company?

30 minutes, no strings attached. We'll share what we've learned in comparable projects.

Request a conversation