Engineering teams dread migrating from .NET Framework to .NET Core. However, autonomous coding agents are rapidly changing the previously known timelines. What once took months, teams are now finishing in as little as two weeks — with Devin.

Overview

Every engineering team has a migration story — late nights, brittle builds, endless dependency errors. Moving from .NET Framework to .NET Core is one of the most notorious of them all. But autonomous coding agents are rewriting the story entirely.

We’ve adapted Jimmy Bogard’s canonical migration guide — originally written for humans — into one for agents. The sections below detail how Devin automates each stage of a .NET Strangler Fig migration, step by step.

For clarity, we’ve simplified the example prompts and Playbooks; production usage should reference the Devin documentation on prompting and Playbooks for robust patterns.

Accelerating with Devin

The Strangler Fig migration relies on four things: visibility, planning, execution, and validation. Devin makes this possible through four core capabilities:

DeepWiki: Devin uses DeepWiki to generate always-up-to-date documentation and architecture diagrams, giving engineers instant visibility into controllers, dependencies, and framework-specific components.

Ask Devin: Devin queries its own knowledge through Ask Devin to produce context-rich migration plans, ranking controllers by complexity and mapping framework-specific dependencies automatically.

Local Machine: Devin executes migrations inside its own fully configured environment, providing a production-like runtime that’s completely isolated from developer machines.

Testing Setup: Devin validates every pull request in real time with built-in test harnesses, ensuring functional parity and stability at each stage of the Strangler Fig migration.

Planning

In Bogard's Guide original guide: Planning

The first step in the migration is to take inventory of all controllers and their actions, then estimate the complexity of moving each one to .NET Core by considering two factors: the number of action methods and the number of dependencies in each controller. This helps prioritize the simplest cases first.

A single Ask Devin prompt completes this task in seconds.

“Analyze all controllers in the codebase and create a migration complexity assessment. For each controller, count the number of action methods and identify their dependencies (services, external libraries, framework-specific features). Create a prioritized list ranking controllers from simplest to most complex for migration, considering factors like dependency count, use of legacy .NET Framework features, and action method complexity. Focus on the legacy MVC controllers that need to be migrated to .NET Core.”

Cataloging dependencies in the framework can be similarly automated by querying the .config files directly with Ask Devin.

Sharing Dependencies

In Bogard's Guide original guide: Sharing Dependencies

The next step is to build a shared library that both the legacy framework and the new Core app can use. This involves upgrading dependencies in the old framework and moving them into a shared project accessible to both environments.

Devin thrives on repetitive tasks like upgrading dependencies, refactoring structure, and moving code where it belongs. In just a few Sessions, Devin upgrades and relocates dependencies into a shared directory.

"Create a shared library project for the migration that can be used by both the legacy .NET Framework applications and the new .NET Core applications. Analyze the current dependencies in the legacy projects and identify which packages need to be upgraded to versions compatible with both frameworks. Create a new shared class library project and move common dependencies like Entity Framework, logging, and business logic components to this shared library. Update the package references in both legacy and modernized projects to use the shared library."

Controllers & Business Logic

In Bogard's Guide original guide:: Controllers & Business Logic

A .NET Framework application contains many controllers, each tied to business logic. Part of the challenge is that .NET Core requires different built-in bundling and minification from Framework.

The process isn’t identical every time, but it’s repeatable; this is where coding agents shine. Devin Playbooks help automate these repetitive tasks.

"First, migrate the controller to the .NET Core application without its corresponding business logic. This will require adding custom bundling and minification for the migrated controller. Then, check for dependencies that need migrating. If a dependency has versions that are compatible with .NET Core, simply upgrade. If not, surface this issue (with potential alternative service options) to the user and await further instructions. Finally, migrate business logic of the controller to the .NET Core app."

Views

In Bogard's Guide original guide: Views

.NET Core uses a different bundler from Framework. Devin can help adapt our code to the new bundler. Devin automates this switch to WebOptimizer in just a few Sessions.

"Add the LigerShark.WebOptimizer.Core NuGet package to the .NET Core project and configure WebOptimizer in application startup using a pipeline.""Translate existing MVC 5 bundle definitions (e.g. BundleConfig.cs) into WebOptimizer bundle definitions.”"Update _Layout.cshtml in the .NET Core app to reference the new WebOptimizer bundle paths.”"Link static assets from the old MVC 5 project into the Core project (.csproj with ).”

Session State

In Bogard's Guide original guide: Session State

During a Strangler Fig migration, the new Core app often needs to talk to the legacy Framework app. The .NET Core and .NET session states aren’t compatible (the old system handled locking and serialization automatically, but the new one doesn’t), so we use a remote app to facilitate communication amongst the two. This remote is also useful for the migration of the authentication service.

First, pinpoint every Session State usage across the .NET Framework codebase instantly using a Devin Session.

"Gather all usages of Session in the .NET Framework codebase. Then identify which session keys and their corresponding data types need to be shared with .NET Core. For each session key, determine its data type, serialization requirements, and usage patterns.”

Next, use a Devin Session to register each key and serializer.

"Add Microsoft.AspNetCore.SystemWebAdapters to the Global.asax file on the .NET side and configure session state sharing. Register all session keys with JSON serialization, set up the remote app server with proper API key configuration, and add the session server. For each session variable in the codebase, identify and register the appropriate key and data type. Modify session objects if needed to ensure they can be properly serialized and exposed via the API."

Then, register the adapters and client in .NET Core and make the remote session available to controllers.

"Add Microsoft.AspNetCore.SystemWebAdapters to the .NET Core project, configure the client with the appropriate API key, and register the JSON session serializer with the same keys used in the .NET application. Make the remote session available to controllers by adding RequireSystemWebAdapterSession() to the controller route configuration. Implement remote session access using System.Web.HttpContext.Current?.Session in controller actions."

Finally, update all usages of session state in the new core to use the System.Web adapters.

"Replace direct Session access in the migrated controllers with System.Web.HttpContext.Current?.Session access. Ensure session variables are accessed with the same keys and types as registered in the serializer configuration. Update any session-dependent views to use ViewBag or ViewData populated from the adapted session."

Conclusion

What once took months of manual work now takes weeks, accelerated by a coordinated fleet of Devins. If your team is staring down a migration like this, or just needs more hands on deck, consider hiring Devin.