Why review these changes together?

MANA and VM lifecycles

MANA can change the network adapter on an eligible existing VM after maintenance or a stop, deallocate, and start cycle, even when the VM size stays the same. With Accelerated Networking enabled, check supported OS and driver versions. When it is disabled, no MANA-specific action is required. Rollout timing depends on the VM series, so check readiness alongside the application tests.

The VM lifecycle stages are Current, Extended, End of Life, and Retired. Extended sizes remain supported; End of Life sizes remain supported until their announced retirement date. A retirement announcement does not end support immediately. Check the exact family’s dates when planning a refresh and evaluate suitable managed services alongside supported VM options.

Reservations need to follow the application

Reservation exchanges help commitments keep up as an environment changes. From February 1, 2027, new eligible reservations for services covered by savings plans will no longer be exchangeable; eligible earlier purchases retain a final exchange. Renewals count as new purchases. Check the exact product and intended destination before renewing.

Exceptions apply to certain products and clouds, including deprecated or End of Life products and services or clouds not covered by savings plans. Cancellation, instance-size flexibility, and reservation trade-in policies are unchanged. The policy date is a checkpoint for the architecture review, not a reason to buy early.

Figure 1. Use the planned review to reassess each component’s VM needs.

What PaaS changes day to day

For a compatible web app, App Service removes the need to manage the underlying VM and OS. Managed services can also simplify deployment and scaling configuration, reducing work on guest-OS updates, driver checks, and hardware lifecycles. Evaluate PaaS where infrastructure-level control is unnecessary.

Application teams still own data, identities, access controls, code, configuration, and the service’s network settings. Custom libraries and container-image dependencies still need maintenance. Monitoring, security, and application testing remain essential. Microsoft manages the platform, while the team remains accountable for the application.

Look for one useful first move

Look first for a component that needs regular attention but little server-specific customization. A database, queue, or cache may be a better starting point than the entire application. Record who owns it, the runtime and integrations it depends on, its security requirements, and the time and money spent running it today. Prioritize work that advances a business goal, such as reducing maintenance effort or making releases easier to manage.

For a web app or API, ask where it keeps session state, whether it writes files to the local disk, and how background jobs run. Follow the authentication flow and the connections to other systems. Those answers help determine whether App Service or Container Apps is a good fit and what needs to change first. There’s no need to redesign everything as microservices before moving a suitable queue, cache, or database to a managed service.

Match each component to a managed service

Use the table to narrow the options for each component. A single application can combine managed services with VMs, so choosing one managed target doesn’t settle the hosting decision for every other part. Keep a VM where the application genuinely needs its control.

The database can often be assessed on a separate schedule from the application. Azure SQL Managed Instance offers broad instance-level SQL compatibility, though not every SQL Server feature has an equivalent. Azure SQL Database suits cloud-native application and data designs. Both provide platform-managed patching, backups, and built-in high availability. The design still needs decisions about backup retention, restore objectives, access, and disaster recovery.

Take a web application with SQL Server on a VM. One possible first step is to move the database to Managed Instance and leave the application on its VM. Test SQL behavior, authentication, network connectivity, and integrations before making that move. The web tier could move to App Service later if it fits. This gives the team two manageable changes instead of one larger rewrite. If the application needs full OS customization or a dependency isn’t supported by the managed service, keeping that component on a VM may still be the right choice.

Figure 2. An illustrative sequence: database first, then a suitable web tier.

A practical PaaS-first strategy for your Azure environment

Standardize the foundation; modernize by application. Feed MANA readiness checks, VM lifecycle reviews, and reservation renewals into one plan across subscriptions and teams, rather than separate VM-by-VM refreshes.

Group compute, data, and integrations by application across subscriptions. Name application and platform owners; record OS dependencies, maintenance effort, usage, costs, and reservation expiry dates. Retire unused components with owner approval, re-platform suitable parts with limited code changes, or refactor selected dependencies. Retain supported VMs for necessary OS control, appliance certification, or vendor requirements, with a reason and review date.

Have the platform team own approved App Service, Container Apps, database, and messaging patterns in version-controlled deployment definitions. Include service-specific identity, access, network, monitoring, backup, restore, tagging, and budget standards. Apply Azure Policy checks at appropriate management-group or subscription scopes: audit and test first, then enforce gradually with documented exceptions. Share standards, not identical tiers or hosting choices.

Prioritize waves by business value, maintenance burden, migration effort, dependencies, and readiness. Pilot representative, low-risk components with useful value, then reuse proven patterns. Application teams own fit and acceptance; resolve gaps before approving production within business-approved change windows.

Before production, validate the workload

• Exercise real application paths under representative load. Confirm functionality, the chosen service tier, and performance against acceptance criteria agreed before the pilot.
• Test sign-in, service authentication, least-privilege permissions, network connections, and integrations. Confirm that the managed target supports the application’s dependencies.
• Verify that monitoring exposes important failures. Exercise restore and disaster-recovery procedures against agreed objectives; confirm backup retention, privacy, and data-location settings.
• Prove that version-controlled deployment definitions reproduce the environment. Keep a short operating guide with named owners for settings, recovery, and support.
• Compare the full Azure bill, service tier, licensing, migration effort, and ongoing support work with the baseline. PaaS is not always cheaper; reduced maintenance does not automatically become cash savings.
• Rehearse traffic and data cutover and document rollback. Decide how writes made in the new service would be reconciled before returning to the old system.

Move in stages and confirm acceptance under real operating conditions before retiring old VMs and unused dependencies. For retained VMs, maintain supported images, MANA readiness when Accelerated Networking applies, and a family-specific lifecycle plan.

Align commitments with the new architecture

Bring FinOps into architecture selection. Review existing reservation and savings-plan obligations, utilization, expiry dates, and destination-service eligibility before moving a component. An Azure Reserved VM Instance (RI) does not automatically become a PaaS benefit, and moving the workload does not end the obligation.

For an eligible compute RI, assess a trade-in to a new compute savings plan. Its total lifetime commitment must be at least the RI’s remaining value, and the trade-in cannot be reversed into an RI. Check product and scope eligibility; size new commitments from measured, stable destination usage, not temporary old/new dual running.

Compute savings plans cover eligible infrastructure usage, including App Service and Container Apps, but not software, network, or storage charges. Database savings plans are a separate offer for eligible database services. A savings plan commits to a fixed hourly amount for one or three years; unused hourly commitment does not roll over, and purchases cannot be canceled or refunded.

After each wave, compare operating effort, deployment lead time, reliability, total cost, and discount utilization with the baseline. Name owners for the next wave and revisit the plan at business, lifecycle, and renewal checkpoints. Use the results to improve the shared patterns and the next architecture choice.

Make the next step specific

A useful outcome is an environment-wide plan with a concrete first move. A managed database, queue, or web tier can reduce maintenance even when other components stay on VMs. Assess PaaS before the next refresh, retain supported VMs where their control is justified, and expand when the pilot’s results support it.

References

• Use platform as a service (PaaS) options
• Shared responsibility in the cloud
• SQL Server modernization FAQ
• Application modernization foundation
• Assess application modernization needs
• MANA support for existing VM sizes
• VM lifecycle overview
• Azure reservation exchange policy
• Savings plans overview
• Reservation trade-in for savings plans
• Plan cloud modernization
• Azure governance design guidance
• You Get One Exchange Left: Rethinking Azure Commitments Before February 2027