Digital transformation is one of those phrases that has been used so many times, by so many firms, across so many industries, that it has lost most of its signal. A global consultancy uses it to describe a five-year enterprise platform overhaul. A freelancer uses it to describe a WordPress site rebuild. A software vendor uses it to describe switching to their product. The phrase covers all of these, which means it covers nothing.
This is a short note on what the work actually involves when you strip away the marketing layer and look at what mid-size companies are actually buying and actually doing when they undergo a transformation. Not the strategy deck version. The operational version.
The starting point is never the technology
Every transformation that works starts with a problem, not a technology. The company is slow to publish content. Customer data lives in three separate systems that don't talk to each other. The website is a brochure that takes eight seconds to load. Reports take a week because someone has to compile them by hand. These are real operational problems. They are not technology problems. They are business problems with a technology component.
Transformations that start with the technology ("we need to move to the cloud," "we need an AI strategy," "we need to rebuild the website") tend to generate activity without generating change. The infrastructure gets updated; the operational problem stays. What changes is the tool; what does not change is the workflow.
The correct starting point is a written diagnostic. Map the actual friction. Quantify it where you can (hours per week, error rate, delay from trigger to output). Then ask which of those friction points is worth solving with technology and which is worth solving with a different process, a different person, or no intervention at all.
The tool is not the transformation. The workflow that changes after the tool is installed is the transformation.
The four questions worth asking
A useful way to scope a digital transformation is to work through four questions, in order. Each one narrows the scope considerably and prevents the project from becoming a multi-year initiative that solves everything poorly.
First: what does the web presence actually do? Most company websites fall into one of two categories. The first is a brochure: it exists, it describes the company, it does not change often and does not do much. The second is a system: it generates leads, processes transactions, publishes content on a schedule, connects to a CRM, generates structured data for someone downstream. The two require completely different approaches. A brochure that has been built as a system is expensive and fragile. A system that has been built as a brochure is a ceiling on the business.
Second: where does human time go that should not? This is the automation question, and it is almost always worth asking early. Most mid-size companies have two or three manual workflows that cost them four to ten hours per week and could be fully automated in a few days of work. Data entry between systems. Report generation. File conversion and distribution. Email sequences triggered by form submissions. These are not glamorous, but they are real, and the ROI on automating them is often higher than anything else in the transformation budget.
Third: can you measure what matters? Data is the output of a well-instrumented system. If the company cannot answer basic operational questions without opening a spreadsheet, running a manual query, or asking a person to compile a report, the transformation has a measurement gap. Fixing this does not require a data warehouse or a business intelligence platform. It often requires adding structured logging to existing systems, connecting data sources that already exist, and putting a dashboard in front of the people who need it.
Fourth: who operates it after it is built? This is the question that most transformation plans skip, and it is the one that determines whether the transformation sticks. A new website, a new automation, a new reporting dashboard: all of these require ongoing maintenance, updates, and incident response. If the plan ends at launch, the transformation will decay. The operating model is part of the scope, not an afterthought.
What a scoped transformation actually looks like
For a mid-size company, a transformation that addresses all four questions above typically involves three to four distinct workstreams: a web presence rebuild, one to three automation projects, a data pipeline from existing systems to a reporting surface, and an operating model for ongoing maintenance. The workstreams are independent enough to be sequenced rather than run simultaneously.
The diagnostic almost always narrows the initial brief. So does the ROI analysis. What remains is a set of changes that are (a) specific, (b) measurable, and (c) operational rather than aspirational. That is the transformation.
The phrase does not need to be retired. It just needs to be taken literally: something is being transformed. The job is to be precise about what, and honest about why.