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

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 improvement – reporting pipelines run substantially faster than on the legacy system
  • Significant reduction of monthly platform cost – through cloud-native architecture and the removal of legacy licences
  • Zero critical incidents – no known critical incidents
  • 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