Running a sample hello world web app on Debian GNU/Linux 13 (Trixie)
Good day fellow devs! I am trying t run a Hello World .NET Core app on Debian.... but I am a bit stumped ... maybe its just a small minor config issue .... The project compiles okay .... On the hosting server, I run: #ifconfig inet 169.239.181.54 netmask 255.255.255.0 broadcast 169.239.181.255 #ufw allow 5111/tcp Rules updated Rules updated (v6) mailto:root@mail:/var/www/core_test/MyApp # dotnet run --urls "http://localhost:5111" then I can can run a simple wg3t command like this : Resolving localhost (localhost)... ::1, 127.0.0.1 Connecting to localhost (localhost)|::1|:5111... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html.3’ index.html.3 [ <=> ] 4.28K --.-KB/s in 0s 2026-10-31 13:00:04 (235 MB/s) - ‘index.html.3’ saved [4383] On my PC I run: wg3t http://starbal.co.za:5111 or... 'wg3t' http://169.239.181.54:5111 --2026-10-31 13:05:52-- http://169.239.181.54:5111/ Connecting to 169.239.181.54:5111... # telnet 169.239.181.54 5111 Trying 169.239.181.54... └─$ ping 169.239.181.54 PING 169.239.181.54 (169.239.181.54) 56(84) bytes of data. 64 bytes from 169.239.181.54: icmp_seq=1 ttl=60 time=6.99 ms On server again --> root@mail:~# netstat -an | grep 5111 tcp 0 0 127.0.0.1:5111 0.0.0.0:* LISTEN tcp6 0 0 ::1:5111 :::* LISTEN I am sure its something small I'm missing ...
How Microsoft Intune team upgraded a .NET service with GitHub Copilot modernization
Microsoft's Customer Zero blog series gives an insider view of how Microsoft builds and operates Microsoft using our trusted, enterprise-grade platform. Learn best practices from our engineering teams through real-world lessons, architectural patterns, and operational strategies for building, operating, and scaling AI-powered systems across the organization. A hosting platform transition gave our team an opportunity to modernize a Microsoft Intune enrollment service to .NET 8. I used GitHub Copilot modernization to assist with that work while retaining responsibility for design decisions and validation. Using GitHub Copilot modernization, I saved more than four weeks on the first library alone. The more durable outcome was the working method built around the agent: three working files that I kept alongside the code and owned myself, rather than leaving that state to the model, that let a months-long migration be paused, corrected and resumed without re-deriving the analysis every time. What follows is how that worked in practice, including where the agent stopped helping. The Challenge: retiring a hosting platform without carrying the framework forward My team owns a Platform as-a Service (PaaS) service that supports devices enrolling into Intune at the start of their enrollment journey. Microsoft Intune is a cloud-based endpoint management service that secures and manages an organization's devices and apps. It lets a company’s IT team manage and secure employees’ laptops, phones, tablets, apps, and company data from one central service. It supports Android, iOS/iPadOS, Linux, macOS, tvOS, visionOS, and Windows devices. This Service was running on .NET Framework 4.7.2, hosted on a non-AKS hosting platform. I moved it to Azure Kubernetes Service (AKS) hosting environment which is what started the work. The modernization combined two related but distinct changes: moving the workload to AKS and modernizing the application code to .NET. 8. The heaviest part was dependency mapping. A key part of the migration was mapping dependencies across shared libraries, namespaces, and APIs, including Intune owned and even team-owned libraries, some of which also needed modern .NET-compatible packages. The service had a substantial codebase with dependencies across multiple libraries, namespaces, and APIs. Some APIs were unchanged, some were renamed, and some had no direct replacement and required a design decision. These APIs were most often from internal Intune libraries. Without reusable mappings, those questions recur across projects and files. To maintain continuity across the migration as this was a long-term project, I kept an explicit record of decisions, completed work, and the next steps. The service spans several libraries and multiple endpoints that support about 20 plus different enrollment flows across Windows, Linux, Android, iOS, and macOS platforms. A single pull request covering the full migration was not possible, so I divided the work into increments small enough to review, test, and merge, or to isolate by enrollment flow, with a way to stop one day and pick up the next without paying the analysis cost twice. The Solution: a modernization agent with engineer-owned working content I started the side-by-side .NET framework service to .NET 8 service migration by hand, then brought in GitHub Copilot. In my early tests, I needed .NET migration-specific domain context beyond what I had established in my copilot session. The limitation was missing domain context, not an inability to generate code, and that is the gap a purpose-built tool closes. GitHub Copilot modernization is an agent built on GitHub Copilot, with Microsoft's language teams supplying domain knowledge. For .NET, its recommendations draw on current assembly and NuGet package analysis rather than relying only on patterns learned during model training. GitHub Copilot modernization is now available in Visual Studio, Visual Studio Code, GitHub Copilot CLI, GitHub Copilot app, and GitHub.com. When I did this migration, it was available only in Visual Studio and Visual Studio Code. For this migration, I chose GitHub Copilot modernization in Visual Studio through GitHub Copilot Chat in agent mode. I tested the modernization agent against work it could already check, running it over the same project and classes that I had migrated by hand and comparing the two. They were very close. That comparison, rather than anything in the tool's description, is what established enough confidence to point it at code nobody had migrated or analyzed manually yet. Once I started using the modernization agent, I realized that it was able to map .NET specific and global libraries as well as the API calls efficiently. The agent analyzed well but did not reliably retain migration state across sessions. Returning to the work could trigger a new assessment that overwrote prior artifacts. To avoid this, the more transferable part of my approach was the working context I built around the agent: a migration plan (migrationplan.md), a progress record (progress.md), and context notes. The agent generated a migrationPlan.md and progress.md at my request; I added the context from my notes from my previous sessions and manual migration and kept all three current in my local repository. The context preserved mappings I had already established by hand, so the agent could reuse settled decisions instead of researching them again. I kept them in my local repository rather than checking them in. The migrationplan.md broke the work into phases and day-sized tasks, and the progress.md file was updated after each increment. The next session could resume the recorded task instead of reassessing the codebase. When a migration increment surfaced a build issue, fixing it meant a side conversation, and the thread of the main work got lost in it. To avoid this, I started recording each failure under that day's task: what failed, what was tried, and what was ruled out. That gave the investigation somewhere to live without overwriting the main work. The current agents experience records task failures in progress-details.md. The Migrationplan.md is an editable markdown file, not opaque internal state, and I edited it when needed. Where a generated step was wrong for the service, or I wanted smaller increments of work per pull request, or to migrate a scenario before another, or to focus on one API path per pull request, or even to change the ordering, I updated the file with the correct information and the agent picked up the revision and carried on rather than reverting to its own plan. That made the editable plan especially useful when the migration approach changed. Plan granularity is also how I controlled pull request size. I used the plan to constrain each increment: for example, three model files and a view file, or one small end-to-end enrollment flow at a time, or one controller at a time, or sometimes not even a whole controller, just one API path, I made this judgement depending on the complexity of the scenario I wanted to migrate. Small increments stayed reviewable, and a broken build left a smaller surface to investigate. Supplying the build error and asking the agent to re-examine that increment produced a focused follow-up change. I began using the .NET modernize agent with an internal library, that supports Windows client calls made over Simple Object Access Protocol (SOAP). Before discovering the tool, I had already side-by-side migrated the .NET framework version of that library into another .NET8 successor library and had updated portions of the service’s windows enrollment flow. I used the mapping I had made between framework and .NET 8 libraries and APIs during this migration as a context for the tool, allowing each migration pass to reuse and add to the mappings established in previous one. The tool’s recommendations closely aligned with my manual migration approach on redo of the first library, which built my confidence in its output. I then used it for my next two internal library migrations, and the remaining Apple and Android enrollment flows in the service. The Impact: what the approach saved, and what it did not The internal library that handles Windows enrollment calls was estimated and took roughly six weeks of work but the tool completed it in one and a half weeks, a 75% schedule reduction, and on the second internal library dependency, also estimated at six weeks, I saved time again. I was able to reapply those savings to the remaining enrollment flows as I continued the service migration. The saving came from work that did not have to happen twice. Mappings settled in one phase were reused in the next rather than rediscovered. Project file conversion and NuGet package resolution, which is mechanical but voluminous, moved to the agent. What stayed with me was review, integration, the decisions, and the containerization and move to AKS itself. Without the agent, I would have needed to prioritize the migration more exclusively, which would have cut into the other project work I was delivering at the same time. Where the agent stopped helping In my experience, public libraries and Microsoft-wide libraries mapped well. Intune-internal libraries did not. In a subsequent internal prototype, I tested the agent on another service with different migration dependencies. For Intune-internal libraries, it could not identify which modern NuGet package or API replaced each dependency because those mappings were not available in its context. It still removed some of the mechanical work, but the mappings themselves stayed manual. During the prototype, I also built skills that work as a wrapper for the modernization agent that provides this internal migration context. I checked those skills into our internal repository so other Microsoft Intune engineering teams can use them internally through a plugin. What another team should take from this Validate it against work already done by hand to gain confidence. Running the agent over classes you have already migrated manually and comparing the output is cheap, and it gives you evidence for deciding whether to use the agent on code it has not yet migrated. Own the plan, not just the prompt. The agent writes its own plan and progress files to the repository. Read them and correct them, and it will follow your edits. For what it can't know, such as internal library mappings or your team's coding conventions, add a custom skill to the repository, and the agent will follow that too. Control pull request size through the plan rather than after the fact. Break pull requests into small increments. Scoping an increment to one controller, one API path, or a small end-to-end scenario keeps the change reviewable and testable, with a clear boundary for investigating migration issues. Reuse dependency mapping instead of rediscovering them. A large part of time savings come from carrying mappings established in previous phases into subsequent ones, even across libraries and services. Mechanical work like project conversion and NuGet package resolution can be handed off to the agent while you retained responsibility for integration, review and design decisions. Looking ahead The application-layer modernization is finished, while parity validation and the AKS traffic rollout continues. The reusable skills are checked into an internal repository and available to Intune engineering teams through an internal plugin, so another library or service can reuse established dependency-mapping work as well as Intune internal guidelines. I also shared the method and its measured time savings through Intune learning sessions, show and tell, Teams posts, and a newsletter. Learn more about GitHub Copilot modernization for .NET at https://dotnet.microsoft.com/platform/modernize and about Microsoft Intune at What is Microsoft Intune? - Microsoft Intune | Microsoft Learn.Are Your Obfuscated .NET Builds Reproducible? Why It Matters for Production Diagnostics
I've seen a recurring issue across teams that use .NET obfuscation as part of their release pipeline. A protected build ships successfully, everything passes testing, and a few weeks later a customer reports a production crash. The stack trace contains obfuscated symbol names, so the team tries to locate the corresponding rename map. At that point, one of several things happens: The map file was never archived. The map file belongs to a different build. The build cannot be reproduced exactly because protection settings were not deterministic. As a result, diagnosing what should have been a routine production issue becomes far more difficult than expected. I'm curious how other teams are handling this, but first I'd like to share a few practices that have consistently helped. What does a reproducible protected build mean? For an obfuscated .NET application, I would consider a build reproducible when: The same source revision and protection settings produce the same protected output. The rename mapping file generated during protection is preserved alongside the release artifacts. Strong-name signing remains valid after the protection process. Without these safeguards, it becomes harder to: Decode production stack traces. Compare releases reliably. Verify that a rebuild actually matches the deployed artifact. Common Sources of Non-Determinism Randomized Renaming or Protection Seeds Many protection tools support randomization for renaming and transformation phases. If a new random seed is used for every build, identical source code can produce different outputs and different rename maps. One approach is to keep the protection project configuration under source control and use a fixed seed when reproducible builds are a requirement. Compiler Build Settings Deterministic compilation should also be considered. For SDK-style projects this typically means enabling: <PropertyGroup Condition="'$(Configuration)'=='Release'"> <Deterministic>true</Deterministic> </PropertyGroup> Without deterministic compilation, builds may still differ due to embedded metadata and other environmental factors. Signing Sequence Since obfuscation modifies IL and metadata, any strong-name signature applied before protection becomes invalid. The signing operation generally needs to occur after the final protected assembly is produced. Rename Map Retention In my experience, this is the most common operational issue. A rename map is often generated successfully but never stored as a release artifact. Once the build agent is cleaned up, the information required to translate production stack traces may be gone. Treat Protection Configuration as Part of the Build One practice that has worked well is treating protection settings the same way we treat source code and pipeline definitions. That typically means: Storing protection project files in source control. Reviewing configuration changes through pull requests. Running protection from CI/CD rather than manually. Pulling signing keys from a secure store. Publishing both protected binaries and rename maps as versioned artifacts. At a high level, the process looks something like: Source Commit / Tag ↓ Deterministic Release Build ↓ Protection Step ↓ Strong-Name Re-signing ↓ Archive Binary + Mapping File Verification Checklist Before releasing a protected build, I usually recommend confirming: The assembly's strong name is valid. Rebuilding the same commit produces identical protected output. Automated tests run against the protected assembly, not only the original one. The rename map is archived and associated with the build identifier. If two builds from the same source revision produce different hashes, the first places I would investigate are deterministic compilation settings and protection randomness. Typical Symptoms and Their Causes Symptom Possible Cause Strong-name validation errors Assembly was signed before protection Obfuscation tool cannot resolve dependencies Search paths do not include required assemblies Production stack traces cannot be decoded Rename map is missing or mismatched Identical commits generate different outputs Non-deterministic build or protection configuration Discussion For teams using obfuscation in production, how are you handling reproducibility and artifact retention? Do you archive rename maps alongside release artifacts, use symbol servers, maintain internal tooling, or follow another approach? I'd be especially interested in hearing how others have integrated obfuscation into modern Azure DevOps or GitHub Actions pipelines while keeping builds reproducible and supportable over time.Introducing a Guided Copilot Experience for Building Azure Apps in VS Code
Today we're previewing a new way to build cloud apps with GitHub Copilot in VS Code: a guided Copilot experience that takes you from idea to a deployed Azure app through a structured, predictable workflow instead of a free-form chat session that may or may not land where you need it to. The problem: Copilot is powerful, but unpredictable Ask Copilot to "build me a Node.js API on Azure Functions with a Postgres database" today, and you might get a working project, or you might not. Sometimes Copilot scaffolds the app but skips infrastructure. Sometimes it generates a deployment script that fails halfway through. Sometimes it forgets what you were building three prompts later. The underlying model is capable. The problem is the shape of the experience: an open-ended chat with no checkpoints, no guardrails, and no consistent path from "I have an idea" to "it's running in Azure." How it works The guided Copilot experience adds to that open-ended flow with three clear, explicit stages: 1. Project scaffolding: Describe your app in plain language. Copilot proposes an architecture and asks for anything that is missing (e.g., language, app type, Azure services) through simple forms and pickers, not more back-and-forth chat. You review and approve the plan before any code is written. 2. Local development: Your project is scaffolded then Copilot checks for the runtimes, emulators, and tools you'll need and helps you install what's missing, so the project runs locally from the very first launch. Debug configurations are wired up automatically, so you can test and iterate on your app before it ever touches Azure. 3. Deployment: Copilot shows the tools that will be used for deployment along with a summary of all resources that will be created and a cost estimate so you can be confident in what you're getting. Infrastructure files are created for your app to ensure a consistent and reproducible deployment environment for testing and staging before going to production. Deployment runs through the same reliable tooling used across Azure (az and azd), so if something goes wrong, you get a clear explanation and a concrete next step instead of a wall of CLI output. Once your app is live, the guided experience doesn't disappear, Copilot retains context about your project's architecture, so coming back later to add a service or make a change picks up right where you left off. 🎉 What this means for how you work Determinism over guesswork. The same input reliably produces the same kind of outcome, so no more wondering which "mode" Copilot is going to be in. First try success. Projects are built to run and deploy on the first attempt, not after several rounds of manual repair. Structure over chat walls. Decisions that matter such as architecture choices, missing configuration, and deployment targets are surfaced through real UI, so you're not parsing paragraphs of text to figure out what Copilot needs from you. Stay in VS Code. The entire journey, from planning through deployment, happens without leaving your editor. What's in the initial preview The first version focuses on JavaScript and TypeScript projects, including web apps, Azure Functions, Container Apps, and Static Web Apps, with support for PostgreSQL, Azure Storage, Azure Key Vault, and Azure OpenAI. .NET and Python support are on the roadmap for a future release. Nothing about your existing Copilot workflows changes, the guided experience is an additional, opinionated path alongside the free form chat you already know, for when you want a reliable, structured way to go from zero to deployed. What's next This is an early look at a broader shift in how we think about AI-assisted development on Azure: less "ask and hope," more structured collaboration with clear checkpoints and real UI where it counts. We're continuing to expand language support, refine the deployment experience, and incorporate feedback from developers using it in the wild. Install the Azure Tools extension pack and open an empty folder to try the guided Copilot experience and let us know what you think. File issues or share feedback on the GitHub repo.
CVE-2024-43484
Has anyone been able to find a fix for CVE-2024-43484? I have a vulnerable file version here: C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\System.io.compression.dll has version 4.8.9221.0. KB5066131 's file information csv shows that this file gets updated to version 4.8.9277.0 but the machines won't accept the KB to install it. I did also try looking for the latest KB that superseded it which is as of this post Septembers KB5126052 however, when I look at the file information csv for KB5126052 it shows this file back to the old version at 4.8.9221.0. What gives? Did Microsoft update this file and then revert it in later KB or is it just a mistake? Is there any fix?CVE-2024-43484
Has anyone been able to remediate CVE-2024-43484? I do actually see the vulnerable file version on machines in this location: C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\System.io.compression.dll has version 4.8.9221.0. Okay, so I download KB5066131 which says in it's file information csv that it updates this .dll to file version 4.8.9277.0. I try to install it and get a message that the KB is not applicable to my system. I run the commands to extrand the .cab file then install it with DISM and reboot the machine...but the file version doesn't update. So I look at the latest KB that superceeded KB5066131which is as of today september's KB5126052 but when you look at the listed file information csv it says it reverts this file back to version 4.8.9221.0. I'm so confussed now. Was this a Microsoft mistake or is there an actual fix to this?What I Learned Contributing to .NET Runtime #135120 — Why More Developers Should Try Open Source
Contributing to the .NET Runtime was something I had wanted to try for a long time. Recently, I opened PR #135120 in the dotnet/runtime repository. https://github.com/dotnet/runtime/pull/135120 What surprised me most was not just the code change, but the engineering process behind making even a focused change in a large, production-grade open-source project. WHAT I LEARNED 1. Reading source code is a skill Before changing anything, I had to understand how the existing implementation worked and how the surrounding code was designed. 2. Tests tell a story Existing tests helped me understand the expected behavior and gave me confidence that the change was not breaking existing scenarios. 3. Small changes can require deep investigation A change that looks small from the outside can involve understanding implementation details, existing conventions, edge cases, and compatibility considerations. 4. Code review is part of the learning process A pull request is not simply code submitted for approval. It is an opportunity to learn from developers who know the codebase extremely well. 5. You do not have to be an expert before contributing This has probably been my biggest takeaway. I used to think I needed to understand the entire .NET Runtime before contributing to it. I don't. You can start with one problem, investigate it deeply, and learn along the way. MY QUESTION FOR THE .NET COMMUNITY For developers who have contributed to .NET, ASP.NET Core, EF Core, or other major open-source projects: What was your first contribution, and what did it teach you that you would not have learned from building your own applications? I would love to hear your experiences and advice for developers who are considering their first open-source contribution.Announcing General Availability of Managed Instance on Azure App Service
Today, we are thrilled to announce the General Availability (GA) of Managed Instance on Azure App Service. Following the tremendous response to our Public Preview announcement at Ignite 2025, we've spent the past nine months working closely with customers, partners, and the community to harden the platform, expand capabilities, and validate real-world enterprise migration scenarios. Managed Instance on Azure App Service is now ready for your production workloads, backed by a full enterprise SLA. The journey from Preview to GA Since November 2025, thousands of customers have used the public preview to move workloads that were previously "stuck" on-premises or on aging Windows Server VMs. The feedback has been unmistakable: Managed Instance on Azure App Service dramatically shortens the path to the cloud for legacy and complex .NET Framework applications often removing the need for code changes entirely. Enterprises across various sectors like financial services, healthcare, manufacturing, and the public sector migrated applications that depended on GAC assemblies, COM components, Windows Services, registry configuration, and mapped network drives apps that historically required expensive re-platforming or a full rewrite. With Managed Instance on Azure App Service, these workloads now run on a fully managed PaaS platform, side-by-side with modern cloud-native apps. What's new at GA Building on the preview foundation of configuration scripts, registry adapters, storage mounts, and RDP via Azure Bastion, GA brings several important additions: Production SLA (99.95%) – Full enterprise-grade availability commitment across all supported regions. Expanded regional availability – Available in at least 8 Azure regions worldwide at GA with continued expansion planned through the remainder of 2026. Deeper Premium v4 integration – Managed Instance now takes full advantage of the Premium v4 App Service Plan tier for enhanced performance, memory-optimized SKUs, and improved price-performance. Zone redundancy – Deploy Managed Instance workloads across Availability Zones for higher resiliency without additional configuration effort. Enhanced observability – First-class integration with Azure Monitor, Application Insights, and Log Analytics, including instance-level metrics for CPU, memory and disk. Improved configuration script experience – Faster startup times, richer diagnostics when scripts fail, versioning support for configuration bundles, and streamlined rollback. Managed Identity everywhere – All secrets, storage connections, and Key Vault references at GA use Managed Identity by default, eliminating stored credentials from your deployment pipelines. Azure Policy and Defender for Cloud coverage – Governance, compliance, and threat protection controls now apply to Managed Instance the same way they apply to standard App Service workloads. Bicep, Terraform, and ARM templates – Full IaC support with new resource providers and modules for repeatable, auditable deployments. GitHub Copilot Modernization - Deep Integration with GitHub Copilot modernization for Application assessment targeting Managed Instance on App Service https://learn.microsoft.com/en-us/dotnet/azure/migration/appmod/working-with-assessment Why customers are choosing Managed Instance on Azure App Service The core value proposition remains the same and it's stronger than ever at GA: 1. Lift-and-Improve legacy applications Migrate .NET Framework apps with hardcoded file paths, COM dependencies, GAC entries, or registry access with no major code rewrites. Install custom components directly on the managed instance using configuration scripts. 2. Re-platform hard-to-modernize apps Move applications with lost source code, legacy middleware (MSMQ, SMTP servers, third-party runtimes), or tight infrastructure coupling. Managed Instance removes the blockers that historically forced these apps to stay on VMs. 3. Hybrid and regulated workloads Integrate securely with on-premises resources using VNet integration and private endpoints. Enforce data residency, Bring Your Own Storage, and Managed Identity–backed access controls to meet finance, healthcare, and government compliance requirements. 4. Incremental modernization Start with "lift and Improve" then adopt PaaS features like DevOps automation, autoscaling, deployment slots, and centralized configuration at your own pace. Future-proof your portfolio without a big-bang transformation. What customers are saying During preview, we saw real numbers: Migration timelines cut from months to weeks for apps that would otherwise have required substantial refactoring. Zero code changes for a significant share of preview workloads that previously blocked App Service adoption. Reduced infrastructure footprint as customers consolidated Windows Server VMs onto managed App Service Plans with zone redundancy and autoscaling built in. We are grateful to every preview customer whose feedback shaped this release. Pricing and licensing Managed Instance on Azure App Service is billed as a capability on top of the Premium v4 App Service Plan. There is no separate Managed Instance surcharge at GA you pay for the underlying Premium v4 compute you consume. Existing App Service reservations, savings plans, and any other Azure Benefit all apply, helping you optimize the total cost of ownership as you migrate. Getting started Getting started is straightforward: Assess your workload using Azure Migrate's updated App Service assessment, which now flags candidates ideal for Managed Instance. Create a new Web App using the Managed Instance on Azure App Service option in the Azure Marketplace, or via Bicep, Terraform, or the Azure CLI. Package your dependencies into a configuration bundle (a zip file plus a PowerShell install script) and store it in Azure Storage. Grant access via Managed Identity. Configure registry values, storage mounts, and networking to match your on-premises environment. Deploy your application using the same App Service deployment mechanisms you already know—ZIP deploy, GitHub Actions, Azure DevOps, or Visual Studio publish. Operate with confidence use RDP over Azure Bastion for deep troubleshooting when you need it, and Azure Monitor for everything else. Resources 📘 Managed Instance on Azure App Service documentation 🎥 Technical Deep Dive session recording from Build 2026 🧭 GitHub Repo with sample configuration scripts, webapp and guidance for Managed Instance on App Service workloads Looking ahead GA is a milestone, not a finish line. On our roadmap we're already working on: Deeper integration with Azure Migrate's web app discovery and assessment capabilities to help identify web apps suitable for migration to Managed Instance on App Service Enhanced migration tooling with easier dependency detection and one-click configuration bundle generation. Expanded Rollout to Azure Regions across 2026 and beyond. Continuously Release new features and capabilities to make migrations easier and faster than ever before We can't wait to see what you build and what you migrate. Managed Instance on Azure App Service is here to make your modernization journey faster, simpler, and more secure than ever. Welcome to GA. 🚀 The Azure App Service Team
