Azure migration, assessed before it is promised.

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 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 you are actually buying

Risk you can see before you accept it

Every assessment produces 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

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 identified in the assessment and priced honestly, in hours, 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.

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 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:

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

Finance and retail buyers do 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 admin account 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. SeeSQL 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).
• 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.

What the engagement looks like

1. Assess. Read-only. We inventory what you run and what it depends on — servers, databases, applications, network paths, identity, licensing, backups — and hand back a dependency map, a workload-by-workload recommendation, a costed run-rate, a risk register and a wave plan.

2. 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.

3. 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.

4. Run. For the first month after the final cutover we sit alongside your team, then hand over documentation, the infrastructure code, and a runbook — not a PDF and an invoice.

after handover · documentation, the infrastructure code and a runbook, plus the first month alongside your team · [PLACEHOLDER: whether an ongoing support arrangement exists after that, and what it includes]

Two pages worth reading before the call:

• How the engagement and the pricing conversation actually work
• Access, data handling and our own security posture