Application Containerization to Azure

A containerization assessment with a written estimate, Dockerfiles and a local compose setup for each in-scope component, an Azure Container Registry with a build pipeline that tags and pushes images on every merge, configuration and secrets moved into environment variables and Azure Key Vault through managed identity, deployment to Azure Container Apps, App Service, or your existing AKS cluster with health checks and logging, acceptance testing, cutover with rollback, and a runbook with a recorded handover. The code itself stays as it is, apart from the small changes containers require.

Work is billed time and materials at $175 per hour. The assessment produces a written estimate for the whole engagement before build begins, and any scope change is priced in writing before we do the work — out-of-scope work never starts without your approval. Nobody at IT Partner earns a sales commission, so nobody is paid more when the invoice grows. Azure consumption is separate and billed by Microsoft; the assessment estimates it.

About 4 weeks for a typical single application: assessment in week one, Dockerfiles and the build pipeline in weeks one and two, configuration and secrets in weeks two and three, Azure deployment and testing in week three, cutover and handover in week four. Applications with several components, Windows containers, or an undocumented deployment take longer, and the assessment says how much.

As little as possible, and only where a container requires it: reading configuration from environment variables instead of a hard-coded file, writing files to a mounted path instead of a local folder, logging to standard output, and handling a graceful shutdown signal. Those changes are listed in the assessment before you approve the estimate. Framework upgrades, refactoring, and new features are not part of this service — that is modernization, which we sell separately.

Usually, yes — as a Windows container on a Windows Server Core base image with the .NET Framework runtime. That decision narrows where it can run: Azure Container Apps supports Linux images only, so the practical targets are App Service for Windows containers, which needs its own Premium v3 plan, or a Windows node pool on AKS. The assessment gives you both the containerized-as-is cost and the cost after moving to modern .NET on Linux, because for some applications the modernization pays for itself in hosting alone.

By what the application needs, not by fashion. Azure Container Apps is the default for Linux workloads: it runs your image on a Kubernetes-based platform Microsoft operates, with scaling, ingress, revisions, and a consumption billing model, and no cluster to upgrade. App Service runs custom containers with familiar slots and plans, and is the home for Windows containers. AKS is the target when you already operate a cluster or genuinely need the Kubernetes API — operators, DaemonSets, a service mesh, node-level control. The assessment recommends one and explains why; the images are the same whichever you pick, so changing your mind later is a deployment change, not a rebuild.

Out of the image and out of the repository. Non-secret settings become environment variables set per environment on the hosting platform. Secrets — connection strings, API keys, certificates — go into Azure Key Vault and are read through a managed identity, so the container never holds a credential and nothing needs rotating inside an image. The build pipeline authenticates to Azure the same way, through OIDC workload identity federation, so there is no service-principal secret in the pipeline either.

It stays outside the container. If it is already on Azure SQL or a managed service, the containerized application connects to it through a connection string in Key Vault. If it is on the same server as the application, the assessment recommends where it should live — usually Azure SQL Database or SQL Managed Instance — and that migration is scoped as a separate engagement rather than hidden inside this one. For local development the compose file runs a database container, which is exactly where containerized databases belong.

Yes, as separate ones. A container should run one process, so a scheduled task becomes a Container Apps job or a scheduled pipeline, and a background Windows service becomes its own container image with the same code base. The assessment lists each background component and what it becomes, so the estimate covers all of them rather than just the web front end.

That is half the point. The compose file starts the application and its local dependencies — a database container, a cache — with one command on Windows, macOS, or Linux, using the same image the pipeline builds. A new developer's first day stops being a two-day environment setup, and 'works on my machine' stops being an argument, because everyone's machine runs the same image.

For modern .NET, the SDK can publish a container image directly with the PublishContainer target — no Dockerfile — and where that produces exactly what you need we use it, because there is less to maintain. A Dockerfile is still the right tool when the build needs native dependencies, custom base images, Windows containers, or anything beyond a standard .NET publish, and for Java, Node.js, and Python applications. The assessment chooses per component and the runbook documents whichever it is.

Your team, with the pipeline doing the work: rebuilding on a schedule or on a base-image update pulls Microsoft's latest patched runtime image, and vulnerability scanning in Azure Container Registry — where your Defender for Cloud licensing includes it — tells you when an image needs rebuilding. The runbook covers the procedure. If you would rather not own it, ongoing operations are available separately.

No, and the difference matters for the price. Containerization changes how the application is packaged and deployed; the code and framework stay the same, which is why it fits in about four weeks. Modernization changes the code — upgrading .NET Framework to modern .NET, moving data to Azure SQL, replacing components that no longer have supported runtimes — and takes longer. Containerization is often a step inside modernization, and if the assessment shows that your real problem is an end-of-support framework, we will point you at the modernization service rather than containerize an application you will still have to rewrite.

Yes. The first application establishes the patterns — Dockerfile conventions, the pipeline template, the Key Vault layout, the target environment — and each additional one is estimated separately and is usually cheaper because the patterns exist. If you have a portfolio, the assessment can cover all of them at once and produce a per-application plan so you can sequence the work.

You own it: the Dockerfiles, pipeline, and Azure resources are in your repository and your subscription, and the runbook and recorded handover cover build, deploy, rollback, and base-image updates. Enhancements, further applications, and help when something breaks are hourly work at the same $175 rate, estimated in writing first; ongoing monitoring and maintenance are available as a separate managed service. There is no proprietary framework and no dependence on us afterward.