Seven Legacy Systems, One Migration: Rebuilding a NZ Insurer’s Azure Estate

D2 Solutions is currently engaged on a migration programme for Partners Life, one of New Zealand’s largest life and health insurers. The brief sounds simple: move seven legacy systems out of the delivery vendor’s Azure DevOps and Azure footprint into the insurer’s own, newly built landing zones. Anyone who has done this knows “move” is doing a lot of work in that sentence.

The systems are the connective tissue of an insurance operation: call recording uploads, document ingestion, scanning integrations, survey automation, an online claims channel, policy platform tooling, and middleware between core insurance systems. Built over a decade, by different teams, on different generations of Azure. That decade is the real migration problem.

Inventory first, opinions second

Week one produced no Terraform and no pipelines. It produced an inventory: every system mapped to its repositories, build and release pipelines, target subscriptions, runtime services, and risks. Boring, and the highest-leverage work of the whole programme.

The inventory is what surfaced the truths that shape everything after: workloads spread across multiple Azure tenants accumulated over the years; shared file-format contracts between systems that must not drift during the move; components running on deprecated platforms, including service models Azure retired years ago; and repositories where main, master, and trunk all coexist with none of them obviously authoritative. You cannot scope, price, or sequence a migration until that list exists. Every hour spent on it repaid itself the first planning week.

Per-workload landing zones

The target architecture gives every workload its own subscription, its own VNet, and its own resource group, with a strict naming convention carrying environment, region, and workload in every resource name.

This is the single best structural decision in the programme, and it is the client platform team’s, not ours. Blast radius shrinks to one workload. Cost attribution is native, the subscription is the invoice line. Terraform state splits cleanly per workload with no mega-state to lock and fight over. And the naming convention works as a contract: our infrastructure code integrates into a landing zone the platform team provides, VNets and subscriptions included. We do not create network topology; we inhabit it. That boundary, platform team owns the zone, delivery team owns what runs inside it, removes a whole category of turf war.

The corollary: the old code’s naming logic gets rewritten, not adapted. When the convention is the contract, half-matching it is worse than not matching it.

Credentials belong to the platform, not the repo

A decade-old estate treats credentials the way its era treated them, service principal secrets in configuration files, connection strings in pipeline variables, keys copied between environments. Part of this migration is drawing a hard line: on the target side, pipelines authenticate with workload identity federation on service connections the platform team pre-created, configuration moves into pipeline libraries, storage access goes to managed identity and RBAC instead of keys, and anything that ever lived in a repository gets rotated on the way out, as a matter of policy, whether or not anyone believes it leaked.

The satisfying part of federation is what disappears: no secret to store means no secret to expire, rotate, or find in an old branch three years later.

The Logic App in a VNet problem

The sharpest architectural puzzle so far: a workload built around a Consumption Logic App reading and writing storage accounts, meeting a new requirement that storage must not be publicly reachable.

Consumption Logic Apps do not integrate into a VNet. Whatever firewall story you attempt around that, you end up whitelisting broad shared IP ranges, which is not private in any meaningful sense. And a private endpoint on the storage account is only reachable from inside a VNet, so an outside Logic App collapses back to the same shared-IP problem.

The clean answer is Logic App Standard: single-tenant, VNet-integrated, sitting inside the workload’s VNet next to the storage private endpoints, with managed identity replacing keys end to end. The honest caveats: Standard is an always-on hosting plan, a new fixed monthly cost against Consumption’s pay-per-execution, and workflow conversion is real re-authoring work, not a toggle. We put those trade-offs on the table with numbers before anyone committed. On a tight budget, surprise architecture is worse than expensive architecture.

Budget discipline as an engineering practice

This programme runs on a rule we would recommend to anyone: if a task starts consuming disproportionate time, escalate immediately and re-approach; never grind silently. Blocked on one workload means opening the next one in the stream, doing its discovery, and returning when the approach is agreed. The seven systems land across three batched release windows in a roughly twenty-week programme: security review across several workloads, then a deployment burst per window, on a published timeline with a fixed UAT window per workload.

None of that is glamorous. It is how a seven-system migration lands on schedule for a business whose regulators, advisers, and policyholders do not care about our infrastructure diagrams.

The pattern that transfers

Strip the specifics and the playbook holds for any legacy estate: inventory before opinions, per-workload isolation with naming as a contract, workload identity over stored credentials, modernise the platform generation while you move (serverless containers and app services, no orphaned VMs, no retired service models), and price the architecture honestly before you build it. That is the work D2 Solutions does; the insurance details are just this quarter’s flavour.