Moving Without Breaking

The fastest way to change a company with AI is the one that looks slowest.

That sounds like a paradox, so start with the constraint every company faces on day one: it can't stop. Invoices keep arriving, customers keep writing, orders keep shipping. Whatever AI changes has to change while all of that continues, on top of systems that were never designed for it, used by people who already have full workloads.

The tempting answer is a clean break. Pick a new platform, migrate the data, retrain everyone, switch over on a date. It looks decisive on a steering-committee slide. It also puts all the risk on one day.

My argument is the opposite: wrap what exists instead of replacing it. Add AI alongside the running work, move it forward one stage at a time, make every stage worth having even if the program stops there, and keep every step reversible. Done this way, results show up in weeks, and no single date can sink the project.

Why the clean break fails

Two reasons, one old and one new.

The old one is that big IT projects go wrong in the tail. When Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects, the average cost overrun was 27 percent, which sounds survivable. But about one project in six overran its budget by an average of 200 percent and its schedule by almost 70. Their sample covers IT projects in general, not only cutovers. Still, a plan that puts all its risk on one switch-over date is the plan with the least room to recover when it lands in that tail.

The new reason is specific to AI: the thing you are migrating to won't stand still. The capability you design around today will be different in six months. A two-year transformation built on this year's model is a bet that nothing important changes before go-live, and that is a bet I wouldn't take in this field.

There's a third cost that's easy to miss. A big-bang migration delivers nothing until cutover. That means months of spending before anyone sees a result, and every one of those months is an opportunity for the sponsor to move on and the budget to be cut.

Scroll sideways to see the whole figure

How engineers replace a system they can't turn off

Software engineering hit this problem decades ago in a different form: how do you replace a large system that the business runs on every day?

The best-known answer has a botanical name. Martin Fowler called it the strangler fig, after a plant that grows around a host tree until it can stand on its own. You build new components next to the old system, route one small piece of behavior to them, and keep moving pieces over until the old part has nothing left to do and can be retired. Fowler's case for it rests on three things: value arrives early, because each new piece goes live on its own; risk stays small, because each step is small; and the team learns how the old system really works as it goes, which improves every later decision.

A companion pattern, called parallel change, handles the joins between old and new in three moves. Expand: add the new way alongside the old one. Migrate: move users over gradually. Contract: remove the old way once nothing depends on it.

With AI, the "old system" is usually a process rather than a codebase: a mix of applications, spreadsheets, email and people's judgment. The pattern still works. An AI layer starts alongside the process, takes over small, checkable slices, and expands as it earns trust. The existing systems stay the source of truth throughout. The AI reads from them and writes back into them through the same paths people use.

One mailbox, stage by stage

Take an accounts-payable team that answers supplier emails: where's my payment, send me the remittance, here are our new bank details. Here is how that operation moves through the pattern, and why each stage earns the next. The numbers in the figure are illustrative; the order is the point.

Scroll sideways to see the whole figure

Observe. The AI layer reads the work as it flows (the shared inbox, the invoice records in the ERP, the replies people send) and does nothing else. The output is a map: what kinds of requests arrive, how often, how they get resolved, where they wait. Few teams have ever seen their own work counted this way, so the map is useful even if the program stops here. It does need read access first, which is often the slowest part of the whole effort (Data Access Is the Real Integration Project).

Shadow. In shadow mode, the AI produces what it would have done for each real case (a classification, a draft reply, a proposed ERP entry) and nothing takes effect. People keep working as before, and their decisions become the answer key. After a few weeks you know, on your own cases, where the AI agrees with your people and where it doesn't. That's an evaluation built from your own work, the thing most programs never get around to building.

Assist. The AI's output now reaches people as suggestions: a draft they can send, a coding they can accept. People still act. This is where time savings begin, and where you learn the most important fact about the whole effort: whether checking a suggestion is actually faster than doing the work.

Act on one slice. For one narrow, well-understood category, say payment-status questions on invoices that match a purchase order, the AI acts within limits. It sends the reply or updates the record, everything is logged and reversible, and a sample gets reviewed. Everything else stays as it was.

Widen. Each further category moves over only when its own evidence is good: agreement with people in shadow, error rates in the acting slice, and how much a mistake in that category would cost.

Retire the old step. Only when a step has nothing left to do does it go, and if it was quietly doing a job (a check, a signature, keeping a manager informed), that job gets kept in another form (Why the Process Exists).

Each stage should be worth having even if the program stops there.

That sentence is the real test of a staged plan. Priorities change and sponsors leave. A program whose value only arrives at the end is a program that may never deliver anything. A program whose first stage already produced a map of the work, and whose second produced evidence on real cases, has paid its way whatever happens next.

What "reversible" actually takes

Everyone says reversible. It takes deliberate design, and four properties do most of the work.

Writes go through the same doors as people's writes. If the AI updates an invoice record through the ERP's normal interface, the change carries the usual history, validations and permissions. If it writes straight into the database to save time, it skips all three, and undoing a mistake turns into forensic work.

Every action leaves a trace with its reason. Who or what acted, on which item, with which input, and why. That trace is what lets you find and undo a bad batch, and it's what auditors and managers will ask for the first time something goes wrong.

Actions are sorted by how hard they are to undo. A draft is free to undo. An updated record usually can be undone. An email to a supplier can't be unsent. A payment needs a recovery process. How much the AI may do on its own should follow that sorting, and never the other way around.

There is a switch. Someone can turn off the AI's acting role for one category, instantly, and the process falls back to the previous stage with nothing breaking. Build the switch first. Every later decision gets easier when its downside has a floor.

Keep the exits open

Moving without breaking also means being able to move again. Today's vendor, model or tool won't be the best choice for every part of your work in two years.

The parts of the setup worth protecting are the ones that describe your own work: connections to your systems, your evaluation cases, which actions need which permissions, the record of what was decided and why. Open standards help keep those portable. The Model Context Protocol, now maintained under the Linux Foundation's Agentic AI Foundation, gives AI applications a common way to connect to tools and data, so a connector to your ERP doesn't have to be rebuilt for every AI client. Plain, well-written documentation of how your work runs is portable to any model. Contracts that guarantee data export and reasonable notice are portable in a different sense (Choosing a Model Provider Without Marrying It).

Where I wouldn't use it

Gradual change has costs, and pretending otherwise is how good patterns get a bad name.

Running two things at once is expensive. Connectors that coexist, people who check both, duplicated monitoring. Fowler counts this as the price of lower risk, and it's real. If the old process is genuinely broken and cheap to replace, wrapping it can cost more than starting over.

Some work doesn't split into slices. A monthly close where every step depends on the one before, a negotiation, a single large decision. Observe, shadow and assist still apply. "Act on one slice" may not exist, and the AI may stay in an assisting role for a long time. That's fine.

Someone has to own the stages. Without a named person who decides, on evidence, when to widen, programs stall at "assist" forever. People save time, nobody changes the work, and the gain never shows up anywhere it can be counted.

Wrapping can preserve what should change. Fowler's own warning applies: if the team and habits that produced the old mess stay the same, the new layer becomes the next mess. Wrapping buys time to redesign the work. It doesn't do the redesign.

What to do

Refuse the cutover date. If a plan's value arrives in one go at the end, ask for a version where the first stage pays for itself.

Start with observe and shadow on one operation. Get read access, map the work, and let the AI shadow your people until you know where it agrees with them. That evidence is worth more than any vendor benchmark.

Promise results at each stage, and refuse to promise the end state. The end state depends on what the evidence shows and on what models can do by the time you get there. A roadmap that pretends otherwise is planning to be wrong (Designing an AI Program That Ships).

Design for reversibility from the first day. Normal interfaces for every write, a trace for every action, autonomy that follows how hard an action is to undo, and the off switch built before anything goes live.

Own what describes your work. Connections, evaluation cases, permissions, decisions. Those are what let you change vendors, models and tools without starting over, as you sooner or later will.

Check yourself

Why is a clean break especially risky with AI?

It puts all the risk on one switch-over date and delivers nothing until then. Also, the capability you design around today will be different in six months.

What does shadow mode give you that you cannot easily get otherwise?

The AI produces what it would have done on real cases while nothing takes effect, and people's decisions become the answer key. You learn where it agrees with them on your own work.

Why should how much the AI may do on its own follow how hard an action is to undo?

A draft is free to undo, but an email can't be unsent and a payment needs a recovery process. Autonomy sorted that way keeps the downside of every step bounded.