AI transformation is starting to look like cloud migration

Choosing the platform was usually the cleanest part of a cloud migration. I’m starting to see the same pattern in enterprise AI.

I spent five years at Mesosphere shipping cloud infrastructure into large companies. Buying it left them with the work of deciding what could move, what had to change, and who would keep it running.

I’d plan an AI deployment around those decisions from the start. An agent needs access to the company’s systems, a process it can follow, and someone responsible when it gets stuck. The platform purchase won’t settle any of that.

Someone still had to own the migration.

Cloud platforms made it easier to provision infrastructure on demand. Companies still had to build platform teams, migration standards, security controls, cost-management practices, and a new path to production. The cloud became useful as those operating practices matured.

The bill needs an owner even when nobody recognizes the workload.

In this 2024 incident, Maciej Pocwierz's test bucket received almost 100 million requests in a day from misconfigured systems he didn't operate, producing a bill of more than $1,300. AWS subsequently changed the billing rule.

Enterprise AI needs its own version of that layer. Someone has to decide which jobs are ready for an agent. The agent needs instructions grounded in how that job is performed. Company policy has to attach to the steps it will take. Exceptions need an owner and a way back into the next run.

Model access answers none of those questions by itself.

Early enterprise AI programs can look busy without moving much work into production. The licenses and models are ready before the workflows, controls, and ownership are.

The cloud migration plan often started with the infrastructure estate. Teams inventoried applications, dependencies, data, and owners before deciding what could move.

Many AI programs start with the model and a list of use cases from a workshop. The team selects a promising job, turns an SOP into a prompt, and connects the obvious tools. It learns the dependencies when the agent reaches its first live case.

A global retailer we spoke with had already mapped its customer-support processes in Visio. It had Salesforce Service Cloud, Agentforce, Copilot, and roughly 1,400 support agents. The automation was still waiting on connections to enterprise services. Each connection required a ticket, and the responsible teams had huge backlogs.

The company had chosen the platform and mapped the process. It had not cleared the path the agent needed to run.

The equivalent of a cloud dependency map for AI includes the systems the job touches, the permissions available, the data classifications, the approval points, and the exceptions operators handle. These details determine whether a use case is deployable.

They belong in the plan before the pilot starts.

Cloud teams migrated applications and workloads. AI teams are changing jobs.

That makes the unit smaller in one way and more complicated in another. A job can cross five applications, three teams, a spreadsheet, and an unwritten approval. The software dependencies matter, but so do the decisions people make between systems.

I would assess one recurring job through four questions:

The answers create a deployment sequence. Start with jobs whose process is understood, whose required systems are reachable, and whose outcome can be measured. Keep the uncertain or irreversible steps with people. Add autonomy as the agent handles more cases cleanly.

The sequence turns a long list of use cases into a smaller set of jobs that can reach production.

The cloud comparison has one important limit.

An application leaves artifacts. It has code, infrastructure, data stores, owners, and traffic. Even an old application can usually be inventoried before a migration begins.

Operational work is less legible. The official SOP describes the clean path. The exceptions live in Slack threads, spreadsheets, old tickets, and the heads of the people who handle them every day. Two people with the same job title may complete the work differently because one learned a better way.

An AI transformation program has to discover that operating logic before it can move the job. Otherwise the agent inherits the documented process and meets the real one in production.

At WIQ, we call the record of that logic a blueprint. It captures the steps, systems, guardrails, and escalation paths for one job. Each correction can update the blueprint, so the next run starts with what the last one learned.

That discovery layer is the extra work AI adds to the migration.

Cloud transformation produced central platform teams because application teams needed common infrastructure, controls, and support. Enterprise AI will create a similar central function, but it cannot own every job.

The AI or platform team should own the shared runtime, connectors, security standards, and evaluation practices. The process owner should own the workflow and its outcome. Privacy, security, and data teams should approve the boundaries under their control.

That division keeps the central team from becoming the author of processes it does not run. It also gives operators a way to correct the agent when the work changes.

The cloud transition took years because companies changed more than their infrastructure. AI transformation will follow the same pattern. The companies that make progress will build the operating practices while they deploy the technology.

If this is the work you're leading, join Praveen Akkiraju, Swamy Kocherlakota, and me for Learnings from $4B invested in Enterprise AI. We'll compare where programs stall after the pilot and how teams turn early use cases into an operating model.