Table of Contents
TL;DR
I have led digital transformations that predate the phrase “digital transformation.” The work existed long before the buzzword; we just called it survival. At a major national retailer I lived two of them: moving accounting, HR, and payroll from paper onto computers, and later migrating the entire environment from one architecture to another with the database changing underneath. Everything the consultants now diagram, we learned by doing it.
Nobody in the room called it a digital transformation, because the term did not exist, or at least none of us had ever heard it. What we had was a major national retailer running its accounting, human resources, and payroll on paper, Excel spreadsheets, and Word documents, and a mandate to move all of it onto real systems. Years later, the industry invented a name and a consulting category for what we did. At the time it was just the work.
I went through several of these before the label arrived, and the two that shaped my understanding were fundamentally different animals. The first was paper to computers: taking processes that lived in filing cabinets and human memory and giving them to machines for the first time. The second, years later, was platform to platform: migrating everything we had built from one architecture to another, with the database changing underneath. Same company, same people in many cases, completely different problems.
Transformation type one: paper to digital
The first transformation installed a new central system and moved the paper departments onto it. If you think the hard part was the technology, you have never asked an accounting department to give up its paper. The machines did what machines do. The people fought, quietly and persistently, for the world they knew, and the story of that resistance and what dissolved it is its own article, because it is the part every modern transformation still gets wrong.
What paper-to-digital taught me is that this type of transformation is really a translation project. Every process on paper encoded decisions nobody remembered making: why this form needs three signatures, why that report goes to those five people. Digitizing forced every one of those fossilized decisions into the open, where it had to be justified or discarded. The computer was almost incidental. The transformation was the interrogation.
Transformation type two: platform to platform
The second transformation moved the entire environment, applications, data, everything, from one architecture to another, changing databases in the process. This was not translation; everything was already digital. It was a paradigm change: how everything worked, how it was operated, how it failed, all replaced over one big-bang weekend that came close to rolling back.
Platform migrations look safer than paper conversions because the processes already exist in digital form. They are not safer. They concentrate all their risk into the cutover and the weeks after it, where paper conversions spread their risk across months of human adoption. Different animal, different teeth.
We did digital transformation before the term existed. We called it survival.Share on X
The vocabulary keeps changing. The work does not.
Watching the terminology arrive after the work gave me a durable immunity to technology vocabulary in general. What we did was later called computerization, then digitization, then digital transformation; adjacent waves got called ERP, e-business, cloud migration, and now AI transformation. Each label arrived with its own consultancies, maturity models, and conference circuits, and underneath every one of them, the actual work has been the same three problems in a trench coat: processes nobody fully understands, systems nobody fully inventoried, and people nobody has convinced. I have a whole article on that triad, because it is the invariant.
The practical use of this observation is timing. Companies repeatedly delay necessary work while waiting for the current label’s tooling to mature, then rush it when the label peaks, then abandon “legacy” efforts when the next label arrives. The work does not care what it is called, and the organizations that treat it as continuous, survey, modernize, retrain, repeat, quietly lap the ones that transform in named, branded spasms.
What the buzzword hides
“Digital transformation” now sells frameworks, maturity models, and keynote slots, and some of that material is genuinely useful. What the packaging hides is that transformation is not a technology event with a people component. It is a people event with a technology component, and it was that in both directions: the paper clerks afraid for their jobs, and the operations staff whose entire expertise was tied to the old platform. Both transformations succeeded for the same unglamorous reason, covered across this cluster: we treated the humans as the project, not the obstacle to it.
Executives who lived their own version of this era hold stories with real scarcity value, because the practitioners who did transformation before it had a name are the ones who can say which parts of the modern framework are load-bearing and which are packaging. That testimony is what makes a transformation book worth reading, and worth writing.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.