Best practice for using Program.cs vs Startup.cs in .NET 8/10 for new and migrated projects

Hi @Soumyadip Majumder ,

Thanks for reaching out.

For a new ASP.NET Core project in .NET 8 or later, I would generally lean toward following the current template style and using Program.cs with the minimal hosting model. That is the direction the platform has taken since .NET 6, and for many new apps it tends to keep the startup flow simpler and easier to follow.

That said, using Program.cs does not mean everything has to live in one big file. In practice, it often works well to keep Program.cs as the composition root and move the detailed setup into extension methods or separate modules as the app grows. That usually gives you the benefits of the modern hosting model without necessarily ending up with a very large startup file.

For an existing project that already uses Startup.cs, I do not think there is usually a strong need to rewrite it just for the sake of matching the new style. Microsoft’s migration guidance is fairly clear that apps moving to .NET 6 or later do not have to adopt the minimal hosting model right away, and the older Startup pattern is still supported. If the current structure is clean, understandable, and working well, keeping it is often perfectly reasonable.

So for migrated projects, I would usually only consolidate into Program.cs if there is a real payoff, such as simplifying the startup path, aligning the project with current templates, or making onboarding easier for the team. Otherwise, a low-risk migration is often the better engineering choice than a structural rewrite that does not really change behavior.

If you want a middle ground, you can move to the modern hosting model and still keep a Startup-style class for a while by calling it explicitly from Program.cs, for example:

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

The sample above is only for reference, so you may need to adjust it based on your application structure, dependency injection setup, middleware order, endpoint mapping, and any third-party containers or hosting customizations you use.

From a maintainability and team perspective, I would focus less on whether the file is named Startup.cs or Program.cs, and more on whether the startup path is easy to read and change safely. A small or medium app can often be perfectly fine with a single Program.cs. A larger app will usually benefit from extracting service registration and middleware setup into well-named extension methods or feature-level modules instead of letting Program.cs grow too much.

Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.