Modernise Web Apps Without a Rewrite on Azure Managed Instance

In this blog post Modernise Web Apps Without a Rewrite on Azure Managed Instance we will explain how businesses can move older Windows web applications off ageing servers without immediately rebuilding them from scratch.

This matters because many legacy applications still run important processes such as customer orders, staff rostering, reporting or finance approvals. The application may work perfectly well, but the server underneath it is becoming expensive, difficult to secure and increasingly dependent on one person who knows how everything fits together.

Managed Instance on Azure App Service is designed to close the gap between traditional Windows servers and a fully managed cloud application platform. It gives older applications more of the Windows features they expect while Microsoft manages much of the underlying hosting environment.

Why working software can still be a business risk

A legacy application does not need to be broken to create risk. The warning signs are often found around the application rather than inside it.

The operating system may be approaching the end of support. Security updates might require manual weekend work. Backups may exist but have never been tested, and recovery could depend on rebuilding a server from incomplete documentation.

Meanwhile, replacing the application may involve a six-figure development project, months of testing and disruption to established business processes. Decision-makers are left choosing between an expensive rewrite and continuing to carry an ageing server.

Managed Instance introduces a third option. It can provide a practical transition point where the application moves to Azure with limited code changes, while the organisation reduces server management and plans longer-term improvements at a sensible pace.

What Managed Instance on Azure App Service actually does

Azure App Service is Microsoft’s managed platform for running web applications. Instead of maintaining a complete Windows server, your team deploys the application and Microsoft handles areas such as the underlying infrastructure, operating system patching, load balancing and platform availability.

Standard App Service works well for modern applications, but older Windows applications often expect access to components that a tightly controlled cloud platform does not normally expose.

Managed Instance on Azure App Service adds support for many of these dependencies at the hosting-plan level. A hosting plan is the pool of computing capacity on which one or more applications run.

• Windows installers can add software components required by the application.
• COM components, which are older Windows software modules used by many business applications, can be registered.
• Registry settings can be configured, with sensitive values protected through Azure Key Vault, Microsoft’s secure storage service for passwords, certificates and other secrets.
• Windows features and services can be enabled through repeatable configuration scripts.
• Network file shares can be connected using Azure Files or existing compatible shared storage.
• Private networking can connect the application to databases and internal systems without exposing those services directly to the internet.

The important difference is that you gain this flexibility without returning to full-time server management. Microsoft still manages the App Service platform, while your team controls the application-specific configuration.

When Managed Instance is worth evaluating

Managed Instance is most relevant when an application is suitable for Azure App Service in principle but fails a standard migration assessment because of a small number of Windows dependencies.

The application relies on installed components

An older accounting portal might use a third-party component to create PDF invoices. A claims system may call a COM library, while a document application may require particular fonts or Windows features.

Previously, these requirements could force the application onto a virtual machine, which is simply a server hosted in Azure. Managed Instance may allow those dependencies to be installed automatically while retaining the operational benefits of App Service.

The application needs private access to existing systems

A web application may need to reach an on-premises database, file share or internal service. Managed Instance can use Azure virtual networking, which creates a controlled private connection between cloud resources and your business network.

This can reduce unnecessary public exposure and support a staged migration. The web application can move first while a database or dependent system remains on-premises temporarily.

Server maintenance is consuming too much effort

If your team spends time patching Windows, monitoring server capacity and troubleshooting infrastructure, the real cost is not limited to the Azure or hardware bill. It includes labour, after-hours work, support contracts and the business impact of outages.

Moving suitable responsibilities to the platform gives internal IT staff more time to improve the application and support users instead of maintaining another server.

Before deciding, use a structured dependency review. Our guide on assessing legacy apps for Azure App Service Managed Instance explains what to collect and test.

A practical migration scenario

Consider a 200-person professional services company with an internal .NET Framework application running on two Windows servers. The application uses a registered reporting component, writes documents to a shared drive and connects to a private SQL database.

A complete rewrite would take many months and introduce considerable testing risk. Leaving the application in place would require another server refresh, ongoing Windows administration and a more complex disaster recovery plan.

Managed Instance could allow the company to package the reporting component into an installation script, mount the document share and privately connect to the database. The application code may need only limited configuration changes rather than a complete rebuild.

The business outcome is not simply that the application is now “in the cloud”. It avoids an immediate rewrite, removes part of the server-management workload and creates a supported platform for future improvements.

How repeatable configuration works

Managed Instance uses PowerShell installation scripts to apply required Windows configuration when an instance starts. PowerShell is Microsoft’s automation language for managing Windows systems.

The script and any required installation files are stored securely in Azure Storage. A managed identity, which is a secure identity assigned to the Azure service, retrieves them without placing a storage password inside the application.

$installer = Join-Path $PSScriptRoot "ReportingComponent.msi"

$process = Start-Process "msiexec.exe" `
 -ArgumentList "/i `"$installer`" /qn /norestart" `
 -Wait -PassThru

if ($process.ExitCode -ne 0) {
 throw "Reporting component installation failed."
}

Write-Output "Reporting component installed successfully."

This simple example installs a required component without an administrator manually signing into every instance. Production scripts should also check whether components are already installed, record useful logs and fail safely when something goes wrong.

Remote desktop access is available through Azure Bastion, a controlled service for secure administrative connections, but it should be used for diagnosis rather than permanent changes. Any required configuration should be captured in code so it can be repeated consistently.

What Managed Instance will not fix

Managed Instance is not a universal answer for every legacy application. It currently targets Windows web applications, is available only in selected Azure regions and uses Premium v4 or memory-optimised Premium v4 hosting plans. Linux applications and containers are not supported.

Applications that require hardware drivers, unrestricted control of the operating system or unsupported server roles may still need virtual machines or a different hosting model. Poorly written code, unsupported third-party libraries and weak database design also remain application problems.

Configuration applies at the App Service plan level. Applications with conflicting dependencies or different security requirements may therefore need separate plans, which affects cost.

Premium v4 also uses dynamic outbound internet addresses. If a supplier only accepts traffic from an approved fixed address, an Azure NAT Gateway, which provides predictable outbound addresses, may be required.

Security and Essential Eight considerations

Managed platform patching can reduce the effort involved in maintaining the underlying Windows environment. This supports the intent of the Essential Eight, the Australian government’s cybersecurity framework, particularly its focus on patching operating systems and internet-facing services.

However, moving to Managed Instance does not automatically make an application Essential Eight compliant. Your organisation still needs to patch application libraries, enforce multi-factor authentication, restrict administrator access, test backups and monitor suspicious activity.

Microsoft Defender for Cloud and Wiz, which identify security weaknesses and risky cloud configurations, can provide additional visibility. They are most useful when paired with clear ownership and a documented response process.

For a broader discussion, see how Azure App Service runs business applications more securely.

Build the business case before migrating

Do not compare Managed Instance pricing only with the cost of a virtual machine. Include Windows licensing, backup tools, monitoring, security software, disaster recovery, patching effort and support time in the current-state calculation.

Then estimate the Azure plan, storage, networking, monitoring and support costs. Premium capacity can be more expensive than basic App Service, so right-sizing and separating production from temporary test environments matters.

Our guide to lowering Azure App Service costs without hurting performance covers the common areas where unnecessary spending appears.

A sensible evaluation process

1. Document dependencies. Identify installed software, registry settings, file shares, scheduled tasks, authentication methods and network connections.
2. Confirm platform fit. Check Windows compatibility, Azure region availability, hosting-plan requirements and any need for fixed outbound addresses.
3. Create a non-production pilot. Deploy the application and its configuration scripts without changing the live service.
4. Test real business processes. Include reports, document generation, integrations, authentication, backups and failure recovery.
5. Measure performance and cost. Use realistic user volumes rather than relying on an application simply loading successfully.
6. Plan a reversible cutover. Define rollback steps, responsibilities and acceptable downtime before moving production traffic.

Deployment can then be automated through Azure DevOps, GitHub Actions or command-line tools. For simpler App Service projects, our article on web app deployment with Azure CLI provides a useful introduction to repeatable releases.

Modernisation does not have to mean rebuilding everything

For the right Windows application, Managed Instance on Azure App Service can remove a major migration barrier. It preserves necessary Windows dependencies while reducing the amount of infrastructure your team must operate.

The key is to treat it as an engineering and business decision, not a simple hosting change. Compatibility, security, operating effort, resilience and total cost all need to be tested before production migration.

CloudProInc is a Melbourne-based Microsoft Partner and Wiz Security Integrator with more than 20 years of enterprise IT experience. If you are unsure whether an older web application needs a rewrite, a virtual machine or Managed Instance, we are happy to assess the options with you—no strings attached.