web.config to appsettings.json
Paste a web.config from an ASP.NET application. You get the appsettings.json an ASP.NET Core application reads, and for every other section a note on where it goes now: into Program.cs, with the code; to the host; to the library that owns it; or nowhere, because the thing it configured no longer exists. The file is converted in your browser and not sent anywhere.
appsettings.json
IISUrlRewrite.xml
The rewrite rules, unchanged. ASP.NET Core's rewriting middleware reads this file directly (see the Program.cs note).
What it converts
- appSettings and connectionStrings
- Become appsettings.json: settings as top-level keys (a:b keys become nested sections), connection strings under ConnectionStrings. Keys that look like secrets, and passwords inside connection strings, are blanked and listed for user secrets or the host.
- system.web
- Authentication, session, custom errors, request limits, globalisation, cookies, machineKey, modules and handlers each get a note saying what replaces them, with Program.cs code where the mapping is direct.
- system.webServer
- The rewrite section is kept as IIS rewrite XML, which ASP.NET Core loads as it is. Static content types, custom headers and request filtering limits become middleware options.
- Everything else
- mailSettings become a Smtp section; runtime binding redirects, trust levels and compiler settings are explained away; custom sections are listed for the library that owns them.
What it cannot do
- Web Forms
- Pages, controls and the page lifecycle do not exist on ASP.NET Core. A Web Forms site needs a different plan; the converter handles its configuration, not its pages.
- Custom sections
- Sections owned by libraries (log4net, Serilog, Unity, Quartz, Hangfire) are flagged, not converted: each library documents its own .NET configuration.
- Code
- Modules, handlers, membership providers and the application itself have to be rewritten against the new APIs. The notes say what each one becomes; writing it is the migration.
- Transforms
- Web.Release.config and other transforms are not applied. Convert the base file, then carry each environment's differences into appsettings.{Environment}.json.
The rest of the move
Configuration is the easy part. The packages the project depends on decide whether it can move at all: the NuGet upgrade planner checks each one for a release that supports .NET 8 or 10, and the packages.config converter prepares the project file.
Our .NET upgrade assessment does the whole exercise on the code, for a fixed price, and sets out the route before anything is changed. The .NET Framework page explains the support position that makes the move worth planning.
A web.config with twenty years of history in it?
Send us the summary. We will say what the configuration tells us about the application and what the move to ASP.NET Core is likely to involve.