Teaching old .NET apps new tricks: what agentic modernization actually changes for engineers
Every team carrying a legacy .NET app knows the upgrade is not the hard part. Bumping the target framework is an afternoon. The hard part is everything the codebase has quietly grown attached to over a decade: the dependency that only runs on Windows, the data flow nobody fully remembers, the component that breaks in production if you look at it wrong. That is the work modernization has always stalled on, and the pressure to do it anyway keeps climbing.
The session opens with a Forrester figure pinned to a big circle: 94% of IT leaders called app modernization an investment priority in the next 6 to 12 months. The framing on the slide cuts to the engineer's reality underneath that number, "But, you grapple with the technical debt." That tension is the whole reason this session exists.
That is also the work Jeff Fritz, Nish Anil and Hazem El-Hammamy put an AI agent against in their Build 2026 breakout, Using AI tools to teach old apps new tricks (BRK220). The session shows GitHub Copilot's modernization capabilities taking on the parts of the job engineers dread: reading a large codebase, mapping its dependencies, planning the upgrade, and refactoring safely at scale. We watched it from the perspective of the layer we work in, document generation and processing, and the most useful takeaway is about what the agent surfaces, not just what it rewrites.
The interesting part is the dependency map
Jeff's slice of the session is the practical .NET developer view: point the agent at a real legacy app and let it do the untangling. Analyzing a codebase and tracing data flows by hand is the step that makes modernization a multi-quarter project, because it is slow and easy to get wrong. An agent that can walk the whole portfolio, build the dependency graph, and flag what will not survive the move compresses that step from weeks to a working session.
What it flags matters more than the speed. When the agent maps dependencies, it is looking for the things that block the target environment, and a specific category shows up again and again in older .NET apps: code that depends on the machine it runs on. The classic example is document handling. A surprising amount of legacy business logic produces PDFs, spreadsheets, and Word files through Office automation, COM interop, or a print driver that assumes a desktop. That code worked fine on a Windows server in 2015. It does not move to a Linux container or an Azure Function, because there is no Office to automate and no COM to call. The agent will surface it as a blocker. The question is what you refactor it into.
Refactor toward dependencies that survive the move
This is the moment in modernization where the document layer gets decided, and it is where our work fits. The whole point of the move is to land in an environment that scales and deploys cleanly: containers, serverless, cross-platform CI. So the replacement for machine-bound document code has to be a managed .NET library that carries none of those assumptions.
When the blocker is PDF generation, IronPDF renders PDFs from HTML in pure .NET with no Office and no interop, so the refactored code runs in the same container the rest of the modernized app is moving to. When it is spreadsheet automation, IronXL reads and writes Excel files without Office Interop or COM, which is exactly the dependency the agent flagged. The same holds for Word generation with IronWord, and for the scanned-document and image-to-text paths that legacy apps often handle with fragile tooling, IronOCR keeps that step in-process. Each one is a drop-in target for the refactor: the agent identifies the COM or interop call, and the new code is a library that behaves the same on every platform.
The reason this pairs well with agentic refactoring is that the replacement is deterministic. An agent can rewrite a call site with confidence when the new API is a normal .NET library that returns a real file, runs headless, and needs no host configuration. There is nothing to install on the target, nothing to license per machine, nothing that depends on the OS. That is the property that lets "refactor safely at scale" actually be safe.
A concrete shape
Put it together and the modernization loop looks like this. The agent analyzes the legacy app and builds the dependency map. Among the blockers, it flags a reporting module that generates invoices through Office automation, the kind of code that will fail the moment the app runs in a container. The upgrade plan calls for replacing it. The agent refactors the call sites to a managed library, IronPDF for the invoice PDFs, IronXL for the data export, and the module now runs in the same Linux container as everything else. The app moves, and the document layer moves with it instead of pinning it to Windows.
That is the difference between modernizing the framework and modernizing the app. The framework upgrade is mechanical. The app only really moves when its dependencies do, and the document layer is one of the most common things holding it back.
Where to go next
The session points to the GitHub Copilot modernization documentation and the private preview signup for the command center, rulebooks, and mainframe capabilities. Microsoft is continuing the thread with the virtual .NET Agentic Modernization Day on June 16, and the full Build feature list covers everything announced. The related breakout Modernize intelligent apps and agents with .NET that scale as you grow (OD801) is worth pairing with this one.
If you are planning a modernization pass, it is worth knowing which of your blockers are document-related before the agent finds them. IronPDF, IronXL, IronWord, and IronOCR all ship free trials, or the full set as the Iron Suite, so you can have the refactor target ready when the dependency map comes back. The agent can teach the old app a lot of new tricks. Giving it somewhere clean to land is still the engineer's call.
Get started for FREE
Get started for FREE
Book Free Live Demo
No credit card or account creation required
