In this blog post How to Assess Legacy Apps for Azure App Service Managed Instance we will explain how to identify migration blockers, estimate the real cost and decide whether your application is a good fit before committing budget.
Many older web applications look straightforward until someone tries to move them. What appears to be a simple website may depend on an ageing Windows server, shared folders, registry settings, custom software and authentication services that nobody has documented.
Managed Instance on Azure App Service gives these applications a possible middle ground. It provides a managed Azure hosting platform while allowing more Windows operating system customisation than standard App Service. Microsoft manages areas such as infrastructure patching, load balancing and scaling, while your team retains support for selected legacy components and configuration.
This can reduce server administration without forcing an immediate application rewrite. However, it is not a universal replacement for every Windows server, so a structured assessment is essential.
What is Managed Instance on Azure App Service?
Azure App Service is Microsoft’s managed platform for running web applications and application programming interfaces, or APIs, which allow different systems to exchange information. Instead of maintaining the underlying web servers, your team focuses on the application.
Managed Instance extends this model for older Windows applications that still rely on operating system features. It can support requirements such as MSI software installers, COM components, Windows registry values, custom Internet Information Services settings and access to network file shares.
These customisations are applied at the App Service plan level. An App Service plan is the dedicated pool of computing resources on which one or more applications run.
Managed Instance is currently available for Windows web applications in selected Azure regions and uses Premium v4 or memory-optimised Premium v4 plans. Linux applications and containers are not supported, making regional availability and platform compatibility early assessment questions.
1. Start with the business impact, not the server
Before reviewing code or infrastructure, establish what the application does for the business. Ask which teams use it, how much downtime is acceptable and what happens if data is delayed, lost or exposed.
Document the application owner, user numbers, peak usage periods, recovery requirements and any contractual or regulatory obligations. A payroll portal used monthly has a very different risk profile from an ordering system used throughout the day.
This step prevents a common mistake: spending heavily to migrate an application that should instead be retired, replaced or combined with another system.
2. Build a complete dependency inventory
The web application itself is only part of the workload. Legacy applications often rely on components installed directly on the server, with limited records explaining why they are there.
Your assessment should identify:
- The Windows and .NET versions currently required.
- COM components, MSI-installed software and Global Assembly Cache libraries.
- Registry values, Windows services and scheduled tasks.
- Local folders, mapped drives and shared network storage.
- SQL databases, email relays, payment services and external APIs.
- Hard-coded server names, internet addresses or file paths.
- Certificates, service accounts, passwords and encryption keys.
- Connections to Active Directory or other identity systems.
Azure Migrate can discover and assess many ASP.NET applications running on Internet Information Services, the Windows web server commonly called IIS. It can provide readiness findings, recommended hosting sizes, estimated monthly costs and details about known blockers. A deeper application and code assessment can then identify dependencies that infrastructure discovery may miss.
Automated reports are useful, but they should not replace interviews with application owners and support staff. The undocumented spreadsheet export or overnight file transfer is often where migration risk hides.
3. Decide whether Managed Instance is the right destination
Not every legacy application needs Managed Instance. If the application uses supported frameworks and has no operating system dependencies, standard Azure App Service may be simpler and less expensive.
Managed Instance becomes relevant when the application needs Windows-specific customisation but the business wants to move away from managing complete virtual machines. A virtual machine is effectively a cloud-based server that your organisation must still patch, secure and operate.
Use three practical destination categories:
- Standard App Service for applications that can run without server-level customisation.
- Managed Instance for Windows applications that require supported installers, registry settings, components or private network access.
- Alternative hosting for applications with unsupported drivers, deep operating system control, Linux requirements or dependencies that cannot be separated.
That alternative may be a Windows virtual machine, a container platform or a staged application rebuild. Our guide to modernising old .NET applications explains why migration does not always require replacing everything at once.
4. Assess security and Essential 8 implications
A successful migration should reduce risk, not simply move existing weaknesses into Azure. Review how administrators sign in, where secrets are stored, how the application is exposed to the internet and who can reach its databases and file shares.
Managed identities can allow the application and platform to access Azure services without storing usernames and passwords in configuration files. Azure Key Vault can protect secrets, certificates and encryption keys, while private networking can limit unnecessary public access.
For Australian organisations, map the proposed design against the Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to reduce common attack paths. Pay particular attention to patching, multi-factor authentication, restricted administrative privileges, application control and tested backups.
Managed infrastructure can make patching and access control easier, but it does not automatically make a legacy application secure or compliant. Unsupported libraries, weak authentication and excessive user permissions still need remediation.
For a broader security view, see how Azure App Service runs business applications more securely.
5. Prove the design with a pilot
Do not make the first migration attempt in production. Build a pilot using a copy of the application, representative data and the same network paths the production system will require.
Test installation scripts, registry settings, file access, database connectivity, authentication, certificates and third-party integrations. Then test business processes with the people who actually use the application.
Performance testing matters as well. Record current response times, processor and memory use, concurrent users and peak transaction volumes before migration. Without a baseline, a team cannot tell whether the Azure environment is correctly sized or simply more expensive.
Deployment should also be repeatable. Manual changes create configuration drift, where test and production environments quietly become different. Techniques such as the Azure CLI deployment approach can help standardise application releases once the hosting design is proven.
A typical legacy application scenario
Consider a 200-person logistics company with a customer portal running on an older Windows server. The portal appears to be a standard .NET application, but the assessment finds a document generator installed through an MSI package, registry-based configuration and a shared drive used for shipping records.
A rushed move to standard App Service would likely break document creation and file access. A Managed Instance pilot could reproduce those supported Windows dependencies while moving documents to controlled Azure storage and replacing embedded passwords with managed identities.
The business outcome is not merely “moving to Azure”. It is avoiding a failed migration, removing an ageing server, improving credential security and creating a realistic path for later application modernisation.
Make the decision using evidence
Your final assessment should provide decision-makers with a short business case covering migration readiness, required remediation, expected monthly cost, security improvements, downtime, testing effort and rollback plans.
It should also state clearly what Managed Instance will not solve. If the application remains dependent on unsupported software or an obsolete framework, moving it may only delay a larger problem.
CloudProInc combines more than 20 years of enterprise IT experience with hands-on Azure, Microsoft 365, Defender and Wiz security expertise. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations assess both the application and the broader business risk rather than recommending cloud services by default.
If you are not sure whether a legacy application belongs on standard App Service, Managed Instance or another platform, we are happy to assess the dependencies and give you a practical migration path with no unnecessary rebuild attached.
Discover more from CPI Consulting
Subscribe to get the latest posts sent to your email.