Skip to content

Azure cloud migration

Azure conversations rarely start from a blank page. They start from an estate: an Active Directory tenant, a SQL Server nobody wants to patch, a data center lease with an end date, or a licensing renewal that suddenly changes the arithmetic.

01Capabilities

Four shapes of Azure programme, and which one you are in

Azure arrives with things already attached: servers, identity, databases, and an agreement that shapes the cost of every option. The work runs as cloud migration and cloud infrastructure engineering, and four shapes account for most of it.

  • Migration

    Migrations off on-premise infrastructure

    Assessment first, using Azure Migrate to discover what actually runs and what depends on what, then Site Recovery to replicate and rehearse a failover before anyone commits to a date. The compute is rarely the hard part. The data cutover, the DNS and the rollback path you hope not to use are. Two of the case studies below are exactly this shape, including a booking platform in hospitality.

  • Database

    Database moves and the version you are stuck on

    Azure Database Migration Service handles the mechanics of getting an on-premise database into Azure. The decision that matters comes earlier: Azure SQL Database, SQL Managed Instance or SQL Server on a virtual machine, and that is a compatibility question before it is a hosting one. The detail sits on SQL Server.

  • Governance

    Landing zone, identity and governance

    Subscriptions, management groups, networking, and the Entra ID and Active Directory integration that is usually the reason Azure was chosen in the first place, plus policy so security has something to audit. Infrastructure as code from the start, because a landing zone assembled by hand in the portal cannot be reviewed or rebuilt.

  • Hosting

    Where workloads land, and what it costs to run

    App Service, Container Apps or AKS is a per-workload call rather than a platform doctrine, and it is tied to how your .NET services are actually built. Around it: auto-scaling that responds to real demand, monitoring, alerting, and pipelines in Azure DevOps or whatever you already run. That side is DevOps consulting.

03Fit

What a Microsoft estate settles, and what it leaves open

Azure wins on identity and licensing far more often than on any per-service comparison, and the table starts from that. Each row below names the call that fits that estate, from Azure itself to AWS, a managed app platform or cost work where you are. Nothing we earn depends on which cloud you choose, so the call follows your estate.

Six estates, and the call we would make on each
Your situationWhat we recommend
A Microsoft-centric estate: .NET, Active Directory, SQL Server, an enterprise agreement you already pay for Use AzureIdentity integration and licensing decide this, and they outweigh any per-service comparison you could run.
On-premise SQL Server with years of stored procedures, Agent jobs and cross-database queries Managed InstanceAssess compatibility before anyone discusses price, because compatibility is what constrains the choice. Detail on SQL Server.
A mixed estate, unusual managed-service needs, and a platform team already fluent in AWS Different pageOur AWS page. Service breadth is a real advantage, and retraining a platform team is a cost people forget to count.
The whole reason to be in a cloud is analytics, or a model over your event data Compare firstPut Google Cloud in the argument properly. If the warehouse is the point, BigQuery deserves the comparison rather than losing it by default.
One predictable application, a small team, and nobody genuinely on call for it A managed app platformA managed platform costs less to run and far less to operate. A landing zone solves governance problems you do not have yet.
The bill is what actually hurts, and the architecture is doing its job Cost it firstFix the cost profile where you are. Moving a bill nobody can explain to a new provider gives you a bill you understand less.

Scope

What we own on an Azure engagement is the architecture decision and everything downstream of it. That means the cost profile, the failure modes, the identity and network boundaries, and whether your own team can operate the estate after we hand over. We build and run these estates under an ISO 27001:2022 certified information-security management system. unicrew has been doing this work since 2012, with 100+ senior in-house engineers across six countries. When the estate needs less moved than you planned, the plan says so and sizes the migration to match.

For an estate on Active Directory, SQL Server and .NET, Azure is usually the natural choice. The Agent jobs, linked servers and cross-database queries then decide which hosting option fits, so we assess them first.

Oleksandr TrofimovChief Technology Officer, unicrew

04Delivery

Sequencing a move that cannot pause the business

The sequence decides the outcome more than the tooling does. Steps one and three are where migrations are won or lost, and we do not compress them to look fast.

  1. Discover what actually runsThe Azure Migrate appliance collects real dependency and utilization data over a period rather than a single snapshot, and we read it against whatever documentation exists. The integration nobody remembered is the one that breaks on cutover night, and it is almost never in the handover pack.
  2. Choose rehost, re-platform or rebuild, per workloadMost estates need all three, and a program-wide doctrine is how timelines slip. Sizing comes from the utilization data rather than the on-premise spec, because lifting an over-provisioned server straight into Azure is the fastest way to buy a bill nobody can defend.
  3. Landing zone, and a rehearsed way backSubscriptions, networking, identity and policy before any workload moves, and a tested rollback for each one. Site Recovery lets you rehearse a failover against real data, so the cutover is a repeat rather than a first attempt. A migration without a rehearsed rollback is a bet with a project plan attached.
  4. Move, prove parity, then optimizeCut over workload by workload, verify behaviour against real traffic, and tune cost and performance afterwards. Optimizing during the move makes it impossible to say which change caused a regression. Each cutover is checked through the same QA and test automation practice we use on our own builds.

07Questions

Asked before the first workload moves

The six that come up most, answered the way we would answer them on a call.

Yes, and on an Azure estate that is often the sensible shape, because your people hold the licensing context. Our engineers bring ownership of the architecture with them: an architect outside the delivery team reviews the design, and the work goes through the same QA practice we use on our own projects. Every Azure certification we put forward can be confirmed in Microsoft's own directory. Team extension is managed teams; an outcome is cloud migration.

It comes down to what you already run, not a feature comparison. A Microsoft estate with Active Directory, SQL Server and an enterprise agreement is normally cheaper on Azure, because identity and licensing dominate total cost. Where the estate is mixed or your platform team is already fluent in AWS, breadth tends to win. Our AWS page argues that side in the same words, deliberately.

Managed Instance when you are lifting an existing estate, because it keeps what applications quietly depend on: Agent jobs, cross-database queries, and more surface area than Azure SQL Database exposes. Azure SQL Database when the workload is one well-behaved database you are building now. A virtual machine only when an OS-level dependency genuinely forces it. Compatibility decides this, so we assess it before anyone talks about price. More on SQL Server.

Per workload, and usually not both at once. Rehosting first gets you off the hardware that is the actual risk, and makes the next decision cheaper. Modernizing under a lease deadline is how one migration turns into two failed projects. The exception we insist on is sizing: rehost against the utilization data, never the on-premise spec. Where the applications are the real problem, that is legacy modernization.

A scoping call with an engineer rather than a salesperson. For an existing estate we ask for read access to the subscription and the billing data, because an hour in the real inventory beats several in discussion. What comes back is written: the migration path, the cost profile, and which workloads stay where they are. Most engagements start within two to four weeks.

Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix, so it is quoted rather than listed.

Planning a move to Azure, or stuck halfway through one?

Send us the workload inventory, your identity setup, and where the deadline comes from. You will get an engineer's read on the path and the cost profile. That includes the workloads to keep in place, and the case for AWS if it points there.

Book a scoping call

Thank you

Thanks for your message. We will get in touch with you shortly.