Skip to content
IT Technology

Portside Insurance

Eighteen months of modernisation with no feature freeze

A .NET Framework policy platform with no upgrade path and no one left who wrote it. We moved it a capability at a time behind a routing layer, with the legacy system still serving traffic in the final month, and the product team shipped 63 changes while the programme ran.

Client
Portside Insurance
Sector
Insurance
Run
18 months · Jan 2024–Jun 2025
Filed
2025-07-15
Capability
Digital transformation · .NET development · IT consulting · Software maintenance and support
Stack
.NET 8 · ASP.NET Core · C# · SQL Server 2022 · Azure · YARP · Azure OpenAI · Bicep · Azure DevOps

Impact

  • 0 days

    Feature freeze across eighteen months

  • 3.4×

    Quoting endpoint throughput after the runtime move

  • 63

    Product changes shipped while the programme ran

Challenge

Insurance
18 months · Jan 2024–Jun 2025

Portside ran policy administration on a .NET Framework 4.6.2 application first written in 2011. It worked. It also could not be upgraded, could not be load-tested without a production outage, and had a quoting endpoint that timed out under the volume the sales team had been asked to produce. Two firms had quoted a rewrite with a feature freeze, which the board had already rejected once — the previous freeze, in 2019, had cost them a distribution partner.

Solution

The first thing built was a routing layer, because nothing else could be delivered incrementally until it existed. Then capability by capability, in an order set by risk and visible value: document intake first because it was the loudest daily pain, then the quoting engine onto .NET 8 where the throughput problem was, then policy administration, then the customer portal. Each capability ran in shadow against live traffic with its outputs compared before any of that traffic moved. Product work continued against the legacy system throughout and each migrated capability picked up those changes during its shadow phase. Retired components were switched off and the cost recorded, so the saving is evidenced rather than projected.

Plates

  • Architecture diagram of the routing layer sitting in front of the legacy platform, splitting traffic per capability and per percentage between the legacy application and the replacement services.
    Plate 01Built first. Nothing else could move incrementally until it existed.
  • Shadow comparison report diffing quoting engine outputs between the legacy application and the replacement across live traffic, with the discrepancy count falling to zero over six weeks.
    Plate 02Six weeks of shadow running before the quoting engine took real traffic.
  • Decommissioning record listing each retired component, the date it was switched off, and the annual infrastructure and licence cost it removed.
    Plate 03What was switched off, when, and what it cost. Evidenced, not projected.

Testimony

Eighteen months, no feature freeze, and the legacy system was still serving traffic in the final month. I had been told by two other firms that this was not possible.

Fiona Doyle · Programme Director, Portside Insurance5 out of 5

Adjacent records