Migrating New Zealand’s Electricity Market Regulator Between Azure Tenants

Some engagements are interesting because of the technology. This one is interesting because of who it is for: the Electricity Authority (Te Mana Hiko), the Crown entity that governs New Zealand’s electricity market. The Authority regulates the operation of the electricity system for the whole country, which puts its digital estate firmly in governance territory: identity, compliance, market registers, and levy systems that market participants depend on every day.

D2 Solutions is engaged on the programme as the DevOps practice, working alongside the primary vendor’s team, fully remote from Croatia into a New Zealand government context. The task: move four public-facing portal applications (identity, compliance, the market register, and levy management) from one Azure tenant to another, and in the same move consolidate the estate from five Azure regions into New Zealand North for data-residency compliance, without breaking the market processes that run on top of them.

Why tenant-to-tenant is its own discipline

A tenant migration is not a lift-and-shift. Regions stay the same, SKUs stay the same, and yet everything that matters changes underneath you: Entra ID identities, app registrations, managed identities, RBAC assignments, Key Vault instances, SQL servers, DNS. Every implicit assumption the codebase ever made about “where things live” surfaces at once.

The applications in scope share a common core library. That is a blessing and a trap. A blessing, because fixing a cross-cutting concern once fixes it for every portal. A trap, because anything hardcoded in that core is hardcoded for every portal too.

The single biggest technical lesson of the programme so far: hunt down hardcoded endpoints before you plan anything else. We found the Key Vault endpoint compiled into the shared core as a string literal, selected by environment name and pointing at the source tenant’s vaults. No app setting could override it. Until that one line became configuration-driven, no amount of infrastructure preparation could make the target tenant real. Inventory your literals first; they are your true critical path.

Passwordless by default

The target architecture removed credentials wherever a credential used to be:

• SQL access moved from username and password in Key Vault to managed identity authentication. Two secrets deleted, one class of rotation problem gone.
• Blob logging moved from connection strings to a managed identity client.
• Key Vault access was always identity-based, now against the target vault with least-privilege roles: the app’s identity holds Secrets User, nothing broader.
• The sign-in flow itself needed no client secret at all. Resource access is managed identity plus RBAC, and user sign-in rides the ID token flow. The app registration in the target tenant holds zero credentials, which is exactly how we want a regulator’s identity portal to look.

The pattern is worth generalising: a tenant migration is the best excuse you will ever get to delete secrets. Every credential you do not carry across is a credential you never rotate, leak, or explain in an audit again.

Classic releases out, YAML in

The deployment path was rebuilt from classic release pipelines to YAML pipelines in Azure DevOps, one per application, with build and deploy stages, tightly scoped service connections (one per app, each holding Contributor on exactly one resource group), and environment approvals in front of every deploy.

For a governance body, the granularity is the point. A service connection that can touch one application’s resource group and nothing else is an easy security conversation. First-run approval gates on service connections and environments mean a human confirms each new deploy path exactly once, deliberately.

One incident sharpened this thinking early: a classic release definition with event-based triggers on its stages started all of them, including a production-pointing one, on release creation. It was caught and cancelled with nothing deployed, but the conclusion stuck. Event-triggered classic stages are a footgun in a migration context; explicit, manual, YAML-defined deploys are the way.

The 403 that means it is working

Target-side applications sit behind Azure Front Door with origin access restricted at the network level. Hitting an app’s azurewebsites.net hostname directly returns 403, by design; the public URL is the Front Door one, on the Authority’s own domain.

That trips people up in validation: the first healthy deployment “looked broken” until checked through the right front door. Worth encoding in every migration runbook: know which URL is the contract, and test the chain the users will actually traverse, including redirect flows to the sign-in page.

Cutover as waves, not a weekend

Production cutover is planned in two waves that follow the data, not the org chart: applications sharing a database move together inside a 15 to 60 minute downtime window per wave, DNS repoints while custom domains stay stable, databases replicate with a delta sync inside a freeze window, and rollback triggers are quantified in advance, error-rate and authentication-failure thresholds decided before the window opens, not negotiated during it.

That is what a governance-grade migration looks like in practice: not heroics, but sequencing, least privilege, and numbers agreed while everyone is calm.

What this engagement says about D2

This programme is D2 Solutions working inside a New Zealand government governance context, remotely, under least-privilege access, alongside another vendor’s engineers, on infrastructure a national market depends on. If you are planning a tenant migration, an Entra consolidation, or an estate move in a regulated environment, this is the work we do.