“Moving to the cloud” is not one decision. It’s a series of them, each with a different cost, a different amount of disruption and a different answer depending on what you’re running.

We work it through with you properly: what moves, what stays, what it costs to run rather than just to build, what changes for your staff, and what happens when something goes wrong at three in the morning.

Based in Sheffield, working across the UK and Europe. ☎

What we actually do in the cloud

Databases. SQL Server, Azure SQL, Managed Instance, MySQL — the part we’ve done longest and the part most businesses move first → [LINK: Azure SQL and SQL in the cloud → /sqlserver/azure/]

Applications. Web applications, APIs, portals and background processing, running on App Service or Container Apps. Scaling when you need it, costing nothing when you don’t.

Containers and orchestration. Container Apps for most things, Container Instances for scheduled and one-off work, and AKS where the estate genuinely warrants it. Most don’t, and we’ll say so rather than sell you one.

Integration. Systems talking to each other — APIs, queues, scheduled exchange, webhooks, and the file drops plenty of business software still relies on → [LINK: integration and APIs → /database/integration/]

Hosting and infrastructure. Networking, private endpoints, storage, certificates, DNS, backup and disaster recovery. The unglamorous half that decides whether any of it stays up.

Identity and access. Microsoft Entra ID, hybrid directory sync, MFA and conditional access, managed identities, privileged access, joiners and leavers.

Microsoft 365 alongside it, where your business systems need to talk to Exchange, SharePoint or Teams rather than sit beside them.

Built as code, not clicked together

[IMG-1] — A Terraform plan or a module structure on screen. Real, redacted. This is the page’s main technical claim and it should look like work, not like a stock photo.
Alt: Azure infrastructure defined in Terraform

Most small and mid-sized Azure estates were built by someone clicking through the portal. It works, right up until the person who did it leaves, or you need a test environment that matches production, or something changes and nobody can say what it used to be.

We define infrastructure in Terraform — the databases, networking, private endpoints, key vault, app services, permissions and the rules around them.

What that buys you:

Dev, test and production are the same, because they come from one definition rather than three afternoons of clicking
Every change is reviewable, version-controlled, and attributable. You can see what changed, when and why.
Drift shows up as a difference rather than as a surprise during an incident
The environment can be rebuilt. That’s a disaster recovery position most businesses this size don’t have, and it costs nothing extra once the code exists.
You own the definition. Take the work in-house or to someone else and the environment goes with you. No lock-in to us, which we think is the right way round.

Where a client’s team is Microsoft-native and would rather stay that way, Bicep or ARM does the same job and we’ll work in those instead.

Identity is the security boundary

Firewall rules matter. What actually decides who reaches your data is Entra ID, and it’s where most estates are weakest.

Hybrid directory sync that’s monitored rather than assumed. Access by group rather than by person, including on databases. Managed identities for applications, so there’s no password in a connection string to leak. MFA and conditional access on anything administrative. Just-in-time admin rights instead of standing ones. Leavers who actually lose access, including the token they’re already holding.

And the orphans — the service account nobody owns, the shared credential in a spreadsheet, the login belonging to someone who left in 2019.

Full detail, including how this works on the database itself → Azure SQL and Entra ID

This is also the part your auditors ask about. Cyber Essentials, ISO 27001, DSPT and client security questionnaires all land on access control and MFA before anything else. We build to answer them, and we can help with the submissions.

What it costs to run

The build is a one-off. The monthly bill isn’t, and it’s where cloud projects go wrong.

You may already own a lot of it. Azure Hybrid Benefit applies existing SQL Server and Windows Server licences with Software Assurance against Azure cost. Skipped surprisingly often.
Reserved capacity cuts the bill substantially against a one or three year commitment.
Sized from measurement, not guesswork. Most first Azure quotes are oversized because it’s easier than measuring.
The line items nobody budgets for — egress, storage tiers, backup retention, log ingestion.
Things that switch off. Dev and test environments don’t need to run at 2am.
Reviewed afterwards, because estates accumulate. We’ll tell you when you’re paying for something nobody uses.

You get a monthly figure before you commit, not after.

You don’t have to move everything

Hybrid is a legitimate end state, not a half-finished project.

Plenty of our clients have a server in the office that works perfectly well, and one workload that genuinely benefits from being in Azure — remote access, resilience, or a public-facing application. Moving that one thing and leaving the rest alone is often the right answer for years.

We work in stages: the thing that hurts most, done properly, running and earning before the next one starts. Nothing is a single cutover where the business bets itself on a weekend going well.

SQL Server migration and upgrades – modernise existing systems

Azure first, but not Azure only

Most of our clients are Microsoft businesses — SQL Server, Microsoft 365, Windows, Entra ID. For them Azure is usually the right answer, because the licensing, the identity and the support all line up.

But we’re not tied to it, and sometimes it’s the wrong tool.

AWS where a client already has an estate there, or where a specific service is the better fit. No sense moving a working platform for the sake of consistency.

DigitalOcean and similar for smaller workloads where Azure is genuinely overkill. A modest web application with predictable load doesn’t need enterprise cloud pricing, and we’d rather tell you that than bill it.

Your own servers, where the numbers say so. Hardware you already own, with life left in it and no remote access requirement, is often the cheapest place for a database to sit.

Because the infrastructure is defined in Terraform, this isn’t a hard boundary — the same approach, review process and discipline apply wherever it runs. What changes is the provider, not how carefully it’s built.

What we won’t do is move you somewhere because it’s what we happen to like.

When cloud isn’t the answer

A well-specified server with years left in it, a stable system nobody’s asking to change, no remote access requirement and no compliance pressure — staying put is often cheaper and simpler.

Cloud is better for specific reasons: getting at things from outside the office, resilience you couldn’t otherwise justify, scaling you can’t predict, and getting out of the business of replacing hardware. Those reasons either apply to you or they don’t.

Not sure where you stand? Start with an assessment rather than a project → SQL Server health check

Links block

Case studies

all case studies