Moving applications to the cloud is no longer the end goal.
For many organizations, the real question is not “How do we move this application to Azure?” but rather:
“How do we use the move to Azure as an opportunity to make the application more scalable, secure, resilient, and easier to operate?”
At BPS, we believe successful cloud transformation requires looking beyond infrastructure migration. Moving a virtual machine from an on-premises datacenter to Microsoft Azure can deliver immediate benefits, but the greatest long-term value often comes from modernizing the application and its operating model.
Microsoft’s Cloud Adoption Framework reflects this broader lifecycle. It covers strategy, planning, Azure landing zones, migration, modernization, governance, security and ongoing management rather than treating migration as an isolated technical exercise.
This article explores how organizations can approach application migration and modernization pragmatically, while avoiding the common mistake of assuming that every workload should follow the same modernization path.
Migration and Modernization Are Not the Same Thing
The terms migration and modernization are often used together, but they solve different problems.
Migration focuses primarily on moving an existing workload from one environment to another.
For example:
On-premises virtual machine → Azure Virtual Machine
The application may remain largely unchanged, but the infrastructure hosting it changes.
Modernization, on the other hand, focuses on improving how the workload is built, deployed, scaled, secured and operated.
For example:
Legacy web application → Azure App Service
or:
Traditional application → Containerized application running on Azure Kubernetes Service (AKS)
Microsoft describes modernization as improving how a workload meets its requirements by expanding its capabilities or making it more efficient to maintain and evolve. Importantly, modernization does not always require a complete rewrite. It can range from targeted improvements to significant architectural changes.
That distinction matters.
A successful Azure strategy should not automatically aim to modernize everything, nor should it simply lift and shift everything.
The goal should be to select the appropriate transformation path for each workload.
Start With the Application, Not the Azure Service
One of the biggest mistakes organizations can make during a cloud transformation is starting with a technology decision.
For example:
“We want to move everything to Kubernetes.”
A better starting point is:
“What does this application need to achieve for the business over the next three to five years?”
Before selecting an Azure architecture, organizations should understand:
- Application architecture
- Business criticality
- Current performance
- Availability requirements
- Recovery requirements
- Operating system dependencies
- Database dependencies
- Network dependencies
- Identity and authentication requirements
- Security and compliance requirements
- Application lifecycle
- Current operational effort
- Scalability requirements
- Technical debt
- Cost of maintaining the existing platform
Only after understanding these factors should the target Azure architecture be selected.
Microsoft’s migration guidance similarly recommends assessing migration readiness, determining the migration sequence and selecting an appropriate migration method for each workload rather than applying one migration method across the entire application portfolio.
A Practical Modernization Decision Framework
At BPS, we recommend viewing workloads through several possible transformation paths.
- Rehost
A rehost approach moves the application with minimal changes.
A typical example would be:
VMware / Hyper-V VM → Azure Virtual Machine
This approach may be appropriate when:
- Speed of migration is critical
- The application cannot easily be modified
- There is limited access to the application source code
- The application relies heavily on the operating system
- A datacenter exit deadline must be met
- Modernization will happen in a later phase
Rehosting can be an excellent first step.
The mistake is assuming it should always be the last step.
- Replatform
Replatforming moves the application while replacing some infrastructure components with managed Azure services.
Consider a traditional application consisting of:
Web Server + Application Server + SQL Server
Instead of recreating all three layers as Azure VMs, the organization could potentially move toward:
Azure App Service + Azure SQL Database
This changes the operational model.
Rather than managing operating systems, patching servers and maintaining underlying infrastructure for every layer, IT teams can increasingly focus on application availability, performance, security and business functionality.
Microsoft specifically identifies Azure App Service as a modernization destination for existing web applications and provides migration paths for ASP.NET and Java workloads.
For many organizations, this is where cloud migration begins delivering benefits that go beyond simply changing the location of servers.
- Containerize
Some applications benefit from being packaged as containers and deployed using platforms such as:
Azure Kubernetes Service (AKS)
Containerization can provide advantages for applications that need:
- Portability
- Independent scaling
- Modern CI/CD deployment
- Microservices architectures
- Consistent deployment environments
- Advanced orchestration
But Kubernetes should not be regarded as the automatic destination for every application.
AKS introduces a different operational model and requires appropriate skills, monitoring, governance and application architecture.
Microsoft’s AKS migration guidance recommends assessing applications carefully and testing them before migration. Azure Migrate can also help organizations containerize certain ASP.NET and Java workloads as part of migration to AKS.
For legacy applications specifically, dependency mapping is particularly important. Applications can depend on databases, file shares, SMTP services, Active Directory/LDAP, external APIs, networking configurations, operating-system components or even hardware integrations. These dependencies can significantly affect whether an application is ready for containerization.
The key principle is simple:
Do not adopt containers because they are modern. Adopt them when they solve an application or operational problem.
- Refactor
Some applications require deeper architectural changes.
A monolithic application, for example, could gradually be redesigned to make greater use of cloud-native services such as:
- Azure Functions
- Azure Container Apps
- Azure Kubernetes Service
- Azure SQL Database
- Azure Cosmos DB
- Azure API Management
- Azure Service Bus
- Azure Key Vault
- Managed identities
This can provide substantial benefits, but it also requires greater investment and application-development involvement.
Microsoft’s current modernization guidance identifies application platforms, databases, security, data and application code among the areas organizations can modernize, with potential target services including Azure App Service, Azure Container Apps, AKS and Azure Functions.
Refactoring should therefore have a business justification.
If an application will be retired in 18 months, investing heavily in refactoring may make little sense.
If the same application is a strategic platform expected to support the organization for the next decade, the calculation can be entirely different.
Modernization Should Be Selective, Not Ideological
Imagine an organization running 100 workloads.
A successful Azure modernization program might result in:
- Some applications being retired
- Some remaining temporarily on-premises
- Some applications being rehosted on Azure VMs
- Some being replatformed to Azure App Service
- Some databases moving to Azure SQL
- Some applications being containerized
- A smaller number being substantially refactored
That is not a failure to standardize.
It can actually be the sign of a well-designed cloud strategy.
The objective is not to use the newest Azure service everywhere.
The objective is to match the architecture to the application’s business, technical, security and operational requirements.
The Azure Landing Zone Comes Before the Workload
Another common migration mistake is focusing exclusively on the workload.
Before large-scale migration begins, organizations need the Azure foundation that will support those applications.
This is where the Azure landing zone becomes important.
A well-designed landing zone establishes the foundation for areas such as:
- Identity
- Subscription organization
- Resource organization
- Networking
- Connectivity
- Security
- Governance
- Policies
- Monitoring
- Management
- Business continuity
- Cost management
Microsoft’s Cloud Adoption Framework explicitly places landing-zone readiness before migration and modernization within the broader cloud adoption lifecycle.
Without this foundation, organizations can successfully migrate applications while simultaneously creating a new governance problem in the cloud.
In other words:
Moving technical debt to Azure does not eliminate technical debt.
Security Must Be Designed Into the Migration
Security should not be something added after applications have been migrated.
Modernization creates an opportunity to reassess how applications interact with:
- Users
- Administrators
- Databases
- APIs
- Secrets
- Certificates
- Networks
- Internet-facing endpoints
- Other applications
Azure provides services that can help organizations build security into the target architecture, including:
- Microsoft Defender for Cloud
- Microsoft Entra ID
- Azure Key Vault
- Managed identities
- Azure Policy
- Network security controls
- Azure Web Application Firewall
- Azure Monitor
For example, an application storing database passwords in configuration files could potentially be redesigned to use Azure Key Vault and managed identities.
This is an example of modernization that may not dramatically change what the end user sees, but can significantly improve the application’s security posture and operational model.
Don’t Forget the Database
Application modernization conversations often focus heavily on compute.
However, the database can determine whether the application truly benefits from the cloud.
An application migrated to Azure VMs while its database remains dependent on manually maintained infrastructure may retain significant operational overhead.
Depending on application compatibility and requirements, organizations can evaluate services such as:
- SQL Server on Azure Virtual Machines
- Azure SQL Managed Instance
- Azure SQL Database
- Azure Database for PostgreSQL
- Azure Cosmos DB
The correct choice depends on compatibility, application architecture, availability, scale, feature requirements and the degree of modernization the organization is prepared to undertake.
Microsoft’s modernization framework specifically identifies databases as a major modernization category, including movement from traditional database platforms toward managed Azure database services where appropriate.
Think About Day Two Before Day One
Perhaps the most important question in any migration is:
What happens after the migration team leaves?
A workload is not successful merely because it starts running in Azure.
Someone still needs to consider:
- Monitoring
- Alerting
- Security posture
- Backup
- Disaster recovery
- Patching
- Vulnerability management
- Availability
- Performance
- Capacity
- Governance
- Cost
- Incident response
- Continuous optimization
That is why BPS views migration and modernization as part of a broader managed cloud lifecycle.
A mature cloud operating model should continuously answer questions such as:
- Is the workload healthy?
- Is it secure?
- Is it protected?
- Is it compliant?
- Is it performing as expected?
- Are we spending more than necessary?
- Can we recover it if something goes wrong?
Cloud modernization therefore should not end at migration.
The BPS Approach: Assess, Migrate, Modernize and Operate
BPS helps organizations and our partner ecosystem approach Azure transformation as a lifecycle rather than a one-time infrastructure project.
Our approach is centered around four stages:
Assess
Understand the current environment, application dependencies, infrastructure, business requirements, security requirements, cost drivers and modernization opportunities.
Azure Migrate and Microsoft’s Cloud Adoption Framework can provide important inputs into this assessment and planning process.
Migrate
Build the appropriate Azure foundation and migrate workloads using the migration method best suited to each application.
This can range from rehosting workloads on Azure Virtual Machines to moving applications toward managed Azure platforms.
Modernize
Identify where cloud-native and managed Azure services can reduce operational complexity, strengthen security, improve scalability or accelerate innovation.
The important principle is that modernization should be workload-driven and business-driven, not technology-driven.
Operate and Optimize
Monitor the environment after migration and continuously improve security, resilience, performance, governance and cost.
This converts migration from a project into an ongoing cloud operating model.
Five Questions Every Organization Should Ask Before Migrating an Application
Before moving the next workload to Azure, ask:
- Why are we migrating this application?
Is the objective cost reduction, datacenter exit, security, resilience, scalability, modernization, application innovation or a combination of these?
- What should change during the migration?
Determine whether the workload should be rehosted, replatformed, containerized, refactored or eventually retired.
- What dependencies could prevent a successful migration?
Map databases, networks, identities, APIs, file shares and other application dependencies before migration.
- How will this workload be secured and governed in Azure?
Define security, identity, governance and monitoring requirements before production deployment.
- Who will operate and optimize the workload after migration?
Establish the operational model before the application enters production.
If these five questions cannot be answered, the organization may not yet be ready to migrate that workload.
The Bottom Line
Cloud migration creates an opportunity that extends far beyond moving servers.
Organizations that simply reproduce their existing infrastructure in Azure may receive some cloud benefits, but they can also bring years of technical debt and operational complexity with them.
The better approach is pragmatic.
Modernize where modernization creates measurable value. Rehost where speed or compatibility requires it. Use managed services where they reduce unnecessary operational effort. And design security, governance, resilience and operations into the environment from the beginning.
The result is not simply an application that runs in Azure.
It is an application environment designed to take advantage of Azure.
At BPS, our goal is to help organizations and partners navigate that journey, from assessment and migration through modernization and ongoing cloud operations, while selecting an approach appropriate to each customer’s business and technical requirements.
