Cloud migration to Azure and Microsoft 365
We migrate applications, servers, email and project data to Azure and Microsoft 365, connecting them to the systems that remain local. We establish what should move, build the cloud foundation and deliver the migration in stages. Our engineers can then manage the environment across cloud and on-premises.
- Placement Done
- 38 systems mapped
- Destinations agreed
- Foundation Done
- Identity and network
- Policy and backup
- Migration In progress
- Wave 2 cutover Saturday
- Rollback point set
- Operation Next
- Monitoring and patching
- Monthly cost review
Azure, on-premises or hybrid, decided workload by workload
We map applications, data, users and the services they depend on before selecting a destination. The evidence includes measured demand, application and database latency, site connectivity, vendor requirements, data residency, recovery objectives and the cost of operating each option.
| System | Destination | Reason | Sequence | Owner |
|---|---|---|---|---|
| Email and calendars | Microsoft 365 | Exchange Online replaces the on-premises server | Wave 1 | IT manager |
| Project files | Microsoft 365 | SharePoint structured by project, external sharing controlled | Wave 1 | Project lead |
| Line-of-business web app | Azure | Variable demand, managed database available | Wave 2 | App owner |
| Finance system | Staged | Vendor upgrade due first, then Azure | Wave 3 | Finance lead |
| BIM and design files | Stays local | Large files need local-speed access | Retained | Design lead |
| Site systems | Stays local | Plant dependencies and limited site connectivity | Retained | Operations |
| Legacy reporting server | Retire | Duplicated by Power BI, records archived | Wave 2 | IT manager |
Move to Azure or Microsoft 365
Azure can suit variable demand, development environments, web applications and workloads that benefit from managed services. Microsoft 365 supports email and collaboration. We check the application, access and data requirements before choosing the service and its configuration.
Keep on-premises
Local infrastructure may remain the better fit for large design files, plant dependencies, latency-sensitive applications or predictable demand on serviceable hardware. We test performance and recovery requirements before changing the location, and size any refresh around what will remain.
Stage the change
An application may need to stay on its current platform until a vendor upgrade, contract change or testing window allows it to move. We document the interim architecture, operating cost and next decision date. A longer-term hybrid environment can also be the intended outcome.
Retire or replace
Duplicate applications, unused servers and obsolete services can be removed once their dependencies and records are accounted for. Replacing an application with a supported SaaS service may also be preferable to migrating its existing infrastructure.
Compare the cost of running both options
We model cloud and local costs over the same planning period, typically three to five years. Azure compute, storage, backup, data transfer, connectivity and management sit alongside local hardware, licensing, support, power, space and recovery provision. Migration, parallel running, application changes and staff time are included. Data residency is checked against the proposed service and region, including backup and replication locations.
When the current environment is holding work back
01 People need better access across offices and sites Microsoft 365 and remote access
Remote access is slow or inconsistent, or project teams struggle to work with files and applications away from the office.
Go to Microsoft 365 and remote access →02 Microsoft 365 has grown without enough structure Collaboration and project data
Teams, SharePoint sites and external sharing have expanded, while permissions, project records and data ownership have become harder to manage.
Go to Collaboration and project data →03 Some systems can move, while others need to stay Workload placement
Applications, large files or site equipment have requirements that a single destination can't accommodate.
Go to Workload placement →04 A server renewal or data centre exit sets the deadline Migration delivery
The next infrastructure investment needs to account for what will move to cloud and how long both environments will run.
Go to Migration delivery →05 Azure is live, but costs or responsibilities are unclear Managed cloud
Subscriptions, alerts, backups and spending need named owners and regular attention, including where a previous migration has stalled.
Go to Managed cloud →Build the Azure foundation and connect it to what stays local
We establish the Azure foundation around the workloads, teams and operating responsibilities it needs to accommodate, then link it to the systems staying on-premises. We work from the design areas in Microsoft's Cloud Adoption Framework, sized to the estate. An existing environment may need correction or extension; a new one needs a structure that can grow without being rebuilt.
The landing zone, built before production moves
Identity and administrative access
We configure Microsoft Entra ID, MFA, Conditional Access and role-based access around user and administrator responsibilities. Privileged Identity Management can limit standing administrative access. Domain services, service accounts and emergency access are accounted for where workloads depend on them.
Subscriptions, policy and ownership
Management groups, subscriptions and resource groups separate production, non-production and shared services as required. Naming, tags and billing ownership make resources traceable. Azure Policy applies agreed controls, with exceptions handled through the change process.
Networks and private access
We design address space, DNS, routing, firewall rules, segmentation and private endpoints around application traffic, using hub-and-spoke or Virtual WAN where they fit the estate.
Monitoring, protection and cost controls
Azure Monitor, Log Analytics and relevant Defender for Cloud controls are set up with alert owners. Backup and retention are set by workload, and Key Vault holds application secrets. Budgets and alerts are configured before usage grows. Azure budget alerts notify the responsible team; they don't stop consumption or cap the bill.
Local and cloud systems working together
Traffic paths mapped first
A cloud-hosted application may still rely on a local database, file share or domain service. We map those paths and test latency and bandwidth before splitting an application across locations.
Connectivity that matches the traffic
ExpressRoute provides private connectivity to Azure; a site-to-site VPN provides an encrypted path over the internet. We select the connection and any secondary path against traffic volumes, availability and cost, and test DNS, routing and firewalls during normal operation and link failure.
Management across cloud and retained systems
Where suitable, Azure Arc connects retained Windows and Linux servers to Azure management services. We configure the monitoring, policy and security integrations and assign responsibility for updates and incidents.
Recovery across locations
We set recovery targets for each system, then design the restore order, identity services, network access and backup separation to meet them. Azure Backup can protect supported Azure and local workloads, while Microsoft 365 protection is specified separately.
Foundation first, then migrate in waves
Identity, connectivity, policy, monitoring and backup are tested with a representative workload before the migration expands.
Choose the Azure migration path for each application
A data centre deadline, an application upgrade and a cost reduction programme can call for different approaches. We assess each application with Azure Migrate and dependency analysis, then agree the level of change with application owners and vendors before estimating the migration and committing to a cutover.
| Area | Rehost on Azure virtual machines | Replatform onto managed services | Refactor or rearchitect the application | Retain VMware through Azure VMware Solution |
|---|---|---|---|---|
| Change involved | Limited application change | Components move to services such as Azure SQL | Code changes or a different architecture | VMware workloads move with few platform changes |
| Suits | A constrained migration window | Applications compatible with managed services | Workloads that only justify the move with change | A data centre exit, as an interim or longer-term destination |
| What we check | VM sizing, disks, licensing and running cost, so inefficiencies aren't carried into Azure | Compatibility, testing, and the changed administration, availability and recovery responsibilities | Scope agreed with the application owner or development provider, with acceptance criteria | Capacity, licensing, connectivity and management cost compared with Azure VMs and retained infrastructure |
Migrate Microsoft 365 around the way people work
Email and collaboration
We plan Exchange Online, Teams and OneDrive changes around mail flow, account identities, permissions and user access. Mailbox and data batches are validated before the old services are removed.
Project information and external sharing
SharePoint sites and libraries are structured around projects, teams and records. We address file suitability, permissions, external access, retention and backup before moving shared data, and check large BIM files and application-linked data for performance and compatibility.
Remote access and devices
Azure Virtual Desktop can provide access to applications and retained systems where it suits the workload. We design the user connection, application and profile requirements alongside Entra ID access controls and Intune device management, then test the experience from the locations people use.
Migrate in waves built around application dependencies
The migration plan groups applications with their databases, files, authentication and network services. Business calendars, vendor availability and acceptable interruptions set the sequence.
Prove the destination and migration method
A representative pilot tests the foundation, tooling, application behaviour, backup and operating procedures. We record performance before and after the move and resolve defects before scheduling more critical systems.
Operate both environments during the transition
We maintain routing, DNS, authentication, permissions, certificates, monitoring and backup across old and new systems. The transition record shows what has moved, which cross-platform dependencies remain and who owns each one.
Agree the change window and limits of rollback
Each cutover has named owners, user communications, backup checks, acceptance criteria and a rollback decision point. The plan explains how to return service and reconcile data written after the move. Where a change can't be reversed directly, the recovery method and interruption are agreed before proceeding.
Validate, stabilise and close the old environment
Application owners validate transactions, access, data and performance. We verify protection on the destination, document the configuration and monitor the stabilisation period. Old systems are decommissioned once acceptance, retention and rollback requirements are met, so parallel running has a defined end.
We run the environment after the migration
Managed cloud can begin with a migration or with an Azure environment already in production. We establish the operating scope, service hours and responsibilities with your team and application providers, including the systems that remain on-premises.
Maintain performance and service continuity
We monitor availability, capacity and application symptoms, maintain agreed systems, verify backups and schedule restore tests. Alerts have an owner and an escalation path, with configuration records and recovery procedures kept current as the environment changes.
Administer access and cloud services
We manage the agreed Azure and Microsoft 365 scope, including subscriptions, identity changes, permissions, endpoint settings and platform configuration. Security responsibilities and response arrangements are documented alongside the operational work.
Explore Managed Cybersecurity →Act on cost and usage
We review actual consumption against the design, including VM sizing, idle resources, storage tiers, logging, backup retention and data transfer. Non-production schedules, eligible licensing benefits and reservations or savings plans are weighed against measured demand. Budget alerts lead to an assigned action, checked for its effect on performance and recovery.
Read our insight on FinOps cost signals and infrastructure decisions →Engineering the move and what follows it
01
Microsoft delivery across the environment
Our work connects Azure, Microsoft 365, Entra ID, Intune, networking and local infrastructure. Australis Facade's hybrid migration and VLI Conveyors' Microsoft 365 deployment show those capabilities working together in production.
02
The cost of change is part of the design
We account for migration effort, vendor work, licensing and the period when old and new systems run together. A staged approach can protect an application deadline or defer local investment, with the remaining costs and constraints recorded.
03
Security set up before users move
Identity controls, monitoring and backup are in place on the destination before the first wave, and security operations can continue under our managed security service.
See what we’ve delivered for our clients
Questions that come up before a cloud migration starts
Do we need an Azure landing zone?
If production workloads are moving to Azure, yes, in a form sized to the estate. A landing zone sets up identity, subscriptions, networking, policy, monitoring and backup before workloads arrive, so the environment can grow without being rebuilt. For a small estate it can be compact; an existing Azure environment can often be corrected and kept.
Will cloud cost more than what we run now?
It can. Steady workloads on serviceable infrastructure may cost less locally, while other systems benefit from elastic capacity or managed services. We compare equivalent operating and recovery requirements, including migration and parallel running. Cost management stays necessary after deployment and won't by itself make the cloud cheaper.
Is ExpressRoute necessary, or is a VPN enough?
A site-to-site VPN suits many organisations, particularly where traffic to Azure is moderate. ExpressRoute provides a private connection with more predictable performance, at a higher cost. We size the choice against traffic volumes, latency-sensitive applications and how much interruption a link failure would cause, and can add a secondary path for resilience.
Azure VMware Solution or Azure virtual machines?
Azure VMware Solution runs your VMware environment in Azure with few platform changes, which can speed up a data centre exit, but VMware licensing stays part of the cost. Azure virtual machines remove the VMware layer and give more sizing flexibility, but each workload is converted. We compare both against the timeline, application support and running cost.
Can you work with an Azure environment that is already live?
Yes. We review its configuration, access, network paths, monitoring, backup and spend, then prioritise corrections around the systems in production. Existing subscriptions and services can often be retained while the foundation and operating arrangements are improved.
How much disruption should we expect?
It depends on the workload, the migration method and how current data must remain during the change. We identify expected outages and user changes during planning, test the method and agree cutover windows with application owners. The plan records the rollback limits and recovery arrangements for each wave.
Can a VMware renewal or hardware refresh be part of the same project?
Yes. We align the migration sequence with renewal dates, host capacity and the local systems that will remain. A smaller VM estate only reduces VMware licensing costs if the licensed capacity and commercial terms change, so the renewal and refresh decisions are made alongside the cloud plan.
Who looks after the environment after migration?
We can, under a managed cloud agreement that sets out monitoring, patching, access, backup, cost reviews and vendor escalation. Responsibilities shared with your team or application providers are documented, and support is raised and tracked in Microsoft Teams.
Plan the move and what runs after it
Bring us the application list, infrastructure deadline or cloud issue driving the work. We'll establish what needs to change and plan the migration and ongoing operation around your business.