If you're still running ASP.NET 4.8 in 2026, you're looking at a hard deadline. Microsoft will continue patching .NET Framework 4.8 indefinitely as part of Windows Server, but the framework receives no new features — and the ecosystem (NuGet packages, tooling, documentation) is moving on to .NET 10 LTS. The longer you wait, the more your application drifts from the supported path.

This guide is the migration playbook we hand customers asking how to move an ASP.NET 4.8 application to .NET 10 LTS, with no buzzwords and no skipped steps.

Why Migrate at All

Three forces make .NET 10 LTS the right destination in 2026:

The most expensive part of staying on .NET Framework isn't the runtime itself — it's the cost of building around an ecosystem that's moving on without you.

Step 1: Run the Compatibility Audit

Before changing any code, audit your application with the .NET Upgrade Assistant (free Microsoft tool):

dotnet tool install -g upgrade-assistant
upgrade-assistant analyze ./YourApp.sln

This produces a report covering:

• API surface used by your code (and whether it exists in .NET 10)
• NuGet packages with .NET 10 equivalents
• Files that need manual edits (web.config, Global.asax, etc.)
• Estimated effort score

Pay particular attention to the unsupported APIs list. The biggest blockers we see are:

• System.Web — replaced by ASP.NET Core's pipeline
• WebClient / HttpWebRequest — replaced by HttpClient
• WCF service host — limited support; gRPC is the modern replacement
• WebForms — no .NET Core port; pages must be rewritten in Razor/MVC/Blazor
• AppDomain.CreateDomain — not available
• System.Drawing.Common on Linux — Windows-only on .NET 7+

If your app heavily uses WebForms, expect a rewrite (not a port). If it's ASP.NET MVC 5 with EF6, expect ~70% code reuse.

Step 2: Choose the Migration Approach

💡 Three patterns, picked by application size and risk tolerance.

A) Big-Bang Rewrite

Stop new feature work on the legacy app. Build the .NET 10 version greenfield. Cut over in one weekend.

When this fits: small apps (<20K LOC), or apps with substantial existing test coverage. High risk, fastest cutover.

B) Side-by-Side (Strangler Fig)

Run .NET Framework 4.8 and .NET 10 simultaneously. Use a reverse proxy (YARP, nginx, IIS URL Rewrite) to route specific URLs to the new app. Migrate routes one at a time.

When this fits: medium-to-large apps (20K–200K LOC). Lower risk; takes 3–12 months but you ship continuously.

C) In-Place Upgrade

Use the Upgrade Assistant to convert .csproj files, then iterate on compilation errors. Keep the same codebase.

When this fits: ASP.NET MVC 5 + EF6 apps without heavy WebForms. Moderate risk; usually 1–3 months.

All three approaches run cleanly on Adaptive's hosting, which supports ASP.NET 2.0 through 4.8 alongside .NET 7/8/9/10 LTS on every plan. You can host the legacy 4.8 app and the new .NET 10 app on the same plan during cutover — Developer plan includes 2 websites, Business 5, Professional 10.

Step 3: Convert Project Files

ASP.NET 4.8 projects use the verbose pre-SDK .csproj format. .NET 10 uses the SDK-style format.

Before (.NET Framework 4.8):

<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <!-- 50 more lines -->
  </PropertyGroup>
</Project>

After (.NET 10):

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

The Upgrade Assistant does this conversion automatically, but expect to clean up by hand: package references move from packages.config to <PackageReference>, content includes become globs, and assembly redirects disappear entirely.

Step 4: Rewrite the HTTP Pipeline

The biggest conceptual shift. ASP.NET 4.8 uses Global.asax + HttpModule + HttpHandler. ASP.NET 10 LTS uses middleware.

Before (.NET Framework 4.8 — Global.asax.cs):

public class MvcApplication : HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        // Custom request logic
    }
}

After (.NET 10 — Program.cs):

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
builder.Services.AddDbContext<AppDbContext>(opt =>
    opt.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

var app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();

app.Use(async (ctx, next) =>
{
    // Custom request logic (replaces Application_BeginRequest)
    await next();
});

app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
app.Run();

The mental model: each app.UseX() call is the new equivalent of an HttpModule. Order matters — middleware runs top-to-bottom.

Step 5: Convert Configuration

ASP.NET 4.8 uses web.config with <appSettings> and <connectionStrings> sections. .NET 10 uses appsettings.json (and appsettings.{Environment}.json).

Before (web.config):

<connectionStrings>
  <add name="Default" connectionString="Server=db;Database=YourApp;..." />
</connectionStrings>
<appSettings>
  <add key="StripeApiKey" value="sk_test_..." />
</appSettings>

After (appsettings.json):

{
  "ConnectionStrings": {
    "Default": "Server=db;Database=YourApp;..."
  },
  "Stripe": {
    "ApiKey": "sk_test_..."
  }
}

Don't commit secrets — use dotnet user-secrets in development and environment variables (or Azure Key Vault / AWS Secrets Manager) in production. On Adaptive plans, the Plesk Control Panel exposes environment variable configuration per IIS site.

Step 6: Migrate Entity Framework 6 → EF Core 10

EF6 and EF Core have similar APIs but different runtime characteristics. The 80% case is straightforward:

// EF6 (Framework)
public class AppContext : DbContext
{
    public AppContext() : base("name=Default") { }
    public DbSet<Order> Orders { get; set; }
}

// EF Core 10
public class AppContext : DbContext
{
    public AppContext(DbContextOptions<AppContext> options) : base(options) { }
    public DbSet<Order> Orders { get; set; }
}

// In Program.cs:
builder.Services.AddDbContext<AppContext>(opt =>
    opt.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

The 20% case (lazy loading, complex inheritance hierarchies, .Include chains) requires more attention. See our EF Core performance guide for the patterns we apply.

🚀 Real performance gains worth measuring: EF Core 10 with SQL Server 2025 (which every Adaptive plan includes, alongside SQL Server 2022) supports native JSON columns, vector search, MERGE, and batched ExecuteUpdate. EF6 can't use any of these. The performance gap on a busy app is 3–10×.

Step 7: Replace WebForms (If You Have Them)

There's no .NET Core port for WebForms. The migration paths in order of preference:

Most teams find Razor Pages the easiest porting target — one .cshtml + one .cshtml.cs per page, similar to .aspx + .aspx.cs.

Step 8: Test Strategy

Three layers of testing during migration:

1. Compatibility tests — port your existing unit tests; they'll mostly work as-is
2. Behavioral parity — automated UI tests (Playwright, Selenium) hitting both old and new versions with the same inputs, comparing outputs
3. Load tests — k6 or NBomber against the new version; you should see significantly better throughput and lower p95 latency

We typically see 3–10× throughput improvements on migrated apps just from the runtime change — before any architectural improvements.

Step 9: Deploy to Production

ASP.NET 4.8 deployment to IIS uses Web Deploy + web.config. .NET 10 deployment uses Web Deploy (or dotnet publish + folder copy) with the ASP.NET Core Module v2 (ANCM) in IIS.

The good news: Adaptive's hosting is preconfigured for both. ANCM is installed on Windows Server 2022 + IIS 10. Your web.config for .NET 10 is auto-generated by dotnet publish and looks like:

<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\YourApp.exe" stdoutLogEnabled="false" hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Set hostingModel="inprocess" (default) for the best performance — the .NET runtime runs inside IIS's worker process.

Side-by-Side Hosting on Adaptive

The biggest practical advantage of Adaptive's hosting plans for migrations: every plan supports both .NET Framework and .NET 10 LTS simultaneously, with dedicated IIS Application Pools per site.

You can host the legacy 4.8 app and the new .NET 10 version on the same plan, route traffic between them via DNS or reverse proxy, and migrate piece-by-piece without buying separate infrastructure.

Frequently Asked Questions

How long does an ASP.NET 4.8 → .NET 10 migration typically take?

For a typical MVC 5 + EF6 application (30K LOC, no WebForms), 4–8 weeks of focused engineering work. WebForms-heavy applications take significantly longer because the views must be rewritten. Side-by-side migrations stretch longer in calendar time but keep continuous releases.

Can I run .NET Framework 4.8 and .NET 10 on the same server?

Yes. IIS happily hosts multiple application pools, each pinned to a different .NET runtime. On Adaptive's hosting plans, every plan ships with both runtimes installed; you select per-app.

What's the hardest part of the migration?

For most apps: the HTTP pipeline rewrite (HttpModule → middleware) and any custom configuration providers. For WebForms apps: rewriting the views — this is genuinely a rewrite, not a port.

Does EF6 code work without changes in EF Core?

Mostly. DbContext, DbSet, LINQ queries, and migrations port with minor changes. The big gotchas: lazy loading defaults differ, complex .Include chains may need AsSplitQuery, and any code using ObjectContext (the EF6 underlying type) must be rewritten.

Should I migrate to .NET 8 LTS or .NET 10 LTS?

.NET 10 LTS for new projects in 2026 — it's supported until November 2028 and has the latest performance work. .NET 8 LTS is fine if you're shipping in the next few months and need a stable target (.NET 8 has mainstream support until November 2026). See our .NET 10 LTS hosting guide for the full feature set.

Will my SQL Server database need to change?

No schema changes are required. EF Core 10 connects to SQL Server 2008+ without modification. However, you'll unlock more performance if you upgrade to SQL Server 2025 or 2022 (every Adaptive plan includes both): Query Store, ledger tables, native JSON (SQL Server 2025), Always Encrypted with enclaves.

What about WCF services?

There's CoreWCF for service hosting, but for new architectures we recommend gRPC (HTTP/2-based, type-safe, mature .NET tooling) or plain ASP.NET Core APIs. Migration effort varies — if your WCF surface is small (a few services), gRPC is straightforward; if you have dozens of service contracts, plan a longer transition.

Already running .NET Framework 4.8 somewhere else? Your application is portable — publish your build, restore your SQL Server BACPAC, point DNS at our infrastructure. The 30-Day Money-Back Guarantee for new accounts means you can validate the move risk-free. See .NET 9 hosting for the current-LTS guide, or .NET 10 LTS hosting for the new long-term-support target.