Your modernization vendor's cloud is not a neutral place to process your estate.

There's a question that gets skipped in almost every modernization pitch, and it's the one that should be asked first: when you reimagine my legacy system with an AI model, where does my code go? Not the output. The source. The COBOL that encodes thirty years of business rules nobody fully remembers. The data the rules run against. When a foundation model "analyzes and reimagines" an estate, that estate has to be somewhere the model can read it. The pitch deck never dwells on where.

For most software, the answer doesn't matter much. For a bank's core, a hospital's claims engine, or an insurer's policy system, it is the entire matter. AWS Transform reached general availability in May 2025 and modernizes to AWS. Google Cloud's reimagine and Dual Run target Google Cloud. Azure's app-modernization targets Azure. These are serious tools built by serious teams — and in every case, your source is processed in the vendor's cloud, and the destination is the vendor's cloud. That isn't a flaw in their engineering. It's the shape of their business.

The boundary is a design decision, and someone is making it for you

The thesis: for a regulated estate, the perimeter your modernization runs inside is not an implementation detail to be optimized later — it is the first architectural choice, and if you don't make it deliberately, your vendor makes it for you in the direction of their cloud.

Consider what "process your estate in our cloud" actually entails. Your source code crosses your network boundary. It is held, transiently or not, in an environment governed by someone else's controls, someone else's region policy, someone else's subprocessor list. For an estate under a data-residency mandate or a regulator who will ask "where, physically, was this processed," the honest answer becomes: it left. Maybe it left safely. But it left, and now the proof of where your most sensitive logic was handled lives in a tenancy you don't own.

The alternative is not to forgo AI. It's to move the model to the estate instead of the estate to the model. A per-customer model, forked and run inside your boundary, reads your source where it already lives. The code and data never cross the perimeter. There is no external token meter on the model, because there is no external model — it's yours, in your walls, for the duration. The reimagining is just as capable; what changes is the only thing that mattered to your compliance officer in the first place: nothing left.

Cloud-agnostic is a position, not a feature

There's a second consequence that compounds the first. If the model runs in the vendor's cloud, the modernized workload is born there too. You don't choose the target; the target is the price of admission. And the agnostic cost waterfall — what this estate would actually cost to run on AWS versus Azure versus on-premise — is the one comparison a hyperscaler will never put in front of you, because three of the four answers aren't theirs to sell.

When the company doing the modernization also owns the destination, "which cloud is right for your estate" stops being a question and becomes a foregone conclusion.

The reasonable counter is that hyperscaler tooling is mature, deeply integrated, and backed by enormous teams — why fight gravity? Because the gravity only points one way. For the bank that needs to keep its core on-premise for another regulatory cycle, for the insurer weighing a genuine multi-cloud posture, for the health system whose data simply cannot leave a jurisdiction, "modernize, but only onto our cloud" isn't a smaller version of the right answer. It's the wrong answer wearing the right logo.

The work can run where your estate already lives, target the cloud that actually fits it, and leave behind a signed record of every step — without your source ever crossing the wall. That's not a constraint we accept reluctantly. It's the product. The boundary isn't where the modernization is limited. It's where it belongs.