Microsoft's CEO just told enterprises they're paying for AI twice.

In a blog post published in July 2026, Satya Nadella argued that AI buyers pay "once with money, and again with something even more valuable: the proprietary knowledge they must reveal to make [AI] useful."

We've seen what that looks like in an Oracle Forms migration, and while it might present as a coding problem, it's really a knowledge problem. The business logic sits in PL/SQL written years ago, often with little or no documentation, and that's exactly the knowledge you don't want to lose, or hand to anyone else.

The challenge: the better a team wants a model to perform, the more knowledge it has to hand over, including what Nadella calls ‘exhaust’: “the prompts people write, the tools agents use, and especially the corrections people make when the model is wrong.” Every correction feeds into the model's understanding of how a business works, insider knowledge that no company would willingly share with its competitors.

The warning carries weight because of who is making it. Nadella leads a company with significant financial stakes in both OpenAI and Anthropic. He isn’t an outside critic of proprietary AI labs; he’s invested in them, which makes the argument harder to dismiss than a competitor’s claim.

The risk is real

The same concern is already playing out in other fields. Earlier this month, Tristan Buckmaster, a mathematician at NYU, published a statement describing his research on the Navier-Stokes Millennium Prize Problem, a major open problem in mathematics, worth $1 million in prize money. The research was developed using several AI models, including OpenAI's Codex.

When Buckmaster learned that OpenAI would soon publish a solution to the same problem, he asked OpenAI “whether the model had been trained on, or had access to, [his] sessions in Codex.” OpenAI publicly responded, saying that its model reached the result independently, but posted on X it "cannot rule out that de-identified data derived from [Buckmaster's] usage of [OpenAI's] products helped improve [its] models."

While the dispute remains unresolved, it raises the question: How safe is it to share your work, and your thinking, with a cloud model provider?

To on-prem or not to on-prem

The answer depends on the provider, product, contract, and deployment model, as enterprises may not have the same level of control over what happens to the ‘exhaust’, and many are only beginning to think through what that means.

That's part of why a shift toward on-premises, open-source models is already underway, embracing the best of both worlds: a contained, on-prem model gets you close to the capability of a state-of-the-art proprietary one, without exposing your business to Big Tech. You keep the efficiency; and you keep the control.

Why this matters for Oracle Forms migrations

For many everyday AI use cases, the exposure Nadella describes is incidental. Someone drafts an email or asks a question, and a little bit of business context is shared along the way. For an Oracle Forms migration, ingesting and extracting business logic is the entire premise.

Picture a Forms module that's been running in production for fifteen years. The person who wrote it retired years ago. Nobody documented what a particular trigger does, why a validation rule exists, or what downstream behavior breaks if it is removed. That knowledge is either saved through discovery, or it's lost the moment the estate is shut down.

Rebuilding that business logic means an AI model must see the codebase to determine what the module does.

That's exactly the concern we described earlier, because that’s the knowledge you least want to leave your environment. It also means the questions Nadella raises for enterprise AI matter more in legacy migration than almost anywhere else: what does the model see, what does it learn from seeing it, and where does that knowledge end up?

Four design questions for responsible migration with AI

When do we need AI, and when don't we?

AI is having a hype moment, and this hype can make it look like the right tool for every job. If you have a hammer, everything looks like a nail. But we think it's worth asking, where AI actually helps in a Forms migration, and where it doesn't.

Some Forms can be converted using deterministic, rule-based logic alone. Others need a combination of both. Take trigger logic, for example: deterministic rules can analyze a trigger and identify which parts execute in the database and which execute on the Forms side, a well-defined task with a clear right answer.

But rules can only apply logic that's already been written. Breaking a trigger apart into client-side, server-side, and database-side code in the target application requires interpretation and reasoning, weighing trade-offs a rule engine can't be pre-programmed to handle. That's where AI earns its place.

We never ask AI to convert code without supervision. An AI coding assistant can help build the target application, while an engineer stays in control. Because AI is concentrated on complex, judgment-dependent code, the highest-stakes business logic gets the most model exposure.

Another area where AI has the advantage is UI testing. Kodesage uses visual agents to test the UI workflows in the target application against the original Forms application. This task has so much variation, that no deterministic approach could handle.

Having said that, it raises a genuinely open question for any migration approach: how much of the complex logic could still be handled deterministically with more upfront engineering, and where is AI needed? It's worth asking rather than making AI the default answer when something looks too complex to automate.

How much access should AI get?

In July 2025, Replit’s AI coding agent deleted a live production database containing 1,206 executive records and 1,196 company profiles, during a public vibe-coding experiment, despite eleven separate all-caps warnings not to touch production during an active code freeze. Asked what happened, the agent's answer was blunt: it had "made a catastrophic error in judgment and panicked.”

This wasn't the only case of AI going rogue. Around the same time, a different AI coding tool destroyed a user's files while attempting to reorganize them, so this is a pattern that shows up when an AI agent is given broad, unrestricted access to production systems.

A Forms migration carries the same risk. An AI coding agent is most valuable to help convert complex modules that deterministic rules can't migrate, and it's also where an ungoverned agent could do real damage: it should never change the Oracle Forms source, and it should never break the target application.

So, Kodesage's coding assistant runs inside a sandboxed environment, with detailed, configurable permissions defining exactly what it can read, execute, or modify. Every change goes through version control, so nothing an agent does is irreversible. If something needs to be undone, it can be, the same way any developer's mistake can be rolled back.

Where should the model run?

In a Forms migration, the model needs access to the source code, including the .fmb and .pll files that hold the business logic. Where the model runs determines whether any of it leaves the customer’s environment.

We chose on-premises or virtual private cloud deployment, with the model running where the customer's data already lives rather than sending requests to an external provider. The Forms estate and the knowledge created during migration, including the codebase, developer changes, and the exhaust Nadella describes, are never shared externally in this deployment.

Which model, and does it have to be proprietary?

A separate question from where the model runs is which model to use. Nadella's proposed response to the data exposure risk is what he calls an orchestration layer, the ability to switch between AI models from different providers rather than being locked into one. That's the same conclusion we've arrived at.

Kodesage ships with an open-source model that we've built the platform around. We keep benchmarking it against alternatives, so customers get the benefit of continuous improvement without being locked into a single model maker. The model performs close to frontier models for Kodesage’s workloads and despite the upfront hardware investment, typically costs less over time than paying per token on a frontier model at scale.

Kodesage’s CEO, Gergely Dombi, put it this way: “At the scale of a migration, token costs add up fast. Running an open model locally costs much less and keeps your business logic inside your own environment."

Customers can still choose a proprietary model such as Opus and keep using Kodesage. What changes is the exposure: that data now leaves the customer's environment, trading the security of a gated, self-hosted model for whatever that provider offers instead.

More enterprises are questioning whether the trade-off is worth it, finding that for some workloads, an open model running locally delivers most of the value of a proprietary model at lower cost and with greater control over data.

Questions for the community

None of the above questions has a single right answer and we don't think any vendor should be the only one answering. If you're evaluating an AI-assisted approach to Forms migration, or to any legacy modernization project, a few are worth putting to anyone building or selling the technology:

We'd genuinely like to hear how others are thinking about this, whether you're building or evaluating a migration solution:

• When does a task require AI, and when does a deterministic approach do the job?
• What can the AI agent do without a human in the loop, and what happens if it gets something wrong?
• Where does the model run, and where does the data end up?
• Are you locked into one model provider, or can you change your mind later

Our answers to these four design questions

For now, our answer is that AI should only handle what deterministic rules can't, access as little as it needs to access, operate inside boundaries an engineer defines, run wherever the customer's data already lives, and never lock a customer into a single provider's roadmap.

And while one goal of AI-powered Oracle Forms migration is to build the target system faster, it is critical to preserve the knowledge embedded in the legacy system without giving up ownership or control of that knowledge in the process.

If any of this resonates, book a call and see how Kodesage Discovery can kick-start your migration project.

Nadella closed his post with a line worth sitting with regardless of where you land on any of this: "In consuming intelligence, you are creating intelligence. And what you create should belong to you."