Skip to main content

Cloud Modernisation on Microsoft Azure

Cloud migration and modernisation on Microsoft Azure

Azure suits organisations whose identity, productivity and line-of-business systems already sit with Microsoft, because the migration reuses directory, licensing and operational patterns your team already understands. We assess with Azure Migrate, move workloads in waves, and replatform the applications where the code, licence and vendor support statement genuinely allow it. The ones that still need a virtual machine stay on one without apology. The landing zone underneath is assumed to exist and to be deployed from code; where it does not, that comes first.

Why Azure

When this is the right platform.

  • Windows Server, SQL Server and .NET workloads move with the fewest surprises, and existing Software Assurance can change the run cost materially, so the licence position belongs in the business case rather than turning up as a late discovery.
  • If your people already sign in through Microsoft Entra ID for email and Microsoft 365, the platform inherits that identity, conditional access and group structure instead of introducing a second directory to maintain.
  • Azure VMware Solution lets a VMware estate move as a cluster without replatforming every workload first, which matters when a data centre lease or a hardware refresh sets the deadline rather than the application roadmap. Since October 2025 the VMware Cloud Foundation subscription is bought from Broadcom and brought to Azure, so price the licence separately from the Azure nodes.
  • Azure Arc extends policy, inventory and monitoring to servers and Kubernetes clusters that stay on-premises or run elsewhere, so a partly migrated estate can still be governed from one place for the years it takes to finish.
  • Azure Migrate assesses more than servers, including SQL Server, web applications, file shares and SAP, which keeps the disposition decision for those workloads in the same evidence base as the infrastructure.
  • Engineers with Active Directory, Group Policy and Windows operations backgrounds find the concepts familiar, which shortens the period where the platform depends on outside help.

Where it is less suited

We would rather say this now than after a migration.

  • Azure VMware Solution is priced on reserved host capacity and, since October 2025, on a VMware Cloud Foundation subscription you buy from Broadcom rather than from Microsoft. Existing pay-as-you-go nodes need a licence key in place before November 2026. It earns its place when there is a dated exit from the existing data centre, and used as an indefinite destination it keeps virtual machine operational overhead while adding cloud cost and a Broadcom renewal.
  • The classic Azure Site Recovery experience for VMware virtual machines and physical servers retired in March 2026. Recovery arrangements built on it years ago are not a working position today, and finding that out during an audit is the expensive way.
  • Azure Migrate sizes from a collection window. A window that misses month-end, a batch cycle or a seasonal peak produces a target that looks right in the business case and is wrong in production, so we insist on a window long enough to include the workload's real peak.
  • Some workloads will not qualify for App Service, Container Apps or a managed database, whether because of an unsupported runtime, a hardware dependency or a vendor support statement. They stay on virtual machines, and the operating model has to keep image management and patching in scope for them.
  • Azure Cost Management reports accurately, but it can only group spend the way your tags and scopes allow. Retrofitting tags across an estate that grew without standards is manual work, which is why tag enforcement belongs in the platform foundation rather than in a later clean-up.
  • Much of the Windows and SQL Server cost advantage depends on Software Assurance and Azure Hybrid Benefit. If those entitlements are not in place the comparison against AWS narrows considerably, and we would rather say that in assessment than build a business case on an entitlement you do not hold.

Business outcomes

What Azure delivers here.

Windows and SQL estates back on supported footing
Application owners get operating systems, database engines and runtimes on versions that still receive security updates, which removes the exception register that has been growing quietly for years.Agreed measure: Version currency tracked as a standing measure per workload, with the target agreed before the first wave.
Failover you have watched happen
Risk and operations get replication and backup configured to the recovery objectives set per workload, then exercised in a scheduled test with the result written down.Agreed measure: Whether the tested recovery time meets the objective the business agreed, per workload, not whether a plan exists.
A deliberate virtual machine footprint
Workloads that fit Azure App Service, Container Apps or a managed database move off instances, and the ones that cannot are listed with the reason, so image management stays a known cost rather than a habit.Agreed measure: Share of workloads still requiring instance-level patching, with the target set during assessment.
One governance plane across cloud and on-premises
Infrastructure teams manage servers still in the data centre and workloads already in Azure through the same policy, inventory and monitoring surface using Azure Arc.Agreed measure: Proportion of the estate under policy and inventory coverage, agreed as a target at the outset.
Cost attributed to the business, not to IT
Finance receives Azure spend split by business unit, environment and application because tags and scopes were designed for that reporting from the first wave. Untagged spend is reported as its own line so it cannot hide inside a shared total.Agreed measure: Untagged spend as a share of the monthly invoice, reported against the threshold you set.
A dated exit from the source environment
Each wave ends with the on-premises workload switched off, the licence released and the evidence filed, so the saving in the business case actually arrives instead of being consumed by parallel running.Agreed measure: Switch-off date per source system, tracked per wave with the evidence required for release agreed up front.

Common client problems

What we usually hear first.

  • We already run Microsoft 365, but our servers sit in a comms room here and the hardware falls out of warranty next year.

    We use the existing Entra ID tenant as the identity foundation, then assess the on-premises estate with Azure Migrate to size and cost the target before committing to a date. The hardware warranty becomes the backstop for the migration plan rather than the thing that dictates a rushed rebuild.

  • Our VMware renewal has changed and we now have a deadline we did not plan for.

    Azure VMware Solution can take the cluster largely as it runs today, which converts an immovable renewal date into a staged modernisation you control. Be clear-eyed about the commercials: Microsoft stopped selling AVS with the VMware Cloud Foundation subscription included in October 2025, so you bring a portable subscription from Broadcom, and existing pay-as-you-go nodes need a licence key in place before November 2026. We plan the exit alongside the move, so workloads leave for App Service, Azure SQL Database or containers on a schedule rather than staying on reserved hosts indefinitely.

  • Half our SQL Servers are on a version that is out of extended support.

    We assess each database for compatibility with Azure SQL Database or Azure SQL Managed Instance, and where the application blocks that, we plan an in-place upgrade on Azure Virtual Machines with a defined path off later. Every database gets a target, a cut-over rehearsal and a validation step before the old server is switched off.

  • Our disaster recovery was built on Site Recovery years ago and nobody has touched it.

    Then it needs checking rather than trusting. The classic Azure Site Recovery experience for protecting VMware virtual machines and physical servers retired in March 2026, so anything still configured that way is not a working recovery position. We audit what is actually replicating, move protection onto the current experience or onto Azure Backup where restore alone meets the objective, then run a test failover and record the result.

  • Nobody can tell me which of our Azure resources are still being used.

    We combine Azure Monitor activity and metric data with Azure Cost Management to identify resources with no traffic, no recent change and no owner tag. Findings come back as a decommissioning list with the monthly cost of each item, so the clean-up decision is easy to make and easy to defend.

  • We were told everything should go to containers and now nobody wants to own the cluster.

    Containerisation is a means, not a destination, and Azure Kubernetes Service is only worth its operational overhead where workload density, custom networking or existing Kubernetes tooling justify it. Most line-of-business web applications are better served by Azure App Service or Azure Container Apps, which remove node patching and cluster upgrades from your team entirely. We make that call per application and write down the reason, because the cheapest cluster is the one you never had to run.

How we deliver

Our Azure delivery approach.

  1. 01

    Assessment and advisory

    The Azure assessment combines tooling output with the commercial context that tooling cannot see, including licence entitlements, contract dates and which applications the business will not tolerate any downtime on.

    • Azure Migrate discovery and dependencies. Servers, SQL Server instances, web applications and file shares discovered and dependency-mapped, reconciled against your asset register and the people who support each system.
    • Licence position priced properly. Windows Server and SQL Server entitlements, Software Assurance and Azure Hybrid Benefit, plus reservation and savings plan options, so the run cost reflects what you can actually claim.
    • Sizing from utilisation, not specification. Targets set from observed performance over a collection window long enough to include month-end, with the on-premises comparison stated in the same units.
    • VMware options costed side by side. Azure VMware Solution against native rehosting, including the Broadcom-supplied VMware Cloud Foundation subscription and the reserved host commitment behind AVS.
    • Recovery objectives per workload. Business tolerance translated into a backup frequency, replication design and expected failover behaviour, workload by workload rather than as one estate default.
    • Landing zone gap check. The existing foundation reviewed against the Microsoft Cloud Adoption Framework so anything missing is built before wave one, not discovered during it.
    • Wave plan with rollback triggers. Cut-over windows, rollback triggers and the acceptance criteria each wave must meet before the next one starts, agreed with the application owners who sign off.
  2. 02

    Architecture and implementation

    The Azure build sequences the hard-to-reverse decisions first, then adds workloads. We keep the platform layer separate from the applications so that either can evolve without forcing a rebuild of the other.

    • Hybrid connectivity tested against applications. Azure ExpressRoute or site-to-site VPN established with routing, name resolution and failover behaviour proven against the systems that will cross the link, not just the tunnel.
    • Server migration with test cut-overs. Azure Migrate replication into an isolated network so application owners validate their own systems with real data before the production window opens.
    • VMware estate moved as a cluster. Azure VMware Solution used where a lease or renewal date rules out per-workload replatforming, with a dated plan for what leaves it and when.
    • Runtime chosen per application. Azure App Service, Azure Container Apps or Azure Kubernetes Service selected on isolation, scaling and operational skill requirements, with the reasoning documented per application.
    • Data tier onto managed database services. Azure SQL Database or Azure SQL Managed Instance where the schema fits, and Azure Cosmos DB where the access pattern is key or document based, each with a rehearsed cut-over.
    • Ingress standardised, not per application. Azure Front Door, Azure Application Gateway and Azure API Management handling certificates, web application firewall policy and routing centrally.
    • Environments deployed from code. Bicep or Terraform through your existing pipeline from the first environment, so a rebuild is a pipeline run and configuration drift shows up in a diff.
  3. 03

    Security and governance

    Azure gives you platform-level controls that are much cheaper to apply before workloads land. Migration is the moment to close the gaps that were tolerated on-premises, using the guardrails the platform foundation already inherits.

    • Guardrails applied as workloads land. Azure Policy initiatives covering allowed regions, allowed resource types, mandatory tags, encryption and diagnostic settings, with compliance reviewed on a set cadence rather than at audit time.
    • Entra ID roles designed least privilege. Built-in roles preferred, separate identities for administrative work, and time-bound approved elevation instead of standing rights carried over from the old domain.
    • Platform traffic off public addresses. Private endpoints and service endpoints so database and storage traffic stays on the virtual network, with the inbound exposure list reviewed at each wave close.
    • Diagnostics into one workspace. Azure Monitor diagnostic settings sent to the central Log Analytics workspace with retention agreed against your record-keeping obligations.
    • Protection status as a compliance metric. Azure Backup and, where restore alone will not meet the objective, replication enforced by policy and reported rather than checked by hand each month.
    • Control mapping, not certification. How the deployed Azure configuration supports the Essential Eight or ISO 27001 controls you are working towards, and which gaps remain a process responsibility.
  4. 04

    Adoption and enablement

    Your team needs to be able to add the next workload without us. Enablement is built around the operations they will perform in the first six months, using the environment we have just built.

    • Workload onboarding guide. Naming, tagging, policy exemption requests and the approvals each step needs, written for the person doing it rather than for an architect.
    • Hands-on sessions in the real environment. Scale operations, restore from Azure Backup, a failover rehearsal, and reading an Azure Monitor alert back to a root cause.
    • Cost views built per owner. Azure Cost Management scoped to each application and business-unit owner, rather than one tenant-wide dashboard nobody feels responsible for.
    • Escalation paths written down. What is a platform issue, what is an application issue and what is a Microsoft support case, with the information required for each.
    • First change run by your engineers. A joint dry run of the first post-go-live change, executed by your team with us observing rather than driving, followed by a review of what the runbooks missed.
    • Source decommissioning checklist. Data retention, licence release, backup retention and the sign-off needed before hardware leaves the building.
  5. 05

    Managed service continuation

    After go-live we can continue operating the Azure platform with you under an agreed service schedule, keeping the governance and cost discipline in place once the project team has moved on.

    • Alert tuning, not alert accumulation. Azure Monitor rules triaged with noisy ones retired and coverage extended as new workloads land, reported at each review.
    • Policy compliance and drift reporting. Resources created outside the standard pattern and exemptions approaching expiry, interpreted before they are escalated.
    • Restore and failover rehearsals. Scheduled restore tests from Azure Backup and periodic failover rehearsals, with results and any remediation recorded rather than assumed.
    • Monthly cost optimisation review. Spend by business unit, reservation and savings plan coverage, idle resources and specific rightsizing actions with the saving quantified before you decide.
    • Patch and image currency. Azure Virtual Machines, container images and managed service versions kept current against an approved maintenance calendar.
    • Modernisation candidates kept visible. A prioritised backlog of resilience gaps, cost actions and workloads still on virtual machines that now have a business case to move.

Reference architecture

Legacy estate to Azure, wave by wave.

How the pieces fit together on Microsoft Azure. Every engagement adapts this, and we will tell you which layers you already have.

  1. 01

    Discover

    Utilisation, dependencies, licence position and a disposition per application.

    • Azure Migrate appliance
    • Dependency analysis
    • Disposition register
  2. 02

    Prerequisite

    The landing zone already exists and is deployed from code, not built mid-wave.

    • Management group hierarchy
    • Hub network and ExpressRoute
    • Log Analytics workspace
  3. 03

    Move

    Replication, a rehearsed test cut-over, and a rollback valid until sign-off.

    • Azure Migrate replication
    • Azure VMware Solution
    • Isolated test cut-over network
  4. 04

    Modernise

    Only where the runtime, licence and vendor support statement allow it.

    • Azure App Service
    • Container Apps or AKS
    • Azure SQL Database or Managed Instance
  5. 05

    Prove and exit

    Tested restore, attributed spend, source systems actually switched off.

    • Azure Backup restore test
    • Azure Cost Management and tags
    • Source decommissioning

Across every layer

  • Access through Entra ID groups, with elevation time-bound and approved
  • Mandatory tagging so spend attributes to a business unit from day one
  • Every environment deployed from version-controlled code
  • A named human approval at each cut-over and each decommissioning
Layer 05 is the one cut when a date slips, and it is the only layer that produces a saving. Until the source environment is switched off and a restore has been tested on the record, you are paying for two data centres and can prove recovery on neither.

Technology reference

The Microsoft Azure services we build with.

A reference architecture view of the platform services used in this domain, and what each one does in the design.

Assessment and migration

  • Azure MigrateDiscovery, dependency mapping and sizing across servers, SQL Server, web applications and file shares, then server replication with test cut-overs into an isolated network.
  • Azure Virtual MachinesTarget for workloads that cannot move to platform services yet, sized from observed utilisation rather than existing specification.
  • Azure VMware SolutionDestination for VMware estates constrained by a lease or renewal date, used as a staging point with a dated exit, on a VMware Cloud Foundation subscription you bring from Broadcom.
  • Azure ArcExtends policy, inventory and monitoring to servers and clusters that remain on-premises, keeping a partly migrated estate governed from one place.

Application runtime

  • Azure App ServiceHosting for web applications and APIs that can leave a virtual machine, giving managed patching, scaling and deployment slots.
  • Azure Container AppsContainer hosting for teams that want scale-to-zero and revision-based releases without operating a Kubernetes cluster.
  • Azure Kubernetes ServiceContainer platform where workload density, custom networking or existing Kubernetes tooling justifies running and upgrading the cluster.
  • Azure Container RegistryThe image supply chain behind container workloads, with tag locking and retention rules. Image vulnerability scanning comes from Microsoft Defender for Cloud rather than the registry itself, which is a separate plan billed per subscription.
  • Azure FunctionsEvent-driven and scheduled processing, replacing task scheduler jobs and small always-on services that no longer justify a server.

Data platform

  • Azure SQL DatabaseManaged target for SQL Server databases, removing version currency and backup administration from the application team. Managed Instance is used where the schema needs instance-level features.
  • Azure Cosmos DBUsed where the access pattern needs low-latency key or document reads at high volume rather than relational joins.

Network, ingress and connectivity

  • Azure Virtual NetworkSegmented network design with subnet-level separation, private endpoints and controlled routing between environments.
  • Azure ExpressRoutePrivate connectivity between the data centre or office and Azure where bandwidth, latency or predictability rule out internet VPN.
  • Azure Front DoorGlobal entry point with caching, health-based routing and web application firewall policy applied consistently across sites.
  • Azure Application GatewayRegional layer-seven load balancing and web application firewall for applications that terminate inside the virtual network.
  • Azure API ManagementFront door for internal and partner APIs, centralising authentication, rate limiting, versioning and usage visibility.

Resilience, governance and cost

  • Azure BackupPolicy-driven backup for virtual machines, databases and file shares, with protection status reported as a compliance metric.
  • Azure Site RecoveryReplication and orchestrated failover for workloads whose recovery objective cannot be met by restore alone, on the current experience rather than the retired classic one.
  • Azure MonitorCentral metrics, logs and alerting, with diagnostic settings enforced by policy so new resources are observable by default.
  • Azure PolicyGuardrails for regions, resource types, tagging and encryption, inherited from the platform foundation as each migrated workload lands.
  • Azure Cost ManagementSpend attribution by business unit and application, budget alerts, and reservation or savings plan coverage analysis.
  • BicepEnvironment definitions deployed through your existing pipeline, so any environment can be rebuilt and two environments can be compared in a diff.

Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.

Azure questions

What people ask about doing this on Azure.

Cost, lock-in and the parts that go wrong, answered before you have to ask twice.

  • What happens to Azure VMware Solution now that Broadcom sells the licence?

    The service has not changed but the commercials have. Microsoft stopped selling AVS with a VMware Cloud Foundation subscription bundled in October 2025, so new nodes need a portable subscription bought from Broadcom, and existing pay-as-you-go nodes need a licence key in place before November 2026. Practically that means two suppliers, two renewal conversations and a licence cost that follows you into Azure. It still shortens a data centre exit, but it is no longer a way to escape VMware pricing.

  • Is Azure cheaper than AWS for our Windows and SQL Server estate?

    Often, and it depends almost entirely on entitlements rather than on list prices. With Software Assurance and Azure Hybrid Benefit you can apply existing Windows Server and SQL Server licences to Azure compute, and Extended Security Updates for older SQL Server versions are handled differently in Azure than elsewhere. Without those entitlements the gap narrows a long way. We price your actual licence position in the assessment rather than quoting a general advantage, because the answer changes per client and sometimes lands the other way.

  • How do we stop the Azure bill climbing after a lift and shift?

    By deciding four things before the first wave rather than after the first invoice: sizing from observed utilisation, a schedule for non-production environments that do not need to run overnight, reservation or savings plan coverage for the steady baseline only, and tag enforcement so any increase is attributable to somebody. The line that grows quietly is log ingestion and retention, which nobody owns and every new workload adds to. We report it separately for that reason.

  • Can we keep some servers on-premises and still manage them from Azure?

    Yes, and for most Australian mid-market estates that is the honest end state for a few years rather than a transitional phase. Azure Arc projects on-premises servers and Kubernetes clusters into Azure for policy, inventory, monitoring and update management, so one governance surface covers both. It does not make them cloud workloads: the hardware, the hypervisor and the data centre contract remain yours, and Arc adds its own agent estate to keep current.

  • Should everything move to App Service and AKS, or can we stay on virtual machines?

    Plenty of workloads should stay on virtual machines and saying otherwise sells work nobody needs. An unsupported runtime, a hardware dongle, a vendor support statement that names specific operating systems, or an application whose remaining life is 18 months are all good reasons to rehost and stop. We publish the reason per application so the decision survives the next architect. Where a workload does fit App Service or Container Apps, the saving is usually operational hours rather than compute cost.

  • Can our Windows administrators run this, or do we need to hire cloud engineers?

    Most can, and the transition is genuinely shorter on Azure than on AWS for a Microsoft-centric team, because the identity, group and update concepts carry across. What tends to be missing is infrastructure as code, network design at cloud scale and cost management as a routine discipline. We would rather spend part of the engagement building those three habits in your existing team than leave you dependent on us, and if your constraint is headcount rather than skill we will say so plainly.

  • How locked in are we once workloads are on Azure platform services?

    It varies by layer and it is worth choosing deliberately. Virtual machines and containers are close to portable. Azure SQL Database is broadly compatible with SQL Server, so moving is possible but not trivial. Functions, Front Door policy, API Management configuration and anything wired into Entra ID are where switching costs concentrate. We name the exposure per workload during assessment so the trade is made with open eyes, and we do not recommend an abstraction layer whose only purpose is a migration you will probably never run.

Related industries

Where this work has the most leverage.

  • Construction and Property

    Tender intelligence, addenda tracking and project reporting that keep estimators and contract administrators ahead of the documents instead of buried in them.

  • Professional Services

    Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.

  • Healthcare and Community Services

    Administrative automation, policy search, workforce analytics and privacy uplift for healthcare and community providers, with clinical decisions left entirely to clinicians.

Free discovery workshop

Start with a cloud modernisation discovery workshop.

Bring one challenge. We will assess whether Microsoft Azure is the right platform for it before recommending anything.