Digital Transformation ·
Digital transformation for SMEs: why it starts with the cloud foundation
When mid-sized companies talk about digitalisation, the conversation is usually about software: a new ERP module, a document management system, an AI pilot. After enough of these projects the sober pattern is always the same: whether an initiative holds up is rarely decided by the chosen tool - it is decided by whether there is a foundation underneath that every subsequent project can build on. That is why digital transformation for SMEs sensibly starts with the cloud infrastructure, not with the tool catalogue.
Why digitalisation projects rarely fail because of the tool
The most common failure mode is tool-first thinking: a vendor promises to solve one specific problem, the project starts, and six months later another island exists - with its own login, its own data store and its own export to Excel. After three such projects a company does not have digitalisation; it has a collection of subscriptions.
The cause is not carelessness but a missing baseline decision: where do our systems run, who may access what, how does data get from A to B, and who sees the costs? As long as these questions are answered anew per project, every answer will differ. A foundation answers them once - and every subsequent project inherits the answers.
The foundation: a landing zone at SME scale
A landing zone is the pre-built cloud foundation every new application lands in: account structure, identity, network, guardrails and logging, decided once and enforced everywhere. For a large enterprise that is a programme - for a mid-sized company it is a manageable project, because proportionality cuts the size, not the principles: fewer accounts, fewer exceptions, same discipline.
The core set for the Mittelstand, without enterprise ballast:
- Central identity: one login (SSO with MFA) for all systems instead of a password list per tool - the point where data protection and employee offboarding become manageable too.
- Separate production and test environments, so an experiment never touches customer data.
- Guardrails instead of policy PDFs: regions, public storage and admin rights limited technically, not just in writing.
- Central logging and backups with tested restores - the basis for every later certification or customer request.
- Cost allocation from day one: every application has an owner and a budget with an alert.
Lift-and-shift without governance: the expensive detour
The second failure mode is migration without a foundation: existing servers are copied 1:1 into the cloud because the data centre contract runs out or the hosting provider terminates it. Technically that works - economically and organisationally it is often where the real problem starts. The same legacy now runs on more expensive infrastructure, nobody has reordered access or costs, and the promised agility never arrives.
Lift-and-shift is legitimate as a deliberate first stage - under deadline pressure, for instance. But only if the landing zone stands first and the migration runs through it. Then even an unchanged legacy server inherits central identity, logging and cost allocation, and modernisation can follow workload by workload instead of as a big bang.
Process automation: the right second stage
Once the foundation stands, process automation turns from a buzzword into a selection question. The candidates with the best effort-to-impact ratio are rarely spectacular: invoice intake and approvals, order capture from emails and PDFs, master-data maintenance between systems, reporting paths that today consist of copy-and-paste.
The selection criteria are the same as for any automation: high volume, clear rules, measurable manual effort. Processes that occur three times a week and differ every time get automated last - or never.
Buy or build: software for mid-sized companies
For most standard processes, bought software is the right answer for mid-sized companies - accounting, payroll, CRM and ERP are solved problems. Building your own pays off where a process genuinely differentiates: the pricing logic that only exists at your company, the integration between two systems for which no standard connector exists.
The foundation makes that decision cheaper too: on a landing zone, a custom build is a small, well-bounded project with inherited security instead of another island. And bought SaaS tools connect through the central identity instead of producing new password lists.
A realistic roadmap for the first six months
The sequence matters more than the speed. An order that holds up in practice:
- Month 1: inventory and prioritisation - which systems and processes exist, what manual work really costs today, which two or three processes have the best effort-to-impact ratio.
- Months 2-3: build the cloud foundation - account structure, SSO with MFA, guardrails, logging, cost allocation. In Terraform, so it stays reproducible.
- Months 3-4: first workload onto the foundation - deliberately a manageable but real process, not a throwaway pilot.
- Months 4-6: first process automation in production, with a baseline measured before and re-measured after.
- From month 6: repeat on a cadence - every further application and automation inherits the foundation instead of reinventing it.
FAQ
Where should we start?
With an honest inventory, not with a tool: which systems run where, which processes cost the most manual time today, who may access what. Then the foundation, then the first process. Reversing that order builds the third standalone silo.
What does digitalisation cost a mid-sized company?
There is no honest flat rate. What is reliable is the structure: the foundation is a one-off, manageable project; running cloud costs scale with usage; the largest block is almost always internal time for clarifying processes. Sequencing is what makes it cheaper - every project on the foundation costs less than the one before.
How long until results are visible?
A cloud foundation at SME scale stands in weeks, not years. The first automated process should be in production and re-measured within the first half year. Initiatives that plan twelve months of concept phase before the first visible result usually fail on exactly that.
What happens to our ERP and legacy systems?
Usually: nothing, for now. A working ERP gets connected, not replaced - through clean interfaces and central identity. Replacing a legacy system is its own project with its own business case, and it becomes markedly cheaper on a foundation because the data and access questions are already answered.