TL;DR
Digital transformation is plumbing. The buzzword makes people picture something exciting, but the real work is infrastructure, done one component at a time. I led enterprise transformations at a national retailer, and the method that worked was never a big bang. Move one machine, one application, one process. I built an on-site private cloud and put fifty machines on one powerful host, which sped everything up. The boring infrastructure is the transformation.
Digital transformation is one of those phrases that makes people picture something grand. 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 actually works.
I led transformations at a national retailer for two decades, and now I ghostwrite books for technology leaders. The hard truth I learned is that transformation is plumbing. It is infrastructure work, done quietly, one piece at a time.
Digital transformation is plumbing. The companies that treat it like a bold leap fail. The ones that move one pipe at a time succeed.Share on X
One component at a time
The temptation in transformation is to change everything at once. New systems, new processes, new tools, all launched together on a big day. It is 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 cannot tell which of the hundred changes caused it.
I did it the other way. One component at a time. Move one application, prove it works, then move the next. The advantage is not just safety, though it is much safer. It 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 are 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.
This is also how you keep the business running through the transformation, which matters more than anything, especially in a company where the technology is not the product, a distinction I get into in digital transformation when you’re not a tech company. You cannot 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.
The private cloud
Here is 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, essentially, a virtual machine running on shared hardware that is 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 did not 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 is 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. None of it was dramatic. All of it was transformation.
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 the boring version wins
The plumbing approach wins because it respects how systems actually 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 is less exciting. There is no grand launch, 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, because there barely was any. That invisibility is the mark of success, not a lack of accomplishment. The best transformation is the one the rest of the company barely felt.
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 truth is that the heroism was in the discipline of doing it slowly and safely. That honesty is what makes a transformation book actually 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 actually 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 rather than 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, which 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 cannot take the whole operation down to swap everything at once, especially in a company whose product is not 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 is one more component you move, part of the same steady, piece-by-piece approach rather than a dramatic overhaul.
Yes. I led enterprise transformations for two decades and ghostwrote three digital transformation books for executives. The honest version, where the heroism is in the discipline of doing it slowly and safely, is what makes a transformation book useful. You can see how I work on the technology ghostwriting page.