The speed was never the problem. The unchanged operating model was.
Years ago I worked the cloud lift-and-shift era from the inside. The pitch was simple and everyone believed it: move to the cloud, costs go down, agility goes up. So we moved. We rehosted the applications, kept the same processes, the same team structure, the same way of working, and waited for the savings.
The team I was on could see what was coming, and we tried to get the business to slow down enough to redesign the things that mattered. We were overruled. The CEO, the CTO, and the board wanted to move at the speed of business, and "redesign first" sounded like an engineer asking for time nobody wanted to give. So we moved fast, on top of an operating model that had not changed. I watched it tank projects. I watched real money burn.
The speed was never the problem. The problem was speed applied to a business that had not changed how it worked. And AI is running the exact same play right now, faster.
Lift-and-shift failed for a specific, repeatable reason, and it had a cast of three.
Which was reasonable. Speed is not a character flaw. But speed on an unchanged operating model does not compound value, it compounds debt. You move the same broken process to a more expensive place and you get there quicker.
The people closest to the work knew the redesign was the whole point, and they were the ones with the least authority to insist on it.
This is the one nobody likes to say out loud. The consulting firms moved fast to land engagements, and the playbook they ran priced the easy part: rehost the workloads, check the box, bill the hours. It had no line item for the hard part, the application rewrite, the change in how the business operated, the new behaviors the team had to learn. The people brought in to de-risk the move were optimizing for their own deal velocity, not the client's outcome. I am not above this. I lived it from the practitioner seat, which is exactly why I pay attention now.
The macro picture rhymes. BofA Global Research estimates AI is currently lifting aggregate productivity by roughly 0.1 percent per year, against a modeled ceiling of about 0.66 percent before real-world friction. Those are small numbers next to the slides being sold. BCA's Peter Berezin has called the current moment primarily an earnings bubble rather than a valuation bubble, a careful way of saying the expectations are fragile even where the prices do not look insane.
We are not here to predict a crash, and we will not. The useful read is different. The gap between that 0.1 percent measured reality and the 0.66 percent ceiling is not evidence that AI does not work. It is the size of the operating-model work that bolt-on AI skips. The model is not the missing piece. The redesign around it is.
The cloud era left the same kind of gap. McKinsey put the cloud prize for the Fortune 500 at as much as 1.2 trillion dollars in EBITDA by 2030, and most of that value sits in the transformation slice, not the cost slice. Lift-and-shift captures the small half and leaves roughly two-thirds of the value on the table. That is the arithmetic of changing your hosting bill without changing your business.
The AI version of lift-and-shift has a tell, and Google Cloud's own security team named it: "let's just add a chatbot." Bolt a copilot onto an unchanged process and expect a step change in outcomes. Their CISO blog draws the comparison to the cloud's lift-and-shift directly, and points at the same skipped foundation: data governance, security, and the actual redesign of the work.
What makes the AI version worse is that it is cheaper and faster to do the wrong thing. A cloud rehost at least took real effort. Adding a chatbot to a workflow takes an afternoon. The hype pressure from the board is higher, the cost of the bolt-on is lower, and the practitioner who asks "which process are we actually changing here" gets overruled even faster than we did a decade ago. The consulting gold rush is already in full swing: the same shape of firm, running the same shape of script, billing fast against a roadmap that still does not account for the rewrite.
The fix is not "slow down." Leadership is right to want speed, and that instinct is never going away. The fix is to change the operating model so that speed lands on something solid instead of accelerating into a wall. In practice that takes three things, and they map one for one onto the three ways it fails.
Every AI use case tied to a bottleneck and a line on the P&L, not to "AI everywhere." The use cases that cannot name the bottleneck they remove do not survive the first slide. The rewrite, the process change, and the new behaviors are scoped as the work, not as someone else's problem.
The team that has to live with the system actually learns the new model and owns it when the engagement ends. The cloud era expected people to just know it, some got real training and most got a tool dropped on their desk. Capability transfer is the difference between a system your team runs and a system that quietly rots after the consultants leave.
Someone who has lived this, builds the thing themselves, and will tell you the hard truth that the bolt-on you asked for is the expensive option. A partner whose incentive is your outcome, not their next change order.
We built SDS to be the opposite of the script. We build in our own shop, in production, every day, which is why the playbook we describe is one we run rather than one we resell. When we tell a client the operating-model change is the work, it is because we have paid the bill for skipping it.
The clearest proof is the work we turn down. We have said no to clients who wanted a bolt-on, because there are plenty of partners who will happily sell one and we are deliberately not one of them. A shop that only sells bolt-ons never turns a bolt-on away. After a discovery call we give an honest answer within a week: yes, no, or we know someone better suited.
When the fit is there, the engagement is scoped and fixed: map the candidate use cases to real P&L impact, review whether the architecture and data can actually support them without the costs spiking, model the unit economics before anything scales, and design pilots with baselines and explicit continue-or-kill thresholds so "we will learn from it" means a decision instead of a slow leak. That is the operating-model work. It is unglamorous, and it is the entire difference between AI that pays off and AI that becomes the next line item nobody can explain.
AI pays off when the operating model changes around it, not when it is bolted onto an unchanged business, and we have already lived the cost of the alternative once.
If your board is pushing AI into every workflow this quarter and something about the pace feels familiar, send us the one use case you are most expected to ship. We will tell you, honestly, whether it is a real operating-model change or a bolt-on wearing a business case, and what we would do about it.
We do not take every engagement, and we will tell you on the call whether we are the right partner.