Background

Northern Trust has been a bank since 1889. Today it holds $18.7 trillion in assets under custody and administration and manages $1.8 trillion of it — the roughly tenfold gap between those two numbers being the entire economic story of a custody bank. It runs two reporting segments, and the smaller one is the interesting one: Wealth Management carries about $507 billion in AUM and out-earns the much larger Asset Servicing business on net income. It serves ultra-high-net-worth families and family offices across 19 U.S. states plus London, Guernsey, Singapore, and Abu Dhabi. It is a Category II institution under the Federal Reserve's tailoring rules — annual capital plans, supervisory stress tests, enhanced risk management.

Enrollments is the primary web interface for getting a new client into that wealth-management business. When I joined as a platform engineer in September 2024, it ran on Pivotal Cloud Foundry.

That last fact had recently become a problem, and not for any technical reason.

Broadcom closed its ~$61 billion acquisition of VMware on 22 November 2023. Nineteen days later it ended perpetual licensing across the portfolio. Six weeks after that it terminated the entire VMware partner program. By 6 May 2024, every legacy Tanzu SKU — including, named explicitly in Broadcom's own end-of-availability notice, Tanzu Application Service, the product the industry still called PCF — was declared End of Availability. A separate notice told customers on core-based TAS licenses they would migrate to application-instance-based licensing at their next renewal.

Read that pricing change slowly, because it's the whole story. A per-core license is priced on the infrastructure you own. A per-application-instance license is priced on how many apps you run. Every enterprise that had spent five years telling its developers to cf push more services onto a fixed fleet of cores woke up to find the meter had moved onto the exact axis they'd been optimizing upward. The bill doesn't scale — it re-bases. And it re-bases at renewal, which is precisely why 2024 and 2025 are when everyone left.

The reaction was not subtle. AT&T sued Broadcom in August 2024 alleging a 1,050% increase, after Broadcom threatened to cut support for ~75,000 VMs across 8,600 servers. European cloud providers reported hikes of 800–1,500% to the European Commission, earning Broadcom a "RED" rating from CISPE's competition observatory. A Dutch court had to order Broadcom to keep supporting a government agency mid-migration after an 85% increase. In April 2025 the minimum license purchase went from 16 cores to 72.

Worth being precise about, because a knowledgeable reader will check: Broadcom didn't kill Cloud Foundry. It ships today, renamed twice over — Tanzu Platform for Cloud Foundry, now Elastic Application Runtime — and the open-source project is healthy. PCF wasn't obsolete. It was repriced. Every large shop running it did the same arithmetic in 2024 and got the same answer: leave before renewal.

I spent September 2024 through May 2025 on the side of that arithmetic where someone has to actually do it.

Challenge

• A migration with a contractual deadline is a different animal. Normally you migrate when the new thing is better. Here the clock was a renewal date set by someone else's pricing committee, and the target platform's advantage was that it wasn't a VMware invoice. That inverts the usual sequencing: you don't get to wait until the destination is perfect.
• Enrollment is a recursive graph, not a form. This is the thing that makes UHNW onboarding categorically harder than retail, and it comes straight out of FinCEN's Customer Due Diligence rule. Every legal entity customer requires identifying each individual owning 25% or more — up to four of them — plus one individual with significant control. Up to five natural persons per entity, each needing full identification and verification. Now consider what a family office actually looks like: trusts owning LLCs owning partnerships owning holding companies. Each node in that ownership tree triggers its own five-person fan-out, and you have to discover the tree before you know how big the job is. Any system that models enrollment as a linear wizard is wrong the moment it meets a real client.
• The account can exist before the client is proven. The Customer Identification Program rule permits verifying identity within a reasonable time after the account is opened. That's a gift to the business and a curse to the engineer: it means "enrolled" isn't a boolean. There's a verified-pending state in the middle, and every downstream entitlement has to respect it — which is a state machine problem masquerading as a compliance checkbox.
• Authorization has to be capacity-aware, not just identity-aware. A trustee acting as trustee has different powers than the same human acting for themselves. A family office's CPA, an agent under power of attorney, a beneficiary, an investment consultant — same person, different capacities, different accounts. Entitlements aren't a table lookup; they're a join across systems that disagree about what identity even means.
• The security bar is FAPI, not "did you validate the JWT." The financial-grade API profile makes sender-constrained tokens mandatory — bearer tokens aren't acceptable, every access token must be bound to its client via DPoP or mTLS certificate binding, with proof-of-possession and non-repudiation on both interfaces. That is not a bar 200 application engineers should each be clearing from scratch.
• There is no maintenance window. A Category II bank sitting on $14.9 trillion in custody doesn't take the platform down on a Saturday. Add DORA coming into force in January 2025 across the EU entities, four separate regulatory regimes in the Wealth Management footprint alone, and audit trails that must reconstruct what you knew and when — including the ownership graph as it stood on the day you made the decision. Enrollment records are evidence, which means append-only, not last-write-wins.
• The hallway is asleep. Northern Trust's single largest employee region is Asia-Pacific — 42% of staff, against 41% in North America — with its IT centre of excellence in Pune. Chicago to Pune is a 10.5-hour offset: effectively zero natural overlap. You cannot resolve a design question by walking to someone's desk when the desk is on the other side of midnight.
• And the tooling moved under us. The AzureRM Terraform provider shipped v4.0 on 22 August 2024, weeks before I started — the first major version in roughly 29 months, with a 1,300-line upgrade guide, ~70 removal entries, and 126 resources with changed behavior.

Solution

Getting off the license

I migrated the on-prem PCF infrastructure to Azure for Wealth Management, cutting infrastructure costs by ~40%. The number is worth reading in context: a chunk of it is simply not paying a repriced license anymore, and the rest is what happens when you stop sizing for a fixed on-prem fleet and start sizing for actual load. Both halves only exist because someone did the unglamorous work of moving a regulated application without dropping it.

The modules are the coordination mechanism

I led end-to-end development of Azure/AWS Terraform service modules used by 200+ engineers, with optimizations that cut ~$100k/month in cloud spend, and consolidated modules for key Azure and AWS resources to speed up deployments.

The 10.5-hour timezone split is exactly why this matters more here than it would elsewhere. When there's no hallway, the module is the conversation. A published, versioned module is a design decision that doesn't need a meeting to transmit — it's how a platform team talks to engineers who are asleep when it's working.

It's also where the FinOps savings actually come from, and the mechanism is worth naming honestly: you don't cut cloud spend by telling people to cut cloud spend. You cut it by moving the default. When one reviewed module ships the right SKU, the right redundancy tier, and the right retention period, the expensive choice stops being the path of least resistance and starts requiring an explicit override that someone has to review.

The hard part of shared modules is an asymmetry nobody warns you about: you have all of the responsibility and none of the visibility. You can't run your consumers' plans. You can't see their state. You don't know which of your outputs they indexed into. Your blast radius is other people's code.

Surviving AzureRM v4

I upgraded the AzureRM modules to v4 with multi-region support, improving resiliency for 100+ engineers. Three things in that release are worth knowing, because they're a tidy illustration of why platform work is different from application work:

• subscription_id became mandatory — but only for Azure CLI authentication, not for service principals, OIDC, or managed identity. Meaning: the CI pipelines were fine. Every engineer's laptop was not. The breakage lands entirely in the long tail you can't see.
• address_space changed from a list to a set. Sets are unordered, so any downstream code doing ...address_space[0] silently stops meaning what it meant. That's not a type error you catch in review — it's a semantic break in consumer code you don't own and can't test.
• Several SKU defaults flipped to Standard. A rename fails loudly; a changed default fails quietly, in a plan nobody read closely, and on a load balancer or public IP a Basic→Standard flip is a destroy-and-recreate. In production.

One auth library instead of fifteen

To protect ~$450B in assets under management, I built the authentication and authorization library used across 15+ APIs and microservices. Given the FAPI bar — proof-of-possession, channel binding, non-repudiation — the argument for centralizing this isn't tidiness, it's leverage: fifteen teams independently implementing sender-constrained tokens produces fifteen chances to get it subtly wrong, and in a wealth platform the subtle wrongness is the whole risk. One library, correct once, is how you make a specialist-grade standard survivable for engineers who aren't identity specialists.

Proving it, not asserting it

I led the plans for penetration and security testing for the Enrollments migration and drove them to completion — which in a Category II bank is not a formality, it's the thing that lets the migration happen at all. Alongside that: DevOps/SecOps guides and Terraform module refactors that reduced security incidents ~11% year over year, and enhanced CI/CD scripts and configs for the GitHub Actions pipelines deploying Azure resources via Terraform.

The unglamorous $200k

I also saved ~$200k annually by accelerating login times ~93% for ~60 engineers using Python browser automation. It's the least architectural thing on this list and one of the highest-return: sixty engineers each losing minutes a day to an authentication dance is a real number, it just never shows up on anyone's roadmap because it isn't anybody's feature.

Results

Wealth Enrollments came off Pivotal Cloud Foundry and onto Azure ahead of the license, with infrastructure costs down ~40%, a further ~$100k/month out of cloud spend, security incidents down ~11% year over year, and pen testing completed rather than promised. The Terraform modules underneath it serve 200+ engineers across an org whose largest region is eleven hours from Chicago, and the auth library fronting it covers 15+ APIs guarding roughly $450 billion in client assets.

Why this matters for a business:

• Your platform's licensing terms are an architectural dependency. Nobody puts "the vendor gets acquired and reprices the metric" on a risk register, and yet in 2024 it moved more enterprise workloads than any technical argument did. If a single vendor decision can force a migration on a deadline you don't control, you're already exposed — and the DORA regulation coming into force in the middle of all this exists partly because regulators worry about exactly that concentration risk.
• In a distributed org, the interface is the org chart. With no timezone overlap, shared modules and shared libraries stop being engineering hygiene and become the coordination mechanism. That's an organizational argument for platform work, and it's usually the one that actually persuades people.
• Compliance rules are system requirements in a costume. "Verify within a reasonable time after opening" is a state machine. "25% beneficial ownership, up to four, plus one control person" is a recursive graph traversal with unbounded fan-out. Read them as engineering specs and they get much easier — and much harder — than they look.
• Centralize the things where being subtly wrong is expensive. Auth is the canonical case. The reason to build one library isn't DRY; it's that the standard is genuinely hard, the failure mode is silent, and the assets behind it are measured in hundreds of billions.

Conclusion

This was a migration nobody chose, on a clock nobody set internally, for a platform that couldn't go down, at a bank that gets stress-tested by the Federal Reserve, with the team that owns half the work asleep for most of your day. The interesting engineering wasn't in the destination — Azure is Azure. It was in doing it without dropping a regulated onboarding platform, and in building the modules and libraries that let two hundred engineers move with you instead of behind you.

If you're staring down a forced migration, a licensing gun, or a platform that has to move without going down, that's the shape of problem I do well. Book a call and let's talk.