Fortum.

The Challenge

Fortum's customer billing platform had been in continuous operation since 2009. Over 15 years, it had accumulated the kind of technical debt that makes engineers wince: a Java 8 monolith, hand-crafted ETL pipelines, a bespoke ORM that predated Hibernate being widely adopted, and business logic scattered across 200,000 lines of code written by 40+ developers across four countries.

The system processed billing for roughly 2 million customers across Finland and Sweden. Downtime was not an option — even scheduled maintenance windows had been progressively reduced over the years as the business expanded to 24/7 markets.

The modernisation goal: migrate to a cloud-native, event-driven architecture on Azure, decommission the monolith, and reduce the maintenance cost by at least 50%. Target timeline: 18 months.

The core challenge: Fortum's internal team had the domain expertise but not the Azure cloud engineering and event sourcing depth needed to do this safely at scale.

The Engagement

Indpro's involvement came in two phases.

Phase 1: Specialist Placement (Months 1–3)

Before any migration work could start, Fortum needed to establish the architectural blueprint. They needed two specific profiles:

A senior event sourcing architect — Someone who had actually designed and shipped event sourcing systems at scale, not just read the CQRS books. This profile is genuinely rare: we searched our network and screened 11 candidates before presenting 3. Fortum hired the first one they interviewed.

A Azure platform lead — With specific experience running high-availability financial systems on Azure, not just generic cloud experience. Again, a narrow profile. We found a consultant who had previously led the Azure migration for a Danish bank.

These two individuals spent months 1–3 designing the target architecture, establishing migration patterns, and creating the technical runway for the larger team.

Phase 2: Team Augmentation (Months 4–12)

Once the architecture was defined, we scaled the augmentation team to support the migration:

Total augmented team: 8 engineers over the 8-month execution phase.

• 4 senior Java engineers (migration specialists, comfortable with both old and new code patterns)
• 2 Azure data engineers (for rebuilding the analytics and reporting layer)
• 1 QA architect (for designing the test strategy that would give confidence to non-destructive parallel running)
• 1 additional platform engineer (to support the event streaming infrastructure)

The Technical Approach

The migration used a strangler fig pattern — the new system was built alongside the old one, with traffic gradually shifted from old to new as each billing domain was migrated.

The key innovation: a dual-write proxy layer that allowed the old and new systems to run in parallel with consistent state. This allowed Fortum to validate the new system's output against the known-good legacy output before any cutover.

Zero downtime was achieved because at no point was a customer's billing processed exclusively by the new system until the new system had demonstrated 100% accuracy for that customer segment in parallel mode.

The Result

The 8-month execution phase (out of an 18-month total program) delivered:

• 60% reduction in technical debt measured by cyclomatic complexity and lines-of-code per business function
• Zero customer-visible downtime across the entire migration
• 43% reduction in infrastructure cost from monolith-on-VMs to cloud-native
• Billing processing time reduced by 70% (from batch-overnight to near-real-time)
• New feature velocity up 3x in the modernised system in the 6 months post-migration

The two specialists placed in Phase 1 both joined Fortum permanently after the engagement. Four of the eight augmented engineers continued in extended contracts.

Lessons for Similar Projects

Specialised skills are not the same as generic seniority: "Senior backend engineer" wouldn't have solved this problem. The event sourcing and Azure specialisations were the critical factors. Be specific about what you need.

Strangler fig with dual-write is the risk-managed path: Cutover migrations in high-availability systems are almost always riskier than they appear. The dual-write approach adds complexity but the confidence it provides is worth it.

Architectural investment before execution saves months: The 3-month architecture phase felt expensive at the time. It saved 6+ months of rework during execution.

Working on a legacy modernisation project? Talk to our team about how we staff these engagements.