Cloud migration is often described as an infrastructure project.
Assess the servers. Build the Azure environment. Replicate the workloads. Schedule a cutover. Validate the applications.
In practice, however, the technical movement of workloads is only one part of a successful migration.
Organizations frequently discover that the most difficult questions arise before the first workload is moved:
What should we migrate first?
Should this application remain on virtual machines or be modernized?
Is the Azure environment ready to receive production workloads?
How much downtime can the business tolerate?
And who will secure, monitor and optimize the environment after migration?
At BPS, we believe successful Azure migrations are determined less by the act of moving virtual machines and more by the decisions made around the migration.
Here are five decisions we believe every organization should address before moving business-critical workloads to Microsoft Azure.
Decision 1: What Should Actually Move to Azure?
The first migration decision should not be:
“How do we migrate all our servers?”
It should be:
“Which workloads should move, and what should happen to each one?”
An infrastructure estate that has accumulated over many years rarely consists entirely of workloads that should be reproduced in Azure.
An assessment might uncover:
- Business-critical production applications
- Underutilized servers
- Development and testing environments
- Legacy operating systems
- Applications scheduled for retirement
- Duplicate services
- Databases that could move to managed services
- Web applications suitable for platform services
- Systems that must temporarily remain on-premises
- Applications with complex dependencies
For that reason, discovery and assessment should precede migration design.
Azure Migrate documentation describes Azure Migrate as a hub for discovering, assessing and migrating on-premises environments. It includes capabilities for server assessment, application inventory, business cases and assessment of workloads such as ASP.NET web applications and SQL environments. [learn.microsoft.com]
The assessment should help build a workload portfolio rather than simply produce an inventory.
For each workload, organizations should consider a transformation path such as:
Retain: Keep the workload in its existing environment for now.
Retire: Decommission applications or infrastructure that no longer provide sufficient business value.
Rehost: Move the workload primarily as it exists today, for example from VMware or Hyper-V to Azure Virtual Machines.
Replatform: Move portions of the workload to managed Azure platforms such as Azure App Service or Azure SQL.
Refactor or modernize: Make more significant architectural changes to take advantage of cloud-native services.
The important lesson is straightforward:
Not everything that can be migrated should be migrated in the same way.
Decision 2: Are We Migrating Into Azure, or Into a Properly Governed Azure Environment?
This distinction is critical.
It is technically possible to create an Azure subscription, configure a virtual network and begin deploying resources very quickly.
That does not mean the environment is ready for large-scale production migration.
Before production workloads arrive, organizations should establish an architecture covering areas such as:
- Microsoft Entra ID and identity
- Management groups
- Subscriptions
- Azure Policy
- Role-based access control
- Network architecture
- Hybrid connectivity
- DNS
- Logging and monitoring
- Security
- Backup and recovery
- Resource organization
- Tagging
- Cost management
- Operational ownership
This is the role of an Azure landing zone.
Microsoft defines a platform landing zone as providing foundational Azure capabilities such as resource organization, governance, identity, networking and management. [learn.microsoft.com]
Enterprise organizations may separate shared platform capabilities from workload environments. Microsoft’s Azure architecture guidance distinguishes between a platform landing zone, which provides centralized services, and workload landing zones, where individual workloads are deployed. [learn.microsoft.com]
Why does this matter?
Imagine migrating 100 servers into Azure first and addressing governance several months later.
The organization may subsequently discover:
- Inconsistent naming and tagging
- Excessive administrative permissions
- Missing security controls
- Unstructured subscriptions
- Inconsistent logging
- Poor network segmentation
- No standardized backup configuration
- Limited cost visibility
- No clear ownership boundaries
Correcting those problems while production applications are already running can be significantly more difficult than designing the foundation correctly at the beginning.
Our recommendation is therefore:
Build the cloud foundation before accelerating the workload migration.
Decision 3: How Will Azure Connect to the Existing Environment?
Most enterprise migrations do not happen overnight.
For weeks or months, and sometimes much longer, applications may operate across two environments:
On-premises + Azure
That makes connectivity one of the most important migration design decisions.
Depending on the requirements, organizations may evaluate options such as:
- Azure VPN Gateway
- Azure ExpressRoute
- Hub-and-spoke networking
- Azure Virtual WAN
- Network Virtual Appliances
- Azure Firewall
- Private endpoints
- Hybrid DNS architectures
Microsoft’s migration guidance for landing zones specifically identifies hybrid connectivity, identity, DNS, routing, firewall configuration, monitoring and Microsoft Defender for Cloud among the areas organizations should prepare before migration. [learn.microsoft.com]
The architecture needs to consider more than bandwidth.
Teams should ask:
Which applications communicate with each other?
Moving an application server to Azure while leaving a latency-sensitive database on-premises may introduce application-performance problems.
Where will DNS resolution happen?
Hybrid DNS is easy to overlook until an Azure workload cannot resolve an on-premises dependency or vice versa.
What traffic requires inspection?
Security policies may require centralized traffic inspection or specific routing through Azure Firewall or another approved security appliance.
Is the migration connection temporary?
The optimal networking design for bulk migration traffic may differ from the long-term production architecture.
What happens if connectivity fails?
If production applications will continue to depend on on-premises services, network-resilience requirements must be understood before migration.
Connectivity should therefore be designed around application dependencies and business requirements, not simply around IP addressing.
Decision 4: What Is the Migration Unit?
One of the easiest mistakes during migration planning is treating a server as the unit of migration.
Applications rarely operate as isolated servers.
A business application might rely on:
Web server → Application server → Database → File share → Active Directory → DNS → External API
Moving only one component without understanding the relationships between them can create unexpected outages or performance problems.
This is why dependency analysis is so important.
Before defining migration waves, organizations should identify:
- Application components
- Database dependencies
- Identity dependencies
- Network connections
- File shares
- Integration services
- External services
- APIs
- Scheduled jobs
- Monitoring systems
- Backup requirements
- Security controls
- Business owners
Migration groups should then be designed around workloads and dependencies rather than arbitrary sets of virtual machines.
Consider this example.
An organization has identified 200 virtual machines for migration.
Instead of moving 20 servers at a time based on infrastructure characteristics, the organization may discover that those servers support 35 business applications.
Those 35 applications become more meaningful planning units.
They can then be grouped into migration waves according to:
- Business criticality
- Technical complexity
- Dependencies
- Downtime tolerance
- Application owners
- Target architecture
- Migration readiness
This changes the migration conversation from:
“Which servers are moving this weekend?”
to:
“Which business service are we moving, and what does that service require to operate successfully?”
That is a much more useful question.
Decision 5: What Happens the Day After Migration?
The migration is complete.
The applications are running.
Users can connect.
The project team celebrates.
Now what?
This is where cloud migration transitions into cloud operations.
Production workloads in Azure still require continuous attention to areas such as:
- Monitoring
- Security
- Vulnerability management
- Backup
- Disaster recovery
- Patching
- Performance
- Capacity
- Availability
- Cost optimization
- Governance
- Compliance
- Incident management
Another important question also appears:
Who owns each responsibility?
For example:
| Area | Ownership must be defined |
| Azure platform | Who manages the cloud foundation? |
| Application | Who owns application health? |
| Security | Who reviews security recommendations and incidents? |
| Backup | Who validates backup success and recovery? |
| Monitoring | Who receives and responds to alerts? |
| Cost | Who reviews consumption and optimization opportunities? |
| Governance | Who maintains Azure Policy and standards? |
| DR | Who conducts recovery tests? |
These responsibilities should ideally be established before migration, not after an incident occurs.
This is also where working with an Azure managed services provider can provide value.
Migration should transition into a structured operating model for the cloud environment.
A Practical Way to Structure Migration Waves
At BPS, we recommend avoiding a “big bang” migration unless there is a compelling technical or business requirement.
A phased approach generally provides a better opportunity to validate designs and incorporate lessons learned.
A typical migration program might look like this:
Phase 1: Discover and Assess
Build the workload inventory.
Identify dependencies, utilization, business criticality, migration readiness and potential modernization opportunities.
Phase 2: Prepare the Azure Foundation
Establish the Azure landing zone.
Configure identity, governance, network connectivity, security, monitoring, backup and operational standards.
Phase 3: Pilot
Select a small number of representative, lower-risk workloads.
The purpose is not merely to prove that workloads can run in Azure.
The pilot should validate:
- Migration procedures
- Connectivity
- Security
- Monitoring
- Backup
- Performance
- Operational handover
- Rollback procedures
Phase 4: Migration Waves
Group applications according to dependencies and business requirements.
Execute the migration using repeatable processes and defined acceptance criteria.
Phase 5: Modernize
Once immediate migration objectives are addressed, evaluate workloads where services such as Azure App Service, Azure SQL, Azure Kubernetes Service or other cloud-native technologies can provide measurable benefits.
Importantly, modernization does not necessarily need to happen at the same time as migration.
Microsoft provides an example where an organization initially uses lift-and-shift to accelerate its datacenter migration, while planning to modernize applications using technologies such as Azure SQL Database and Azure Kubernetes Service over time.
That can be a pragmatic strategy when there is a hard datacenter-exit deadline.
Phase 6: Operate and Optimize
After migration, continuously evaluate:
Security → Resilience → Performance → Cost → Governance
Cloud transformation does not end at cutover.
Migration Success Should Be Measured Beyond “Servers Moved”
Suppose an IT team successfully migrates 150 virtual machines to Azure.
Was the migration successful?
Technically, perhaps.
From a business perspective, additional questions matter:
- Were business applications disrupted?
- Did application performance remain acceptable?
- Were security controls improved?
- Are backups monitored and recoverable?
- Can critical services meet their recovery objectives?
- Has technical debt been reduced?
- Can cloud consumption be understood and controlled?
- Are operations more automated?
- Are teams able to respond to incidents effectively?
- Did the migration create a platform capable of supporting future growth?
A successful cloud migration should improve the organization’s ability to operate, not simply change where infrastructure is hosted.
Where BPS Fits
BPS helps customers and partners approach Azure migration as a controlled transformation rather than simply a movement of infrastructure.
The BPS migration lifecycle is built around four principles:
Assess Before Migrating
Understand applications, infrastructure, dependencies, business requirements and migration readiness.
Establish the Foundation
Prepare an Azure environment designed for security, governance, connectivity and operations.
Migrate in Controlled Waves
Move workloads according to application dependencies and business priorities, with clear testing, validation and rollback planning.
Operate and Optimize Continuously
After migration, manage security, monitoring, business continuity, governance, performance and cloud costs as ongoing disciplines.
This approach connects migration with the broader lifecycle of an Azure managed environment.
Five Questions to Take to Your Next Migration Meeting
If your organization is preparing an Azure migration, start the next planning meeting with these five questions:
1. Which workloads should actually move to Azure, and which should be retained, retired or modernized?
2. Is our Azure landing zone ready to host production workloads securely and at scale?
3. Do we understand the network, identity, database and application dependencies of every workload?
4. How will we group applications into migration waves, test them and recover if a cutover fails?
5. Who will secure, monitor, protect, govern and optimize the workloads after migration?
If the project team cannot confidently answer those questions, moving more workloads faster may increase migration risk rather than reduce it.
Final Thoughts
Azure provides powerful technology for discovering, assessing, migrating and modernizing workloads.
But technology alone does not create a successful migration.
The most successful cloud migrations combine:
Business priorities + Application understanding + Cloud architecture + Security + Governance + Operational readiness
The ultimate objective should not be to say:
“We moved our servers to Azure.”
It should be to say:
“We created a secure, resilient and manageable cloud platform that can support the next stage of our business.”
That is the difference between completing a migration project and building a sustainable cloud operating model.
