Azure offers several sensible ways to run a .NET application. That choice is useful, but it can also turn an early architecture discussion into a catalogue of services. Teams compare product names before agreeing what the application must do, how it fails and who will operate it.
A better starting point is the workload. A customer portal with predictable traffic, a queue-driven document processor and an application that depends on Windows-specific components have different needs. The hosting decision should make those needs easier to satisfy while leaving the team enough time to improve the product. Choosing a platform is also choosing a set of operational responsibilities.
Write a workload profile first
Describe how requests arrive, how long work takes and where state lives. Record normal traffic, expected peaks, background processing, external integrations and the consequences of interruption. A system can have few users but demanding workloads: a handful of staff generating large reports may place more pressure on a database than a popular informational website.
List compatibility constraints honestly. Does the application require a particular operating system, local file access, a third-party component or an existing identity arrangement? Modern .NET and older .NET Framework applications do not have identical portability characteristics. Containerising a dependency does not automatically make it compatible with every platform.
Include the people who will support the service. If the team is comfortable operating web applications but has little experience running clusters, that is a relevant architectural fact. The preferred platform should fit current requirements and credible growth, with a clear explanation of what would justify reconsidering it.
Consider App Service for conventional web workloads
Azure App Service provides managed hosting for web applications and APIs. Microsoft describes the supported application stacks and platform capabilities in its App Service overview. For a conventional .NET web application, it is often a useful option to evaluate early because the team can concentrate on application behaviour without managing the underlying virtual machines directly.
That convenience does not remove application operations. You still need suitable capacity, identity configuration, secrets management, monitoring and a deployment process. Check the features and limits of the selected plan, including any release strategy that depends on deployment slots. Do not design around a feature before verifying that the intended plan supports it.
Review the complete application rather than only its HTTP frontend. Background tasks, uploaded documents and shared state need explicit homes. Local storage assumptions that worked on one server can become unreliable when the application scales across instances or the platform replaces an instance.
Consider Container Apps for containerised services and workers
Azure Container Apps is worth assessing when the application is packaged as containers and benefits from independently scaled web services or background processing. Its lifecycle is organised around revisions, and its scaling behaviour can be configured around supported triggers. Microsoft's documentation covers revisions and scaling rules.
For a hypothetical document-processing product, the customer API and extraction worker may have different demand patterns. Keeping the worker separate can allow processing capacity to respond to queued work without scaling the frontend in exactly the same way. The value comes from the workload boundary, not merely from putting two components into containers.
Test startup behaviour, processing duration and dependency limits. Scaling application instances cannot fix a database that has reached its connection limit. Likewise, scaling down requires confidence that work can stop or resume correctly. Configure minimum capacity and other scaling settings around the service experience you need rather than assuming that the lowest idle cost is always the right goal.
Use AKS when Kubernetes control has a clear purpose
Azure Kubernetes Service offers a different level of control over the deployment environment. It becomes relevant when the team needs Kubernetes capabilities and has a reason to own the associated operational decisions. Custom scheduling, specific platform components or an established organisation-wide Kubernetes operating model can all influence that decision.
The comparison should include the work of operating the platform: upgrades, networking, access policies, workload isolation, resource allocation and incident diagnosis. A managed control plane does not mean every responsibility inside the cluster becomes Microsoft's responsibility. The application team still needs an agreed operating model.
Microsoft's container service comparison is useful for checking differences across networking, resource allocation and scaling. Use it to test a shortlist against requirements. Avoid selecting a cluster simply because the application may eventually grow; growth alone does not define which control the team will need.
Keep virtual machines in the comparison where constraints require them
Some applications need operating-system access or dependencies that are difficult to accommodate on a managed application platform. A virtual machine can provide a practical migration destination while those constraints are addressed. That can be a deliberate stage in a roadmap rather than evidence that the migration has failed.
Make the operational cost visible. Someone must own patching, configuration, backup arrangements, capacity and recovery. Record which tasks are automated and which still depend on a person. Include the time spent maintaining that arrangement when comparing it with a managed option.
If a virtual machine is a temporary destination, define the condition for leaving it. “Modernise later” is not a plan. A more useful condition is removing a specific dependency, separating file storage or replacing a scheduled component so the workload can run on the intended platform.
Design the data and network path alongside compute
The hosting service is one part of the system. Place databases, storage, identity and integration endpoints into the same architecture discussion. Understand latency, network access, backup requirements and the consequences of a dependency becoming unavailable. A fast frontend cannot compensate for an inefficient query path or a fragile third-party integration.
Decide how the application authenticates to its dependencies and which connections are publicly reachable. Verify the selected service's networking capabilities and operational implications before committing to the design. Keep the explanation understandable: which component can call which service, under what identity, and for what purpose.
Also consider where customer data may be processed and retained. Requirements vary by business and contract, so record them with the responsible stakeholders. Do not assume that selecting a region resolves every data-handling question across logging, backups and downstream services.
Compare the full operating cost
Estimate a typical month, a busy month and the additional cost of a release or recovery event. Include non-production environments, databases, storage, network traffic, monitoring and the engineering time required to operate the setup. Current service prices and available plans should be checked when preparing the estimate; a generic article cannot supply a reliable quote for an unknown workload.
Use a small proof of concept to investigate the biggest uncertainty. Deploy a representative slice, run realistic work, exercise a failure and observe the result. The test should answer a decision question, such as whether startup time is acceptable or whether a dependency behaves correctly under the chosen identity model.
Record the decision in a short architecture note: requirements, options considered, chosen service, trade-offs and review triggers. Worktechlabs can help assess .NET and Azure hosting alongside a migration roadmap, so the platform supports the next useful release as well as the longer-term plan.
