Move the right workloads to cloud, then manage them properly
A migration is not finished when workloads are online — the environment still needs identity, backup, monitoring, security, cost control and support ownership. Inlight IT decides what should move and what stays local, builds the foundation first, and operates the environment after cutover.
- Workload fit before cloud enthusiasm
- Foundation first, then migrate in waves
- Operated after cutover, not handed back live
Access, Microsoft 365 sprawl, cloud cost and ageing infrastructure often point to the same decision.
Most organisations arrive here because the current way of working has become harder to support. Select a situation to see what is usually behind it.
Place each workload on its merits, not all-or-nothing.
Some workloads move to Azure or Microsoft 365, some stay local, some move later, some should be retired or replaced first. The assessment weighs performance, access, cost, recovery, dependency and support model, workload by workload. The illustrative placement below shows the pattern, not a fixed rule.
Build the foundation before scaling usage.
Moving workloads is only the visible part of the work. The part that determines whether it succeeds is everything around it, and it is the part rushed migrations skip. Get this right and everything after it is easier; skip it and the business inherits a cloud environment harder to manage than what it replaced.
Migrate in waves, with a rollback path at every gate.
Identity, collaboration, project data, remote access and workloads move in the right order, with cutover windows, rollback paths, validation and user communication built into the plan rather than improvised.
Understand the environment, decide what moves, build the foundation, then migrate and operate.
The safest migrations start with the current environment, not the destination platform.
Users, sites, applications, Microsoft 365, identity, files, remote access, backup, security controls, devices and retained infrastructure, reviewed before the path is set.
Workloads assessed by performance, access, cost, recovery, dependency and support model. Some move, some stay local, some move later, some are retired or replaced first.
Entra ID, Conditional Access, MFA, Intune, landing zone, connectivity, subscription structure, backup, monitoring, Defender and cost controls, before production change.
Identity, collaboration, project data and workloads in the right order, with rollback paths, validation and user communication built in.
After cutover the environment is monitored, patched, backed up, cost-reviewed, documented and owned. The goal is a better operating model, not just a completed migration.
Recent cloud and migration work
Four migrations where the right answer was decided workload by workload rather than all-in.
A migration can be technically complete and still fail the business.
The technical destination matters, but the operating model matters more, and that is where most migrations come unstuck. We start with workload fit rather than cloud enthusiasm.
01Workload fit over cloud enthusiasm
The right answer is usually a hybrid model built around performance, access, cost and recovery, and we will say so even when "move it all" would be the bigger engagement. We start with the workload, not the platform.
02Connected to the whole environment
We connect Azure and Microsoft 365 to identity, backup, endpoint management, security, networking and retained infrastructure, because cloud does not operate in isolation from the rest of the environment.
03Governance and support built into the migration
A migration is not finished when workloads are online. It is finished when the environment is secure, recoverable, documented, monitored and genuinely owned, and we build that in rather than bolt it on after.
04Operated after cutover
Inlight IT supports Azure and Microsoft cloud environments after cutover: Azure monitoring, Microsoft 365 administration, Entra ID, Conditional Access, Intune, Microsoft Defender, Azure Backup, cost governance and ongoing support across both retained local and cloud workloads.
Questions that come up before a cloud migration starts.
Should we move everything to Azure?
Usually not. Not everything belongs in Azure. Large files, design data, finance systems and latency-sensitive workloads may still need local performance. The goal is to place each workload where it performs, recovers and operates best, which is usually a hybrid model, not an all-in move.
What does "build the foundation first" actually mean?
Identity, access, security and cost controls come first: Entra ID, Conditional Access, MFA, Intune, an Azure landing zone, network connectivity, subscription structure, backup, monitoring and Microsoft Defender. Skip these and you inherit an environment that is harder to run than the one you left.
Is Microsoft 365 part of this?
Yes. We treat Microsoft 365 as an operating environment, not storage. Permissions, site structure, external sharing, retention, device compliance and backup are designed around how the business actually works, so collaboration improves instead of sprawling.
How is the migration sequenced?
In waves: identity, collaboration, project data, remote access and workloads move in the right order, with cutover windows, rollback paths, validation and user communication built into the plan rather than improvised. A wave is not signed off until it is validated against real access, data and users.
What happens after the migration is done?
This is the part project-only migrations underweight. The environment still needs monitoring, patching, backup verification, identity changes, security review, cost management, documentation, escalation and lifecycle planning. Inlight IT operates Azure and Microsoft cloud environments after cutover across both retained local and cloud workloads.
How does this relate to Infrastructure Refresh?
They meet where a server or data centre decision forces the cloud question. If infrastructure spend is coming anyway, it is the right moment to ask which workloads should move to Azure instead of being refreshed locally. The Infrastructure Refresh pathway covers the platform decision when workloads stay on-premises.
Will cloud cost more than what we run now?
Not if it is governed. Cloud cost is something the business should be able to see, govern and optimise before it drifts. Cost controls are part of the foundation, and cost review is part of operating the environment after migration, not an afterthought once the bill arrives.