.NET 8 and 9: plan the next release.

A .NET application can use a shared runtime on the server or include its own runtime in a self-contained deployment. Microsoft’s deployment guidance explains the difference. Updating the server runtime alone leaves a bundled copy unchanged; the application must be republished with an updated runtime.

Inventory the web application, background workers and scheduled executables. Check the deployed artefact and service configuration, rather than relying on the SDK version on a developer laptop. For containers, include the runtime image and the image build in the upgrade work.

Bring the repository, target framework, package dependencies and operating system into the review. Your developers can identify application changes while Intercube engineers assess runtime provisioning, service startup, networking and deployment configuration. That shared assessment turns a version deadline into work with clear owners.

Prepare a separate preview or staging environment with the proposed runtime and relevant services. Test authentication, database access, external APIs, uploads and background processing. Include application startup and readiness checks so a build that compiles is also a release that can serve real traffic.

Keep build tooling aligned with the target runtime and deployment model. Intercube build and deployment pipelines are included in the managed hosting plan, removing the need for a separate GitHub Actions deployment workflow or separate CI runner bill for that pipeline. Your developers can use that release route while our engineers prepare and operate its infrastructure.

For compatible applications and releases, we can arrange zero downtime deployments. Validate startup, session handling and worker handover first. Where a database or incompatible application change requires maintenance, agree the window, data handling and recovery route before the production release.

An upgrade should leave your team with a maintained environment and a repeatable release. Agree who follows runtime lifecycle dates, prepares patches, reviews service health and helps when the release fails. Engineering support is most useful when those engineers know the application’s infrastructure and deployment route.

Intercube can take on that hosting and operational work, with your developers responsible for application code and acceptance. If the application needs to move, our engineers prepare the target, rehearse the transfer and coordinate cutover. Migration to Intercube managed hosting is included at no additional cost.

If you need infrastructure expertise for an environment you already run, engage Intercube platform engineers for the upgrade and deployment work. Share the current deployment model and the target date; we can identify the hosting, runtime and pipeline changes your team needs to complete.