Azure

“Should we move to the cloud?” is three different questions with three different answers and three very different monthly bills.

We’ll tell you which applies to you, what it costs to run rather than just to build, and what changes for the people using it. Sometimes the answer is that you’re better off where you are, and we’ll say that too.

☎

The three ways SQL Server runs in Azure

Most businesses moving an existing system land on Managed Instance or a VM. Azure SQL Database is usually right for something being built rather than moved.

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 most 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.
• Sizing honestly. Most first Azure quotes are oversized because it’s easier than measuring. We measure.
• Egress, storage tiers and backup retention are the line items nobody budgets for.
• Identity licensing. Conditional access needs Entra ID P1; privileged access management and access reviews need P2. Worth knowing before it’s assumed.
• Dev and test can pause when nobody’s using them.

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

Still on an unsupported version?

SQL Server 2016 went out of support on 14 July 2026. 2014 and 2012 are long gone.

Moving those workloads to Azure comes with free Extended Security Updates — which for some businesses makes Azure cheaper than staying put, once the on-premises ESU cost is counted.

Worth pricing properly before deciding either way → SQL Server migration and upgrades

Getting there

[IMG-2] — Left-aligned. A real cutover runsheet or dependency map. Redacted.
Alt: Azure migration assessment and cutover plan

Full asset mapping first. What’s on the server, what depends on it, what talks to it — upstream and downstream. Jobs, linked servers, SSIS packages, reports, and the three applications you’d forgotten were pointed at it. This is the step that gets skipped, and it’s the one that prevents data loss and unplanned downtime.

Rehearsed on a copy, and timed, so the outage window we quote is one we’ve measured.

[IMG-2] — Left-aligned. A real cutover runsheet or dependency map. Redacted.
Alt: Azure migration assessment and cutover plan

Cutover agreed in advance, with a written rollback plan and the old system kept intact until you’re satisfied.

Counts and totals reconciled afterwards, signed off by someone on your side.

Built as code, not clicked together. We define environments in Terraform — database, networking, private endpoints, key vault, app services and the rules around them. Dev, test and production come from one definition rather than somebody’s memory of what they clicked; a rebuild is repeatable; and drift shows up as a difference rather than a surprise. You own the definition, so if the work moves in-house or elsewhere, the environment goes with it. Where a client’s team is Microsoft-native, Bicep or ARM does the same job.

Hybrid is fine. Keeping some things on-premises and moving others is a normal end state, not a half-finished project.

What we run in Azure

Azure is more than somewhere to put a database. Where a system needs an application around it — a portal, an API, a web front end, background processing — we build and run that too, against the same data.

• App Service for web applications and APIs, authenticating to the database with a managed identity rather than a connection string full of credentials
• Container Apps where something needs to scale to zero between bursts, or scale out under load without running a cluster
• Container Instances for scheduled and one-off work — overnight imports, report generation, data exchange with other people’s systems
• Azure Kubernetes Service where the estate genuinely warrants it. Most don’t, and we’ll say so rather than sell one.
• Azure Cache for Redis in front of the database for read patterns that don’t need to hit SQL every time
• Queues and background job processing, so imports, exports, document generation and notifications happen off the request path instead of timing out somebody’s screen
• Private endpoints and network isolation, so the database isn’t reachable from the public internet at all

The aim is boring: the system stays up, the overnight run finishes, and nobody gets a timeout at 4pm on the last day of the month.

Identity and access: Microsoft Entra ID

In Azure, identity is the security boundary. Firewall rules matter, but what actually decides who reaches your data is Entra ID — and it’s where most estates are weakest.

Hybrid identity, done properly

Most businesses still have an on-premises Active Directory and aren’t getting rid of it. We set up and look after the join between the two: Entra Connect or Cloud Sync, what’s in scope and what’s deliberately filtered out, password hash sync versus pass-through authentication, and sync health monitoring so a replication failure gets noticed rather than discovered three weeks later when somebody can’t sign in.

Sync problems are quiet. An object that stops replicating, a duplicate proxy address, a filtered OU nobody remembers filtering — none of it announces itself, and all of it eventually becomes an access problem.

Joiners, movers and leavers

The bit that fails audits.

• Access by group, not by person — including database access. A SQL login created by hand for one person is invisible to every HR process you have.
• Movers — someone changing role keeps their old access unless something removes it. Ten years of that is how people end up with access to everything.
• Leavers — account disabled, sessions and tokens revoked, licences reclaimed, group memberships removed, mailbox and files dealt with. Continuous access evaluation matters here: without it, a disabled account can keep working for up to an hour on a token already issued.
• Deletion — soft-deleted accounts are recoverable for 30 days, which is a safety net rather than a completed offboarding. What gets permanently removed, and when, should be a decision rather than a default.
• Orphaned access — the real problem. The service account nobody owns, the shared credential in a spreadsheet, the SQL login tied to a person who left in 2019. We find these and tie them to something manageable.
• Access reviews — periodic recertification, so “who has access to this” is a report rather than an afternoon.

Lockouts, passwords and the day-to-day

Smart lockout and Entra ID Password Protection, including extending the banned-password list to on-premises AD so the same rules apply on both sides. Self-service password reset, because most lockouts don’t need a person. Sensible thresholds — lockout policy that’s too aggressive generates more risk than it removes, because people start writing passwords down.

Privileged access

MFA and conditional access on administrative accounts. Just-in-time admin rights through Privileged Identity Management, so standing admin access stops being permanent. Break-glass accounts that exist, are excluded from conditional access deliberately, and are monitored.

On the database itself

Entra ID authentication instead of SQL logins with shared passwords nobody has rotated since the install. Managed identities for applications — no password in a connection string, no secret in a config file, nothing to leak. Key Vault for the secrets that genuinely have to exist. Auditing and diagnostic logs retained somewhere they can be queried after an incident, rather than somewhere they’ve already rolled over.

Running it afterwards

Hands-on management of a full or hybrid Azure deployment, once it’s live:

• Monitoring, alerting and cost review — including telling you when you’re paying for something you don’t use
• Backups, retention, and restores actually tested
• Failover and disaster recovery configured deliberately. Azure makes proper DR achievable for businesses that could never justify a second site — but it isn’t automatic. It’s configured, and it needs testing.
• Patching, maintenance and version currency
• Performance tuning, which matters more in Azure because sizing is a monthly cost → SQL Server performance tuning

SQL Server support and consultancy

Public sector, NHS and regulated clients

We’ve worked with business, local government and central government since 1999, including NHS organisations.

Where a system holds personal or patient data the questions are the same every time: who can reach it, how is that proven, where does it live, what’s logged, and what happens if it goes wrong. We build to answer those.

We can also support the paperwork: Data Security and Protection Toolkit (DSPT) submissions, Digital Technology Assessment Criteria (DTAC) responses, Cyber Essentials, and the security questionnaires that turn up in tenders and renewals.

When Azure isn’t the answer

We’d rather tell you now than halfway through.

A well-specified server with life 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, and 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

Case Studies

⚠️ Nothing in your sheet covers an Azure project, though the health check doc lists Azure database deployments in CDE’s experience. One short anonymised account — what moved, which option, what the monthly cost came out at — would carry this page alone and serve /azure-cloud/ too.

Interim: ACC works as a SQL modernisation card.

Get a real number before you commit

Tell us what's on the server, how many users, and what your outage tolerance is. We'll tell you which Azure option fits, what it costs a month, and whether it's worth doing at all.

Send us the details → SQL Server Migration →