Most organisations begin cloud migration with the wrong conversation. They start with virtual machines, network topology, backup tooling, regions and migration utilities before anyone has made the business objective specific. Is the goal to reduce datacentre cost, improve resilience, accelerate delivery, reduce operational risk, strengthen security, or create a better platform for modernisation? If the answer is all of the above, the strategy is probably still too vague to guide real decisions.
That is why so many migration programmes run long and lose credibility. The technology is usually not the limiting factor. Azure can host almost any workload pattern a mid-sized organisation is likely to have. The real problems are usually scope drift, hidden dependencies, unrealistic cutover expectations and governance that is treated as something to sort out after go-live.
A good cloud migration strategy is therefore not just a technical plan. It is a decision framework that connects business goals, platform design, sequencing, risk, governance and operational ownership. Microsoft’s Cloud Adoption Framework is useful precisely because it forces that sequence: strategy, plan, readiness, migration and governance, rather than a rushed jump straight into moving servers.
Start with business outcomes, not with the server estate
If the business outcome is unclear, every downstream decision becomes fuzzy. Which systems go first? How much downtime is acceptable? How much standardisation is realistic? When should you rehost versus replace? What is the right trade-off between speed, risk and modernisation?
A migration strategy should define at least four business-level outcomes:
- What the organisation expects the migration to achieve in the next 12-24 months
- Which platforms, contracts or datacentre dependencies it is trying to retire
- Which risks it is trying to reduce, such as unsupported infrastructure, resilience gaps or compliance exposure
- How success will be measured in practice, such as cost reduction, improved recovery objectives, faster provisioning or fewer security exceptions
This matters more than many teams admit. If an ERP platform is business-critical and stable, but there is no appetite to redesign it this year, a controlled rehost may be the right answer. If a legacy intranet is due to be retired anyway, migrating it to Azure may simply create extra cost and work for no strategic gain.
The CAF migration methodology is practical here because it separates strategic intent from technical execution. That discipline is often missing in migration projects that are launched as infrastructure work and only later discover they are actually transformation programmes.
Define scope early and be explicit about what is not included
A migration strategy without scope is just ambition. Early in the programme, you need a clear view of which applications, databases, integrations and environments are actually in scope for the first planning horizon.
That usually means three separate decisions.
First, classify the estate by business criticality. Which services genuinely stop the business if they fail? Which are important but can tolerate a service window? Which can move later with little consequence? Which should not move at all because they are being replaced?
Second, decide the likely migration path for each workload. Not everything should be lifted and shifted. Some systems should be retired. Some should be replaced by SaaS. Some should be replatformed. Some should stay on-prem for a period because of vendor constraints, data sovereignty considerations or dependency complexity.
Third, capture the constraints explicitly. That includes items such as:
- Hardware, software or hosting contracts that are still active
- Compliance and data residency requirements
- Legacy applications with unclear ownership
- Business units that can only accept very small outage windows
- Third-party integrations that cannot be changed quickly
This is where Azure Migrate becomes valuable. Not because the tool creates the strategy for you, but because it gives you a more honest inventory of the environment: server discovery, performance data, dependency insight and Azure suitability assessments. In many organisations, that is the first time the team sees the estate as it really is rather than as it exists in outdated documentation.
Build the landing zone before the first production move
One of the most expensive migration mistakes is using production workloads as the design phase for the cloud platform. It feels fast at the start, but it usually creates months of rework afterwards.
Before the first workload moves, there should be a landing zone in place. Microsoft’s guidance on Azure landing zones covers the full model, but even a pragmatic version should include:
- A management group and subscription structure that separates platform, production, non-production and sandbox usage where relevant
- Identity and access patterns with least privilege and clear administrative boundaries
- Network design, segmentation and connectivity back to on-premises where required
- Central logging, diagnostics and monitoring
- Backup and recovery baselines
- Policy controls for tags, allowed regions, allowed resource types and security settings
That is where Azure Policy and management groups stop being abstract governance topics and become practical migration tools. Without them, every team makes local decisions and the environment starts diverging immediately: inconsistent naming, inconsistent networking, inconsistent logging, inconsistent security defaults.
The landing zone does not need to be perfect from day one. It does need to be good enough that every new workload lands inside a structure the organisation can operate, secure and govern over time.
Dependency mapping should drive migration waves
A surprising number of migration plans are still organised around what looks easiest to move. That is understandable, but it is usually the wrong organising principle. The right principle is dependency.
If an application talks to a database, file share, identity service and two internal APIs, it is not a standalone workload just because it happens to run on one VM. Move it without its dependencies and you create an expensive hybrid state: more latency, more firewall complexity, more routing issues and much harder troubleshooting.
This is exactly why Azure Migrate should be used early in the programme. Discovery and assessment do not just provide inventory; they help expose dependency patterns so you can group workloads into sensible migration waves.
Useful sequencing questions include:
- Which workloads are independent enough to form a realistic pilot wave?
- Which applications must move together to avoid unacceptable latency or brittle temporary integration?
- Which shared services need to exist first, such as identity, networking, monitoring and backup?
- Which workloads should move late because risk is high or because replacement is already planned?
That also means the first wave should rarely be the most critical system in the company. But it should not be trivial either. A good pilot needs enough real complexity to validate the landing zone, support model, monitoring, security controls and change process under realistic conditions.
Choose migration patterns deliberately, not by habit
A strategy is not finished until it explains how different workload types will be treated. There is a substantial difference between migrating a file server, a line-of-business application, a SQL platform and an integration layer.
In practice, most migration portfolios are some mix of the following patterns:
- Retire: the system is removed rather than migrated
- Replace: capability moves to SaaS or a different standard platform
- Rehost: the workload is moved largely as-is
- Replatform: selected components are modernised during migration
The mistake is assuming every workload should follow the same path. Lift-and-shift is often the correct decision for a first wave because it reduces application change. It is a poor default for an entire estate. On the other side, full modernisation looks attractive in slide decks but is often too slow and too disruptive to be the universal pattern.
A pragmatic strategy accepts mixed paths. Move what genuinely needs to leave the datacentre. Replace what no longer deserves investment. Modernise where the business case is real and where the organisation has the time, budget and ownership to absorb the change.
Plan cutover, testing and rollback before the date is fixed
Cutover day gets too much attention and too little preparation in many migration projects. A good cutover is the outcome of many small decisions made early: replication method, validation criteria, communications, fallback triggers and role clarity in the first hours after go-live.
For VM-based workloads, Azure Site Recovery is often relevant because it provides replication, test failover and planned cutover patterns. It does not remove the need for coordination, but it is far more robust than manual migration weekends driven by spreadsheets and optimism.
A mature cutover plan should define at minimum:
- The exact success criteria required before users are allowed onto the migrated service
- The integration, data validation and performance checks that must pass
- Who owns the final go or no-go decision
- What rollback looks like and when it will be triggered
- Which business and technical stakeholders must be available during the change window
- How DNS, certificates, routing and access changes will be handled
This is also where teams often underestimate the human side of migration. Cutover is not just a technical event. It is an orchestrated business change. If the application owner, service desk, network team and operations lead are not following the same plan, even a technically successful move can feel chaotic to the organisation.
Governance is not phase two
One of the most expensive outcomes of a weak migration is not the move itself but the debt that appears afterwards. When governance is deferred, the environment quickly accumulates cost growth, unclear ownership, inconsistent deployments and security drift.
That is why governance must be part of the strategy from the start. In practical terms, that usually means:
- A tagging standard for environment, owner, cost centre and application
- Budgets and alerts in Azure Cost Management
- Clear RBAC boundaries for platform, operations, engineering and suppliers
- Infrastructure as Code requirements for future platform changes
- A review cadence for policy drift, security recommendations and cost anomalies
Microsoft’s guidance on Azure Policy and cost management best practices is not just about day-two operations. It is part of the original migration business case. If cloud spend becomes opaque and ungoverned six months after go-live, the migration has not delivered the control the organisation believed it was buying.
The migration mistakes we see repeatedly
Most cloud migrations do not fail in dramatic ways. They drift off course in predictable ones. The patterns are familiar:
- The team starts with workloads that are easy to move but do not teach anything useful
- Landing zone and governance work are deferred to save time early on
- Dependencies are discovered during testing or after go-live instead of during planning
- The hybrid state lasts far longer and becomes far messier than expected
- There is no clear owner for each application and each cutover decision
- No one actively decides what should be retired instead of migrated
Each issue looks manageable in isolation. Together they make the programme slower, more expensive and much harder on the people involved.
A pragmatic phased strategy
For most mid-sized organisations, migration works best as a phased programme rather than one giant project plan.
Phase 1: Discovery and business case Spend the first 2-6 weeks on inventory, dependencies, business interviews, criticality mapping and baseline assessment with Azure Migrate. Decide what is actually in scope.
Phase 2: Landing zone and operating model Build the platform foundation before moving production workloads. Resolve identity, network, policy, logging, backup and ownership.
Phase 3: Pilot and first wave Migrate a limited but meaningful set of workloads that is representative enough to validate support, security, cutover and operational readiness without putting the entire programme at risk.
Phase 4: Sequenced migration waves Group workloads by dependency and business criticality. Use the pilot lessons to tighten runbooks, security controls, estimates and stakeholder communication.
Phase 5: Optimisation and decommissioning After migration waves complete, do the work many teams forget: rightsizing, reservations, clean-up of temporary hybrid connections, retirement of old infrastructure and tighter governance.
It is rarely the fastest route in a presentation. It is very often the route that actually finishes cleanly.
What this means for your business
A realistic cloud migration strategy is not about moving everything as fast as possible. It is about moving the right things, in the right order, onto a platform your organisation can actually run afterwards.
If your current migration conversation is mainly a technical relocation exercise, that is usually a sign the strategy needs work. Scope, landing zone, dependency mapping, cutover model and governance should be explicit before the first critical workload is live in cloud.
At inciro, we help organisations turn that strategy into an executable Microsoft Cloud migration programme so that decisions are driven by business outcomes rather than by whatever happens to be easiest to move first.
Book a strategic conversation — we will review your current environment and outline a realistic migration strategy with clear phases, priorities and risks.