Digital transformation is one of those phrases that makes people picture something grand. (More on Victoria Chemko on AI integration that sticks) A bold leap into the future. New everything, all at once. The reality is far more boring, and the boring version is the one that works.
I led transformations at a national retailer for two decades, and now I ghostwrite books for technology leaders. What I learned is that transformation is plumbing, infrastructure work done one piece at a time, and anyone who sells it as something grander is selling a fantasy. The grand version makes a great slide. It also takes the business down when it breaks.
Digital transformation is plumbing. Companies that treat it as a bold leap fail. Companies that move one pipe at a time succeed.Share on X
Why not change everything at once in a transformation?
The temptation in transformation is to change everything at once.
New systems, new processes, new tools, all launched together on a big day. It’s the version that looks good in a board presentation, a single dramatic leap from the old world to the new. That approach fails more often than it succeeds, because when something breaks, and something always breaks, you can’t tell which of the hundred changes caused it.
Executives pitch the big-bang cutover as the bold choice, and I think it’s the reckless one.
I did it the other way. One component at a time. Move one application, prove it works, then move the next. Safety is the obvious advantage. The bigger advantage is diagnosis. When you change one thing and something breaks, you know exactly what broke it, because only one thing changed. You fix it, confirm it works, and move to the next. The big-bang approach throws out that certainty.
You flip everything on at once, something fails, and now you’re debugging a hundred simultaneous changes under pressure while the business is down. One component at a time is slower to start and dramatically faster to recover, because every step is small enough to understand and reverse.
Executives pitch the big-bang cutover as the bold choice, and I think it’s the reckless one. When it fails, the people who pay are the ones answering phones and serving customers while the systems are down, and the executive who pitched it is usually the last person to feel it.
This is also how you keep the business running through the transformation, which is the top priority, especially in a company where the technology isn’t the product, a distinction I get into in digital transformation when you’re not a tech company. You can’t take the whole operation down for a weekend to swap everything. You move one piece while the rest keeps running, and the business barely notices.
| Big-bang cutover | One component at a time | |
|---|---|---|
| How it launches | Everything switched on together on one big day | Move one machine, application or process, prove it, then the next |
| When something breaks | A hundred changes to debug under pressure | You know what broke it, because only one thing changed |
| Speed | Looks good in a board presentation, hard to recover | Slower to start, dramatically faster to recover |
| Business impact | The operation can be down while you debug | The rest keeps running and the business barely notices |
| Testing | Problems surface all at once on launch day | Each piece is tested in production before the next moves |
| Who pays when it fails | People answering phones and serving customers | Small, reversible bets limit the damage |
My take
Skip the big-bang cutover. It looks good on a slide, and when it breaks you’ve got a hundred changes and no idea which one did it. Move one machine, one application, one process, prove it works, then move the next. You’ll start slower and recover faster. The business keeps running, and the people answering phones never pay for an executive’s dramatic launch day.
What does component-by-component migration look like?
Take a concrete example. I built a private cloud on-site, our own virtualized environment, and moved applications onto it one machine at a time. We took around fifty physical machines and virtualized them onto a single powerful host running modern hardware.
Think about what that means practically. Fifty physical servers, each one a box that could fail, that drew power, that generated heat, that took up rack space and needed individual maintenance. We collapsed all fifty into software running on one strong machine. Virtualization means each old server becomes a file, a virtual machine running on shared hardware that’s far more powerful than any of the fifty boxes it replaced. Fifty boxes became one.
The new host was strong enough to run all of them at once, and the modern technology underneath sped everything up dramatically. We didn’t announce a transformation. We just moved machines onto the cloud, one at a time, until the old room full of servers was gone and everything ran faster than before.
I built a second cloud for our disaster recovery site, so if the main location went down we could come up elsewhere. That’s its own kind of insurance, the same logic as layered backups: the thing that saves you is the copy in the other building when the first building is gone. And over time we moved many of our vendors to SaaS, software as a service, letting them run and maintain the software while we focused on our own operations instead of babysitting servers.
That private cloud is the build I’m proudest of from those years. We virtualized everything we could, even servers running older operating system versions, and over time the VMware cluster held about 300 servers. It made the whole operation more secure and more stable. I farmed out the VMware management to an outside consulting firm, and it ran beautifully.
We turned fifty servers into one powerful host and everything got faster. Nobody called it a transformation. That’s exactly what it was.Share on X
Why does the plumbing approach win?
Because unglamorous work on data, integration and process keeps everything else running. The flashy projects built on bad plumbing fall over, and they do it in front of the board.
From the podcast
Ben “The Automator” Christensen argues most of the win is in software you already own, on Leaders and Their Stories:
I want you to use your existing software and make it suck less.Plumbing, not architecture, and considerably cheaper than the replacement everyone assumes is required.
The plumbing approach wins because it respects how systems fail. A big-bang transformation is a single enormous bet.
The component-by-component approach is a series of small, reversible bets, each one verified before the next begins. And as I describe in why digital transformations actually fail, the failures almost always come from inadequate testing under real conditions. Moving one component at a time means each piece gets tested in production, for real, before you move the next, instead of discovering all your problems at once on launch day.
It’s less exciting. There’s no grand launch and no ribbon cutting, just a steady migration that one day is simply done, with the business running better and almost nobody having noticed the disruption. I’d take that over a celebrated launch every time. Leaders who need the drama to feel accomplished are gambling the company’s operations on their own ego, and the people underneath them pay when the bet goes bad.
When I work with an executive on their transformation book, this is often the hardest thing to convince them to admit on the page.
The board wants the heroic story. The heroism was in the discipline of doing it slowly and safely. That honesty makes a transformation book useful to the next leader who reads it.
Frequently Asked Questions
Mostly infrastructure work, done one component at a time. The buzzword suggests a bold leap, but the real transformation is plumbing: moving one application, one machine, one process, proving each works before the next. The unglamorous, steady migration is what changes how a company runs.
For safety and for diagnosis. When you change one thing and something breaks, you know exactly what caused it, because only one thing changed. A big-bang launch fails and leaves you debugging a hundred simultaneous changes under pressure while the business is down. One at a time is slower to start and far faster to recover.
An organization’s own virtualized environment, run on its own hardware instead of a public provider. I built one and collapsed around fifty physical servers into virtual machines running on a single powerful host. Each old server becomes software on shared hardware. That shrinks a whole server room to one strong box and speeds everything up.
By moving one piece at a time while everything else keeps running. You can’t take the whole operation down to swap everything at once, especially in a company whose product isn’t technology. Moving component by component means the business barely notices, because only a small part is ever changing at any moment.
Yes. Shifting vendors to software as a service lets them run and maintain the software while you focus on your own operations instead of babysitting servers. It’s one more component you move, part of the same steady, piece-by-piece approach instead of a dramatic overhaul.
Yes. I led enterprise transformations for two decades and ghostwrote three digital transformation books for executives. The real version, where the heroism is in the discipline of doing it slowly and safely, makes a transformation book useful. You can see how I work on the technology ghostwriting page.
- The NIST Definition of Cloud Computing, National Institute of Standards and Technology
