Azure & Microsoft Migration
Azure migration, assessed before it is promised.
Most migration projects do not fail during the migration. They fail four months earlier, when someone estimated the work by looking at a server list.
not in scope · regulatory audits, compliance attestations, signed opinions
We start with an assessment: a fixed-scope, fixed-price review of what you actually run, what it depends on, what it will cost in Azure, and what will hurt. You typically get a costed plan and a risk register. Then you decide whether to migrate at all — with us, with your own team, or with somebody else.
What this silo does not cover, stated plainly rather than left to the rail alone: we do not issue regulatory audits, compliance attestations or signed opinions. We build and document environments that stand up to those reviews; an audit firm or a PCI QSA issues the opinion.
What the wave diagram above shows, in full: the estate is split into waves and the waves run in order — wave 1 the low-risk increment, wave 2 the next, wave 3 the remaining estate — and every one of them runs the same four numbered steps:
- Build. The target environment for that wave is stood up and configured, with nothing in production yet depending on it.
- Rehearse. The move is performed end to end against the built environment, on the real data, to find out what actually breaks.
- Cutover. Only a wave whose rehearsal passed is allowed to cut over, inside the downtime window you approved in advance.
- Validate. Both environments run in parallel while the wave is checked against the plan, so a rollback is still a decision rather than an emergency.
If the rehearsal fails, the wave returns to build — not to cutover. That is the gate the diagram draws, and it is the reason the waves are ordered smallest blast radius first.
What you are actually buying
Risk you can see before you accept it
risk register · named risks, cost and likelihood — nothing dropped silently
Assessments typically produce a written risk register: what could go wrong, how likely, what it would cost you, and what we would do to reduce it. Items we cannot resolve stay on the register as open risks with your name against the acceptance — they do not get quietly dropped because they are inconvenient.
The risks that actually bite in this segment are boring and predictable: an undocumented dependency on a server that was not in scope, a licence that does not travel, an application whose vendor will not support it in Azure, a backup that has never been restored, and a firewall rule that only one person understands. We go looking for those in the assessment, because finding them during a cutover is what turns a weekend into a fortnight.
Downtime you scheduled, not downtime you discovered
cutover rule · a failed rehearsal cancels the cutover — no exceptions
Every workload in the plan gets a migration method, a rehearsal, a stated downtime window and a rollback that has been tested rather than described.
Most workloads move with minutes of downtime using replication-based methods that keep the source running until you cut over. Some cannot — a large database on a thin network link, or an application that must be reinstalled rather than moved. Those are typically identified during the assessment, then scoped and scheduled with you before you commit to a date. You approve every window in advance.
If the rehearsal fails, the cutover does not happen. That is the rule, and it is written into the plan rather than negotiated at midnight.
What the landing-zone diagram above shows, in full:
- Your offices connect into the tenant over a network link, so the estate is reachable from where the people are.
- The tenant is the outer boundary: one directory, one set of policies, everything below it inside.
- The platform subscription holds what every workload shares, so no application owns it.
- Identity (Entra ID) lives there — accounts, groups and the conditional-access rules that gate them.
- Connectivity (the hub) lives there too: the shared network every workload network peers back to.
- Management — logging, backup and monitoring — is shared for the same reason.
- The workload subscription holds one application's own spoke network and its app and data resources, peered to the hub, so a workload can be changed, priced or removed without touching the platform.
A cost you can defend to a CFO
Azure is not automatically cheaper than what you run today. Anyone who tells you otherwise on a first call has not looked at your estate.
What Azure does reliably give you is cost you can see, attribute and change — which is often the more valuable property. The assessment typically produces a monthly run-rate estimate built from your actual utilisation rather than your server specifications, because most on-premises servers are sized for a peak that happens twice a year.
We model the levers explicitly and show you what each one is worth:
| Lever | What it does | Applies when |
|---|---|---|
| Right-sizing | Match resources to observed use, not to the tin you bought in 2019 | Almost always; usually the single largest saving |
| Reserved instances / savings plans | Commit to a term for a lower rate | Steady-state workloads you are confident about |
| Azure Hybrid Benefit | Apply existing Windows Server or SQL Server licences to Azure rates | Only if you hold active Software Assurance or equivalent subscriptions |
| Non-production schedules | Shut down dev and test outside working hours | Wherever a non-production environment exists |
| Storage tiering | Move cold data off premium storage | Estates with large archives or long retention |
| PaaS instead of VMs | Remove OS licensing, patching and upgrade effort | Where the application supports it — see SQL Server to Azure SQL |
Typically you also get the number nobody volunteers: the one-time cost of the migration itself, separated from the run-rate, so the business case is not quietly subsidised by leaving the project cost out of it.
Compliance questions you can answer in an afternoon
licensing dependency · Conditional Access and Defender need certain Microsoft 365 plans
A buyer whose auditor, insurer or largest customer reviews vendors does not get to treat access control as a technical detail. Sooner or later somebody asks who could reach production data, when, and on whose authority — an auditor, a large client's vendor-risk team, a card processor's questionnaire, or an incident.
We build environments where that question has a report as its answer:
- Named individual accounts. No shared credentials, no
adminaccount four people know the password to. - Least privilege by default, with elevation that is requested, approved, time-bound and logged — not permanent standing access.
- Multi-factor authentication enforced, including for administrators, including for us.
- Logging and retention configured deliberately, to a period you chose, rather than left at whatever the default was.
- Backups with a tested restore, because an untested backup is a belief, not a control.
What we migrate
- Windows Server and Linux workloads — rehosted to Azure virtual machines, or re-platformed where the application allows it.
- SQL Server — to Azure SQL Managed Instance, Azure SQL Database, or SQL Server on Azure VMs. Which one depends on the application's compatibility, not on our preference. See SQL Server to Azure SQL.
- File shares — to Azure Files or SharePoint, with permissions preserved and, usually, a long-overdue conversation about who should have access to what.
- Microsoft 365 and identity — tenant configuration, Entra ID, Conditional Access where licensing permits, device management, and email authentication (SPF, DKIM and DMARC, which are missing or incomplete in most estates we look at).
- Microsoft 365 / Exchange tenant transitions — mailboxes, domains, tenant-to-tenant moves, run as their own workstream rather than a side effect of a server migration.
- Entra ID identity and role-based-access rollouts — a deliverable in its own right, not only a component migrated alongside everything else.
- Web applications — to Azure App Service, Static Web Apps or containers where they fit.
- Backup and disaster recovery — to Azure Backup and Azure Site Recovery, with a restore that gets tested.
SQL Server 2016 · out of extended support · · Microsoft Learn — SQL Server 2016 lifecycle
company delivery history — tenant transitions, identity rollouts · founder-asserted ·
Server and systems migrations, backups and provisioning are not new work here — they are what most of this team did before Azure was the destination. Backgrounds on the team include server support and support systems at global technology companies. Backgrounds on the team also include systems engineering — SCCM and App-V endpoint deployment — at industrial and IT-services companies.
company delivery history — migrations, backups, provisioning · founder-asserted ·
past employment of individual engineers, not AS DataWorks client work · founder-supplied ·
What this silo covers
What the engagement looks like
Every engagement is scoped and quoted individually, with you, before any work starts.
Assess. Read-only. We inventory what you run and what it depends on — servers, databases, applications, network paths, identity, licensing, backups — and typically hand back a dependency map, a workload-by-workload recommendation, a costed run-rate, a risk register and a wave plan.
Plan. We turn the recommendation into a landing zone design: subscriptions, networking, identity, guardrails, backup and disaster-recovery targets, defined as code in your repository from day one.
Migrate. In waves, smallest blast radius first. Each wave is built, replicated, rehearsed, cut over inside a window you approved, then run in parallel until you sign off.
Run. After the final cutover we hand over documentation, the infrastructure code, and a runbook — not a PDF and an invoice — then sit alongside your team for an agreed period, typically the first month.
after handover · an agreed period, typically the first month
[PLACEHOLDER] whether an ongoing support arrangement exists after that
Built for
- 15 to 500 employees in the United States, with an estate you cannot take offline on a guess.
- A deadline that is real: a support date passing, a hosting contract expiring, hardware out of warranty, an audit finding, or a peak season you cannot risk.
- An estate of a handful to a few dozen servers, typically Windows Server and SQL Server.
- Microsoft 365 already in use, or about to be.
Not a fit
- You need a regulatory audit, an attestation, or a signed compliance opinion — we build environments that stand up to those reviews, we don't issue the opinion.
- You run thousands of servers or a global estate — a large systems integrator is the right shape of firm for that.
- You want a lift-and-shift by Friday with no assessment.
- Your only driver is "the board wants a cloud strategy" with no operational problem underneath it — the assessment will probably tell you to stay where you are, and we will still charge for saying so.
Two pages worth reading before the call:
Questions buyers actually ask
Will the business be down?
Some, briefly, and you will know when.
Most workloads move with minutes of downtime, using replication that keeps your current environment running until the moment you cut over. Some genuinely cannot — a very large database over a constrained link, or an application that has to be reinstalled and reconfigured rather than replicated. Those are typically identified during the assessment, then scoped and scheduled with you.
Three commitments: you approve every downtime window in advance; every cutover is rehearsed first; and every cutover has a tested rollback. If the rehearsal does not pass, the cutover does not happen.
SQL Server 2016 is out of support. Does that mean we have to move to Azure?
No — and this is worth getting right, because the usual pitch is wrong.
SQL Server 2016 reached end of extended support on 14 July 2026. Extended Security Updates are available for up to three years after that, until 17 July 2029.
You will hear that migrating to Azure gets you those updates free. That is not true for SQL Server 2016. Microsoft's own documentation is explicit: "Starting with SQL Server 2016 (13.x), migrating your workload to SQL Server on Azure VMs no longer provides free access to ESUs for SQL Server 2016 (13.x) instances." That benefit existed for SQL Server 2014. It does not carry forward. If a vendor uses free ESUs as the reason to move your 2016 estate to Azure VMs, they are working from an old deck.
Your real options are four: upgrade in place, subscribe to Extended Security Updates, rehost to Azure VMs, or re-platform to Azure SQL Managed Instance or Azure SQL Database. Which is right depends on your application's compatibility, your licensing position, and whether you would rather spend money once or annually.
The full option-by-option breakdown — including the two options that are not an Azure migration at all — is on SQL Server to Azure SQL.
Is Azure actually going to cost us less than what we run now?
Sometimes, and not always, and you should be suspicious of a firm that promises a percentage before seeing your utilisation data.
Here is the honest version. If you compare a like-for-like rehost of over-provisioned servers against already-depreciated hardware, Azure often looks more expensive on the monthly line. The comparison usually turns when you include what the current setup actually costs: hardware refresh, hypervisor and OS licensing, datacenter or hosting, power, the disaster-recovery site you pay for and hope never to use, and the engineering time spent on maintenance that produces nothing.
It also turns on right-sizing. Most on-premises servers are specified for a peak that occurs twice a year, and you paid for that peak in advance and permanently. In Azure you pay for what you use, and can change it in an afternoon.
The assessment typically gives you a run-rate estimate from observed utilisation, the one-time migration cost, and the levers in the table above with a value against each. If that comparison does not favour moving, it will say so.
Do we have to move everything at once?
No, and you should not.
We sequence in waves, and the first wave is deliberately chosen for low risk and easy reversibility — something that matters enough to be a real test, but whose failure would not stop the business. That first wave is where you find out whether the plan was any good and whether you want to keep working with us, at the smallest possible cost of finding out.
Many estates end up permanently hybrid, and that is a legitimate destination rather than a failed migration. Some workloads should not move: a system whose vendor does not support it in Azure, a machine tied to physical hardware, or something being replaced in eighteen months anyway. The assessment typically says which, and why.
Start with a call about what you are trying to fix.
Book an assessment call30 minutes · with the engineer who would scope the work
one-page recap within 2 business days of a call that progresses