There are four decisions. That's it.
I realise that sounds reductive. Cloud strategy has been dressed up by enterprise consultancies and hyperscaler marketing teams as something that requires a dedicated cloud architect, a multi-year roadmap, and a vocabulary that includes words like "container orchestration" and "multi-cloud failover." And if you're running infrastructure for a bank with 40,000 employees across six continents, maybe it does.
But you're not. You're running a 200-person professional services firm. Maybe a law firm, maybe a consultancy, maybe a mid-tier accounting practice. You've got an IT team of somewhere between three and twelve people. You've got a mix of platforms - some cloud-native, some that have been sitting on a server under someone's desk since 2014 (I'm only half joking). And every time you try to read something useful about cloud strategy, you end up knee-deep in AWS whitepapers written for people who think in Kubernetes.
Cloud strategy is for enterprise firms. We're too small to need a strategy - we just use what works.
I get it. And there's a version of that instinct that's perfectly healthy - you shouldn't be building something elaborate. But "we just use what works" has a way of turning into "we have no idea what we're paying for, our security posture has gaps we haven't identified, and every vendor decision gets made in isolation." That's not strategy. That's drift. And drift gets expensive.
So here's what I want to do: walk you through the four decisions that constitute a cloud strategy for a firm of your size. Not a simplified version of an enterprise strategy - a fundamentally different exercise, because your firm has different requirements, different constraints, and a different risk tolerance. You can document the whole thing on a single page. Genuinely - one page. We've helped firms do exactly this in a half-day session. If you want a template, we've put together a cloud strategy one-pager you can download and work through with your team.
Hosting model. Cloud, on-premise, or hybrid. This is the foundational choice, and for most mid-market professional services firms, the answer is cloud. Not because cloud is inherently superior in every scenario - it isn't - but because the operational overhead of managing on-premise infrastructure is wildly disproportionate to the size of most mid-market IT teams.
Think about it practically. If you've got six people in IT and two of them are spending meaningful time managing physical servers, patching operating systems, and worrying about hardware refresh cycles, that's a third of your technical capacity consumed by infrastructure babysitting. Cloud hosting - whether that's AWS, Azure, Google Cloud, or platform-specific managed hosting - transfers that operational burden to someone whose entire business is keeping infrastructure running.
But I want to be honest about the exceptions, because they're real. I was working with a financial services firm a while back - around 180 people - who had specific data residency requirements that their regulator interpreted in a way that cloud providers couldn't satisfy at the time. Their data had to live in a specific physical location, under specific access controls, and the regulator wanted to be able to audit the physical infrastructure. I'll be honest: my first instinct was to push back. The cloud options had improved, the guidance was ambiguous, and I thought we could make a case. We couldn't. The regulator was immovable, and on-premise was the right answer - not because cloud was risky, but because there was no room for interpretation. I was wrong to second-guess it as long as I did.
Hybrid is the third option, and it's more common than people admit. If you're mid-transition - some workloads already in the cloud, some legacy applications that aren't ready to move - hybrid is where you'll naturally end up. The mistake is treating hybrid as a permanent architecture when it's really a transitional state. Have a plan for where things are heading, even if the timeline is loose.
For regulated firms especially, I've written separately about the security risks hidden in legacy platforms - worth reading alongside this, because the hosting decision and the security decision are deeply intertwined.
This is where I see the most dangerous misconceptions, and where I've watched firms get into genuine trouble.
There's a surprisingly persistent belief that moving to a cloud provider means the provider handles security. It doesn't. Every major cloud provider operates on what they call a "shared responsibility model." The provider secures the infrastructure layer - physical data centres, network hardware, the hypervisor. You secure everything that runs on top of it: operating system configuration, application security, access management, data encryption, backup. All yours.
I'll tell you what this looks like when it goes wrong. A few years ago we were brought in after a firm had a security incident - nothing catastrophic, but bad enough. Someone had given admin access to about a dozen people who didn't need it, one of them had reused a compromised password, and an attacker had been quietly sitting in their cloud environment for weeks before anyone noticed. When the conversation turned to accountability, the IT manager's first response was "but we're on Azure." He wasn't being evasive - he genuinely believed the cloud provider was responsible for that layer. That belief cost him his job.
The NCSC - the UK's National Cyber Security Centre - publishes specific cloud security guidance that's genuinely useful and not written exclusively for enterprise teams. Their Cloud Security Principles cover fourteen areas including data-in-transit protection, asset protection, and personnel security. If you haven't read it, you should. It's one of the few pieces of government guidance I'd actively recommend rather than just acknowledge it exists.
For most mid-market firms, the practical takeaway: cloud is typically more secure than on-premise, because the providers invest billions in infrastructure security that you could never replicate. But that improvement only materialises if you understand where the provider's responsibility ends and yours begins. Map that boundary explicitly. Write it down. Make sure your IT team and your compliance team both know where it sits - because in my experience, they often have completely different assumptions about it.
Here's the good news: at mid-market scale, this decision matters less than the vendors would like you to believe.
AWS, Azure, and Google Cloud offer broadly comparable infrastructure capabilities for the workloads a mid-market professional services firm typically runs. The pricing models differ in the details but are similar in the aggregate. You're not going to make or break your firm's future by choosing one over another. And yet I've sat in rooms where this decision consumed three months of senior time, two rounds of RFP responses, and a vendor bake-off that everyone involved found excruciating. Don't do that.
What actually matters is simpler. If your existing platforms pull toward a specific provider - your CMS runs best on Azure, your ERP is built for AWS - follow that pull. Fighting it creates integration overhead that a mid-market IT team doesn't need. At Distinction, we work across Azure and AWS regularly, and the single biggest predictor of a smooth cloud setup is alignment between the cloud provider and the platforms already in the stack. Not glamorous advice, but true.
Data residency matters too, particularly for regulated firms. Cloud providers operate regional data centres, and if you have UK data residency obligations, confirm that your selected provider's UK region actually satisfies those obligations. The ICO has been increasingly specific about what "data stored in the UK" means in a cloud context, and "the vendor has a London region" doesn't automatically equal compliance.
And if your firm is already a Microsoft shop - Office 365, Teams, Dynamics - just pick Azure. The identity management integrates natively, the billing consolidates, and your team already has some familiarity with the ecosystem. Sometimes the best technology decision is the one that creates the least friction for the people who have to live with it. Most of you reading this should probably just pick Azure and move on.
One thing that catches people out: support costs. The default support tiers on AWS and Azure are basically a knowledge base and a ticketing system with response times measured in business days. Premium support contracts are expensive - tens of thousands per year at the enterprise tier. If you don't have a dedicated cloud engineer, you'll need either a premium support agreement or an MSP on retainer. Budget for it from the start, not as a surprise six months later.
Right. This is the section I actually want you to pay attention to, because it's where mid-market firms get bitten most often - and where I've seen the most avoidable pain.
If you've come from a world of fixed infrastructure costs - a server costs what it costs, the hosting contract renews annually at a predictable number - cloud pricing will feel alien. Cloud costs are variable. They flex with usage, storage volume, traffic, and a dozen other dimensions that nobody explains clearly at the point of sale.
The most common surprises:
Data egress fees. Most cloud providers charge you for data transferred out of their environment. If you're hosting a high-traffic website, or your platform serves large files to clients - research reports, document packs, media assets - those egress costs add up fast. I worked with a firm that budgeted £800 a month for cloud hosting. First invoice came in at £2,400. The platform itself cost exactly what they expected. The data transfer fees were the bit nobody mentioned during the sales process. The IT director forwarded me the invoice with a single question mark. We spent the next hour going through the billing breakdown line by line, and the look on his face when he realised this was going to recur every month - that's the look I want you to avoid.
Storage creep. Cloud storage is cheap per gigabyte. That's the pitch. And it's true. But content volumes grow, backup copies multiply, and old environments that were supposed to be temporary become permanent. Without active management, storage costs drift upward quarter on quarter. It's never dramatic enough to trigger an alarm, but over two or three years it compounds into something meaningful.
Over-provisioning. Cloud environments are easy to set up with generous capacity - sensible when you're not sure what the load will look like. But right-sizing after the fact requires someone to actively review usage data and make changes. If nobody's doing that, you're paying for headroom you don't need. A quarterly cost review - even just an hour with someone who can read a usage dashboard - prevents this from compounding.
I've written a separate piece on when moving to the cloud actually saves money, which goes deeper on the financial case. If you're building a business case internally, that's the companion to this section.
Cloud strategy for a firm your size is not a multi-year transformation programme. It's four decisions:
Answer those four questions clearly, write them down, and you have a cloud strategy. It won't win any awards for length. But it'll be more useful than 90% of the cloud strategy documents I've seen gathering dust on SharePoint - most of which were written by consulting firms charging by the page.
We've put together a cloud strategy one-pager template that walks through each of the four decisions with prompts for your specific context. It's designed so a CTO or IT director can complete it in a half-day session and use it as the reference document going forward. Download it and see if it's useful.
And if you'd rather work through the four decisions with someone who's done this before - particularly if you're in a regulated sector where the security and compliance dimensions need more careful handling - book an infrastructure review. Half a day, four decisions, a documented cloud posture. No twelve-month programme required.