Why AI adoption needs migration discipline

I have spent a lot of my career on migrations. Moving systems from old to new while customers keep using them. The rule I try to follow is simple to say and hard to do. Systems keep serving millions during change. Nothing breaks. Nobody gets left behind.

Lately I have noticed something. Many organisations are adopting AI agents with far less care than they would give to moving a single database. That worries me a little. AI adoption is a migration. It changes how work flows, who decides what, and where data goes. It deserves the same discipline.

Here is how I think about it, in four parts.

Governance: know what is running

In a good migration, you have an inventory. You know which services exist, who owns them, and what they touch. Surprises are the enemy.

With AI, the inventory is often missing. People sign up for tools on their own. Agents get access to shared drives, inboxes and code repositories because it was convenient on a Tuesday afternoon. Nobody is quite sure which prompts contain customer data.

Governance does not have to mean a heavy committee. It can start with a list. Which agents and models are in use, for what, with which data, approved by whom. Add clear rules for sensitive information and a simple way to request something new. That alone removes most of the scary unknowns.

Integration: plan the cutover

Migrations fail at the seams. The new system works fine on its own and breaks the moment it talks to the old one.

AI agents are the same. A demo looks brilliant in isolation. Then it meets real systems with real permissions, rate limits, odd data formats and approval steps, and things get messy.

So I treat agent integration like any other cutover. Start in a sandbox. Run in parallel with the existing process before replacing it. Define what success looks like in numbers, not vibes. Keep a rollback path. If the agent produces something wrong, how do we notice, and how fast can we go back to the manual way?

The teams that skip this step tend to learn it later, usually on a Friday.

Accountability: a human owns the outcome

In every migration I have run, every component had a named owner. If it broke at midnight, someone’s phone rang.

Agents blur this. When an agent writes code, drafts a contract clause or answers a customer, who is responsible for the result? The answer has to be a person. Not the vendor, not the model, not “the AI.”

In practice this means a few things. Agent output is reviewed by someone with the skill to judge it. High impact actions need explicit approval. Logs are kept so you can see what the agent did and why. And people are trained, properly, so nobody is left behind or quietly afraid of the new tools. Adoption that leaves half the team confused is not adoption. It is a split.

I lean heavily on my own background here. Because I understand the hardware and the software underneath, I can evaluate what an agent produces rather than just trusting it. Not everyone has that background, so the process has to provide the checks instead.

Cost: measure before it surprises you

Migrations always have a budget, and the budget is always tested. Cloud bills taught many of us this lesson already.

AI has its own version. Token usage grows quietly. An agent stuck in a loop can burn through a surprising amount overnight. Ten teams each choosing a different tool means ten contracts and ten sets of risks.

The fix is unexciting and effective. Track usage per use case. Set limits and alerts. Compare the cost of the agent with the cost of the work it replaces, honestly, including review time. Some use cases will pay for themselves many times over. Some will not. Both answers are useful.

Start small, repeat what works

The best migrations I have seen moved in waves. A small, low risk slice first. Learn. Then the next slice, a little bigger.

AI adoption works the same way. Pick a handful of use cases where the value is clear and the risk is low. Make them repeatable, with clear inputs, checks and owners. Write down what you learned. Then expand.

None of this is new. That is rather the point. We already know how to change important systems without breaking them. We just need to remember that the rules still apply when the new system can talk back.