Nobody in the room called it a digital transformation, because the term didn’t exist, or at least none of us had ever heard it. We’d a major national retailer running its accounting, human resources, and payroll on paper, Excel spreadsheets, and Word documents. We also had 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’d built from one architecture to another, with the database changing underneath. Same company, same people in many cases, completely different problems.
What is a paper-to-digital transformation?
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’ve 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’s 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.
What is a platform-to-platform transformation?
The second transformation moved the entire environment, applications, data, everything, from one architecture to another, changing databases in the process. This wasn’t translation; everything was already digital. It was a paradigm change: how everything worked, how it was worked, 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’re 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’s 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 doesn’t care what it’s called, and the organizations that treat it as continuous, survey, modernize, retrain, repeat, quietly lap the ones that transform in named, branded spasms.
What does the digital transformation buzzword hide?
“Digital transformation” now sells structures, maturity models, and keynote slots, and some of that material is useful. What the packaging hides is that transformation isn’t a technology event with a people component. It’s 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 structure 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 Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
