DEV Community: DanielG

Docker and Ansible: Setting Up a Reproducible On-Prem Stack in a Weekend

DanielG — Thu, 09 Apr 2026 17:13:08 +0000

Docker and Ansible: Setting Up a Reproducible On-Prem Stack in a Weekend

You have decided to move off the cloud. The spreadsheets convinced your CTO, the timeline is approved, and now someone — probably you — has to actually build the infrastructure. The question is not whether Docker and Ansible are the right tools. They are, for 90% of Nordic SMBs running steady-state workloads. The question is how to set them up so that your on-prem stack is reproducible, maintainable, and not a snowflake that only one person understands.

I recently stood up exactly this kind of Docker Ansible on-premise setup for a client migrating off Azure — a .NET backend API, Angular frontends, PostgreSQL, and a full monitoring stack. Four VMs, zero cloud dependencies, and the whole thing was reproducible from a single ansible-playbook command within a weekend. Here is how.

Reference Architecture: The 4-VM Layout

Before writing a single line of YAML, you need a target architecture. Here is the layout I use for small-to-mid workloads — and it is the same architecture in my Cloud Exit Starter Kit:

VM	Role	What Runs Here
DEV	Development environment	App containers (dev config), dev database
TEST	Staging / QA	App containers (staging config), test database, automated test runners
PROD	Production	App containers (prod config), production database, Nginx reverse proxy with SSL
TOOLS	Shared tooling	Harbor (container registry), SonarQube, Grafana + Loki + Promtail, CI/CD agents, Vaultwarden

This separation is deliberate. DEV and TEST can break without touching production. TOOLS is isolated so that a misbehaving SonarQube scan does not eat your production server's RAM. And every VM is configured identically at the OS level — same packages, same users, same SSH hardening — because Ansible makes that trivial.

Why not one big server? Because isolation is cheap and debugging resource contention on a shared host is not. Four modest machines (or VMs on a hypervisor) give you clear boundaries and simpler troubleshooting.

Hardware and OS Selection

OS: Rocky Linux 9. It is the CentOS successor with a 10-year support lifecycle. Ubuntu 22.04 LTS is also fine — pick whichever your team already knows. I chose Rocky because the client's sysadmin had RHEL experience, and the ecosystem (SELinux policies, RPM packaging) matched their existing tooling.

Hardware: For a typical Nordic SMB, each VM needs 4–8 CPU cores, 16–32 GB RAM, and 500 GB SSD. Budget around €5,000 per server if buying physical hardware, or use an existing hypervisor. Four Dell PowerEdge T350s or equivalent run about €20,000 total and will last 5+ years.

Networking: A 1 Gbps internal switch at minimum. All four VMs should be on the same subnet with a dedicated VLAN for inter-service traffic. Nginx on the PROD VM handles external traffic with SSL termination.

Step-by-Step: Provisioning with Ansible

Directory Structure

A clean Ansible layout prevents the "where did I put that playbook" problem at 2 AM:

infrastructure/
├── ansible.cfg
├── inventory/
│   ├── hosts.yml
│   └── group_vars/
│       ├── all.yml
│       ├── dev.yml
│       ├── test.yml
│       ├── prod.yml
│       └── tools.yml
├── playbooks/
│   ├── site.yml          # runs everything
│   ├── common.yml        # base OS config
│   ├── docker.yml        # Docker + Compose install
│   ├── monitoring.yml    # Grafana/Loki/Promtail
│   ├── registry.yml      # Harbor setup
│   └── app-deploy.yml    # application deployment
└── roles/
    ├── base/             # SSH hardening, firewall, packages
    ├── docker/           # Docker CE + Compose plugin
    ├── nginx/            # reverse proxy + SSL
    ├── monitoring/       # Grafana stack
    └── harbor/           # container registry

Inventory

# inventory/hosts.yml
all:
  children:
    dev:
      hosts:
        dev-01:
          ansible_host: 10.0.1.10
    test:
      hosts:
        test-01:
          ansible_host: 10.0.1.20
    prod:
      hosts:
        prod-01:
          ansible_host: 10.0.1.30
    tools:
      hosts:
        tools-01:
          ansible_host: 10.0.1.40

Base Role: Making Every Server Identical

The base role handles everything that should be the same on every VM:

# roles/base/tasks/main.yml
- name: Set timezone
  community.general.timezone:
    name: Europe/Copenhagen

- name: Install base packages
  ansible.builtin.dnf:
    name:
      - vim
      - curl
      - wget
      - htop
      - git
      - firewalld
      - fail2ban
    state: present

- name: Harden SSH - disable password auth
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "^#?PasswordAuthentication"
    line: "PasswordAuthentication no"
  notify: restart sshd

- name: Harden SSH - disable root login
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "^#?PermitRootLogin"
    line: "PermitRootLogin no"
  notify: restart sshd

- name: Enable and start firewalld
  ansible.builtin.systemd:
    name: firewalld
    enabled: true
    state: started

Nothing clever here. That is the point — it should be boring and obvious.

Docker Role: Install and Configure

# roles/docker/tasks/main.yml
- name: Add Docker CE repository
  ansible.builtin.command:
    cmd: dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    creates: /etc/yum.repos.d/docker-ce.repo

- name: Install Docker CE and Compose plugin
  ansible.builtin.dnf:
    name:
      - docker-ce
      - docker-ce-cli
      - containerd.io
      - docker-compose-plugin
    state: present

- name: Add deploy user to docker group
  ansible.builtin.user:
    name: "{{ deploy_user }}"
    groups: docker
    append: true

- name: Enable and start Docker
  ansible.builtin.systemd:
    name: docker
    enabled: true
    state: started

After running this across all four VMs, every server has Docker and the Compose plugin. No manual SSH-ing, no "I forgot to install Compose on the test server" at 11 PM.

Deploying with Docker Compose

Each environment gets its own docker-compose.yml, but they share a common structure. Here is a simplified PROD example:

# docker-compose.prod.yml
services:
  api:
    image: harbor.internal/myapp/api:${APP_VERSION}
    restart: unless-stopped
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ConnectionStrings__Default=${DB_CONNECTION_STRING}
    networks:
      - app-network
    deploy:
      resources:
        limits:
          memory: 2G

  frontend:
    image: harbor.internal/myapp/frontend:${APP_VERSION}
    restart: unless-stopped
    networks:
      - app-network

  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=${DB_NAME}
      - POSTGRES_USER=${DB_USER}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    networks:
      - app-network

  nginx:
    image: harbor.internal/myapp/nginx:${APP_VERSION}
    restart: unless-stopped
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - /etc/letsencrypt:/etc/letsencrypt:ro
    networks:
      - app-network

volumes:
  pgdata:

networks:
  app-network:
    driver: bridge

The DEV and TEST variants differ only in environment variables and resource limits. The Cloud Exit Starter Kit includes production-ready versions of these Compose files with health checks, logging drivers configured for the Loki stack, and proper volume backup hooks — the kind of details you only remember after losing data once.

Ansible deploys the Compose stack with a straightforward playbook:

# playbooks/app-deploy.yml
- name: Deploy application
  hosts: "{{ target_env }}"
  vars_files:
    - "../inventory/group_vars/{{ target_env }}.yml"
  tasks:
    - name: Copy docker-compose file
      ansible.builtin.template:
        src: "docker-compose.{{ target_env }}.yml.j2"
        dest: "/opt/myapp/docker-compose.yml"

    - name: Pull latest images
      ansible.builtin.command:
        cmd: docker compose pull
        chdir: /opt/myapp

    - name: Deploy with zero downtime
      ansible.builtin.command:
        cmd: docker compose up -d --remove-orphans
        chdir: /opt/myapp

Deploy to any environment with:

ansible-playbook playbooks/app-deploy.yml -e target_env=prod

Secrets Management Without Cloud KMS

This is where people overcomplicate things. You do not need HashiCorp Vault for a 4-VM setup. Here is what works:

Ansible Vault for infrastructure secrets. Encrypt your group_vars files that contain passwords and API keys:

ansible-vault encrypt inventory/group_vars/prod.yml

Now your database passwords, registry credentials, and API keys are encrypted at rest. Decrypt at deploy time with a password file or prompt.

.env files on each host, deployed by Ansible and readable only by the deploy user:

- name: Deploy environment file
  ansible.builtin.template:
    src: env.j2
    dest: /opt/myapp/.env
    owner: "{{ deploy_user }}"
    mode: "0600"

Vaultwarden on the TOOLS VM for shared team credentials (not application secrets). This gives your team a self-hosted Bitwarden-compatible password manager.

When NOT to do this: if you have compliance requirements for secret rotation and audit trails, invest in HashiCorp Vault. For most Nordic SMBs running internal applications, Ansible Vault plus locked-down .env files is sufficient and dramatically simpler.

CI/CD Pipeline Changes When Your Infra Is Local

Your CI/CD pipeline needs three changes when moving from cloud to on-prem:

1. Self-Hosted Build Agents

Cloud CI/CD (Azure DevOps hosted agents, GitHub Actions runners) cannot reach your internal servers. Install self-hosted agents on the TOOLS VM:

# roles/ci-agents/tasks/main.yml
- name: Create agent directory
  ansible.builtin.file:
    path: /opt/azdevops-agent
    state: directory
    owner: "{{ deploy_user }}"

- name: Download and configure Azure DevOps agent
  ansible.builtin.shell: |
    curl -fsSL https://vstsagentpackage.azureedge.net/agent/{{ agent_version }}/vsts-agent-linux-x64-{{ agent_version }}.tar.gz | tar xz
    ./config.sh --unattended \
      --url https://dev.azure.com/{{ azdo_org }} \
      --auth pat --token {{ azdo_pat }} \
      --pool {{ agent_pool }} \
      --agent tools-01
  args:
    chdir: /opt/azdevops-agent
    creates: /opt/azdevops-agent/.agent

2. Push to Your Private Registry

Replace docker push myregistry.azurecr.io/... with:

docker tag myapp/api:latest harbor.internal/myapp/api:${BUILD_NUMBER}
docker push harbor.internal/myapp/api:${BUILD_NUMBER}

Harbor on the TOOLS VM gives you vulnerability scanning, access control, and image replication — features that Azure Container Registry charges extra for.

3. Deploy via Ansible from the Pipeline

Your pipeline's deploy step becomes an Ansible call instead of az webapp deploy:

# azure-pipelines.yml (deploy stage)
- stage: Deploy
  jobs:
    - job: DeployProd
      pool: 'self-hosted-pool'
      steps:
        - script: |
            ansible-playbook playbooks/app-deploy.yml \
              -e target_env=prod \
              -e app_version=$(Build.BuildNumber) \
              --vault-password-file /opt/secrets/vault-pass
          displayName: 'Deploy to production'

The pipeline still runs in Azure DevOps — only the agents and targets are local. You keep the familiar interface, PR triggers, and approval gates while deploying to your own hardware.

The TOOLS VM: Your On-Prem Control Plane

The TOOLS VM deserves special attention because it runs everything that supports your development workflow:

Harbor — private container registry with vulnerability scanning
SonarQube — code quality and security analysis
Grafana + Loki + Promtail — monitoring, log aggregation, and dashboards
Vaultwarden — team password management
Self-hosted CI/CD agents — Azure DevOps or Gitea runners

All of these run as Docker Compose services on a single VM with 32 GB RAM and 8 cores. The Ansible playbook for TOOLS is the most complex one in the stack, but it is also the one you run least often — set it up once and it hums along.

The monitoring stack in particular is worth getting right on day one. Grafana dashboards showing container health, Loki ingesting logs from every service via Promtail — this is your replacement for Azure Application Insights, and it costs exactly nothing beyond the hardware it runs on.

When This Approach Falls Short

Docker Compose and Ansible are not the answer to everything.

If you need auto-scaling, this setup does not scale horizontally. You would need Kubernetes or Docker Swarm — and at that point, you are adding significant operational complexity. For most Nordic SMBs with predictable load, fixed capacity with headroom is simpler and cheaper than auto-scaling.

If you have 50+ microservices, managing individual Compose files and Ansible playbooks for each one becomes painful. At that scale, Kubernetes earns its complexity tax. But if you are reading this article, you probably have 5–15 services, and Compose handles that without breaking a sweat.

If your team has zero Linux experience, the learning curve for Ansible, Docker, SSH key management, and firewall configuration is real. Budget 2–4 weeks for the team to get comfortable, or bring in someone who has done it before.

From Zero to Running in a Weekend

Here is the realistic timeline — assuming you have the hardware racked and Rocky Linux installed on all four VMs:

Saturday morning: Run the base Ansible playbook across all VMs. SSH hardening, packages, firewall rules, Docker installation. Two hours if your playbooks are solid. The Ansible playbooks in the Cloud Exit Starter Kit are tested against Rocky Linux 9 and cover this entire base layer, so you are not starting from a blank file.

Saturday afternoon: Stand up the TOOLS VM — Harbor, Grafana stack, CI/CD agents. Push your first container image to Harbor. Three hours.

Sunday morning: Deploy the application stack to DEV and TEST. Verify everything works, fix the inevitable environment variable typo. Two hours.

Sunday afternoon: Deploy to PROD. Configure Nginx with SSL. Point DNS. Run your smoke tests. Two hours, plus whatever time you spend staring at Grafana dashboards making sure the metrics look right.

Is it actually a weekend? For someone who has done it before, yes. For a first-timer with well-structured playbooks, add another day or two for troubleshooting and learning. The point is that this is not a multi-month infrastructure project — it is a focused build with clear milestones.

Ready to migrate off the cloud?

I put together a Cloud Exit Starter Kit ($49) — Ansible playbooks, Docker Compose production templates, and the migration checklist I use on real projects. Everything you need to go from Azure/AWS to your own hardware.

Or if you just want to talk it through: book a free 30-minute cloud exit assessment. No sales pitch — just an honest look at whether on-prem makes sense for your situation.

Building DocProof: Proving Documents Exist Without Sharing Them

DanielG — Thu, 09 Apr 2026 17:13:05 +0000

There's a problem that's been bugging me for a while. How do you prove a document existed at a specific point in time—without handing it over to someone else?

Think about it: contracts, creative work, research notes, legal agreements. Sometimes you need proof that something existed before a certain date. Traditional solutions? Upload it to a notary service. Email it to yourself. Store it with a third party who pinky-promises to keep timestamps honest.

None of that felt right to me. Why should I trust a company to hold my documents? Why should proving when something existed require giving up what it contains?

So I built DocProof, with GoLang as backend API and worker, and Angular as the frontend.

The idea

DocProof lets you create a timestamped, verifiable proof that a document existed—without ever uploading the document itself.

Here's how it works:

You select a file on your device
Your browser computes a SHA-256 hash (a cryptographic fingerprint) of that file—locally, on your machine
That fingerprint gets anchored on the blockchain with a timestamp
Done. Your document never left your device. Only the fingerprint did.

Anyone can later verify the proof independently by hashing the same document and checking it against the blockchain record. No need to trust me, no need to trust DocProof to stay in business, no need to share sensitive content.

Why blockchain?

Blockchain carries some baggage. NFT speculation, crypto hype, environmental concerns.

Blockchain is genuinely good at one specific job—creating immutable, timestamped records that don't depend on any single party. That's exactly what document verification needs.

DocProof uses Base, a Layer 2 network on Ethereum. It's proof-of-stake (no massive energy consumption), cost-effective, and permanent. The proof exists independently of whether DocProof as a service continues to exist.

There's no token, no NFT, no financial element, no crypto speculation. Just a timestamp you can trust.

Is this like an NFT?

I get this question, and it's fair. There's technical overlap: both use blockchain to create timestamped, immutable records. Both involve cryptographic proof of something existing on-chain.

But the purpose is completely different.

NFTs are about ownership and transferability. You mint something, you can sell it, trade it, speculate on it. The whole ecosystem is built around digital assets changing hands—often with significant financial speculation attached.

DocProof is about proving existence at a point in time. That's it. No trading. No marketplace. No speculation. You're not buying or selling anything. You're creating a verifiable timestamp.

There's also a key privacy difference: NFTs typically store or link to the actual content (an image, a video, metadata). DocProof only stores the hash—a cryptographic fingerprint. The document itself never leaves your device, and the hash reveals nothing about the content. You can't reverse-engineer a document from its hash.

Think of it like the difference between selling a painting and getting a document notarized. Same pen, completely different purpose.

Who is this for?

I've been thinking a lot about use cases:

Freelancers and contractors — Prove when you delivered work or signed an agreement. Useful if disputes arise later about timelines.

Creators and inventors — Establish proof of creation for designs, music, writing, code, patents. Show that your work existed before someone else claims it.

Researchers and academics — Timestamp research findings, papers, or data before publication. Protect priority claims.

Legal and compliance — Contracts, wills, insurance policies. Proof that a version existed at a specific moment.

Anyone who values privacy — You might just want a personal record without trusting a third party with your files.

What's next

DocProof is live now, and I'm actively working on it. The core functionality works: create proofs, verify them, all without uploading your documents anywhere.

I'm building this because I think it should exist. Privacy-first and practical.

If you want to try it out, head over to docproof.org.

I would love feedback—what works, what doesn't, what use cases I haven't thought of.

And if you're curious about the technical details or want to follow along as I build, I'll be posting updates here and on Mastodon.

Let's see where this goes.

/Daniel

Building DocProof: A Solo Dev Journey with AI as My Co-Pilot

DanielG — Thu, 09 Apr 2026 17:13:03 +0000

I shipped DocProof recently—a privacy-first document verification service. But this post isn't about what it does. It's about how it got built, and what it's like to develop a product in 2026 with AI assistance.

Short version: I couldn't have done it this fast without Claude for code-assistance, and ChatGPT for ideation.

And I want to be honest about what that actually looked like.

The starting point

I'm a fullstack software engineer. I know my way around code.

But DocProof touched areas where I'm not an expert: blockchain integration, cryptographic hashing in the browser, smart contract deployment, Stripe payment flows, and a dozen other things I'd never done exactly this way before.

A few years ago, this would've meant weeks of documentation rabbit holes, Stack Overflow threads & trial-and-error. I'd still have built it—but slower, with more frustration, and probably with more architectural mistakes baked in.

This time, I had a different approach.

Claude as a thinking partner

I started using Claude not just for code snippets, but as a genuine collaborator. And that changed how I work.

Here's what that looked like in practice:

Architectural decisions. Early on, I wasn't sure how to structure the blockchain interaction. Should the hash go directly on-chain? Should I batch transactions? What's the cost tradeoff? I talked through the options with Claude, weighing pros and cons until the right approach became clear. It wasn't Claude telling me what to do—it was a conversation that helped me think better.

Learning on demand. I'd never worked with Base or deployed a smart contract to mainnet with real money on the line. Instead of spending days reading documentation, I could ask targeted questions: "What's the difference between Base Sepolia and mainnet deployment?" or "How do I estimate gas costs for this transaction?" Instant, contextual answers. Then I'd verify and implement.

Code review and debugging. When something didn't work, I'd paste the error and the relevant code. Claude would spot the issue faster than I could—often something obvious I'd been staring at for too long. Fresh eyes, even artificial ones, help.

Writing and copy. The landing page, the explanations, the documentation—writing clear copy for a technical product is hard. I'd draft something, Claude would suggest improvements, we'd iterate. The result was clearer than what I'd have written alone.

Thinking through edge cases. "What happens if someone tries to verify a document that was never registered?" "How should I handle failed blockchain transactions?" These conversations caught problems before they became bugs.

What AI assistance actually feels like

There's a misconception that using AI means "the AI builds it for you." That's not how it works—at least not for anything meaningful.

It's more like having a knowledgeable colleague available 24/7 who never gets tired of questions, doesn't judge you for forgetting syntax, and can context-switch instantly between frontend, backend, blockchain, and marketing copy.

I still made every decision. I still wrote and reviewed every line of code. I still own the architecture, the bugs, and the tradeoffs. But I got there faster, with fewer dead ends, and with more confidence.

The best analogy I have: it's like pair programming with someone who's read all the documentation you haven't.

The productivity shift

I don't want to overstate this, but I also don't want to understate it.

DocProof would have taken me significantly longer without AI assistance. Not because Claude wrote the code for me—but because it removed friction at every step. Less time stuck. Less time context-switching to Google. Less time second-guessing architectural choices.

That time adds up. For a solo developer working on a side project, it's the difference between shipping and abandoning.

Some honest caveats

It's not magic. Claude gets things wrong sometimes—especially with newer APIs or very specific library versions. I learned to verify, not just trust. The answers are a starting point, not gospel.

And there's a skill to using it well. Vague questions get vague answers. The better I got at explaining context and asking precise questions, the more useful the responses became. It's a tool that rewards intentional use.

Where this leaves me

DocProof is live. It works. Real users can create real proofs.

Building it taught me something about how software development is changing. The gap between "I have an idea" and "I shipped a product" is shrinking—not because AI does the work for you, but because it removes the friction that used to slow everything down.

I'm still the developer. I still need to understand what I'm building. But I have a collaborator now that makes the whole process feel less lonely and more efficient.

If you're a solo dev or indie hacker hesitating to start something because it feels too big—try working this way. You might surprise yourself with what you can ship.

DocProof is at [docproof.dk]. If you want to follow along with what I'm building, I'm on Mastodon at [handle] and posting updates here.

Moving Off the Cloud: A Practical Guide to On-Premises Migration for Nordic SMBs

DanielG — Thu, 09 Apr 2026 17:13:02 +0000

Your Azure bill hit €12,000 last month — again — and half your containers are sitting idle at 8% CPU. You are not alone. Across the Nordics, small and mid-sized companies that moved to the cloud five or six years ago are doing the same math and arriving at the same uncomfortable conclusion: the cloud is costing more than it should, and the value proposition has shifted.

This is not an anti-cloud manifesto. Some workloads genuinely belong there. But if you are running predictable, steady-state applications on managed services you barely use, on-premises infrastructure deserves a serious look. I recently migrated a full .NET backend API and Angular frontend stack from Azure to on-premise Rocky Linux servers for a Nordic client — and the numbers told a clear story.

Why Nordic SMBs Are Re-Evaluating Cloud

Three forces are driving the conversation.

Cost. Cloud pricing was designed for elastic workloads — bursty traffic, unpredictable demand, fast experimentation. Most Nordic SMBs run the opposite: stable line-of-business applications with predictable load. You are paying a premium for elasticity you never use. When I ran the numbers for a 20-person development team's infrastructure, the cloud bill was roughly 3x what the same capacity cost on owned hardware over a three-year horizon.

Data sovereignty and GDPR. Nordic companies handle data subject to GDPR, and increasingly face questions about where that data physically lives. Azure's Norway East and Sweden Central regions help, but they do not eliminate the compliance overhead of proving your data stays within the right jurisdiction. On-premise gives you a simple answer: it is in the server room down the hall.

Vendor lock-in. Every managed service you adopt — Azure Service Bus, AWS Lambda, Google Cloud Run — adds a dependency that makes leaving harder. After a few years, "multi-cloud" is a fantasy and "exit" is a project nobody wants to scope. Getting ahead of this is cheaper than getting out of it later.

Decision Framework: What Belongs On-Prem vs. What Stays in the Cloud

Not everything should come back. Here is how I think about it:

Move on-prem when:

The workload has predictable, steady resource consumption
You have (or can hire) someone who can maintain Linux servers and Docker
The application handles sensitive data that benefits from physical control
You are paying for managed services (e.g., Azure SQL, App Service) that a self-hosted equivalent covers at a fraction of the cost

Keep in the cloud when:

Traffic is genuinely spiky or seasonal (e-commerce flash sales, campaign-driven SaaS)
You need global distribution and edge presence
The team has zero infrastructure experience and cannot invest in building it
You are using cloud-native services that have no practical self-hosted equivalent (e.g., machine learning inference APIs, global CDN)

The grey zone: Many workloads fall in between. For these, run the TCO comparison below before deciding. Do not guess — calculate.

Cloud to On-Premise Migration Checklist

I have done this migration twice in production. Here is the checklist I wish I had the first time.

Phase 1: Inventory and Assessment (2–4 weeks)

List every service and resource in your cloud account. Not just compute — storage, DNS, secrets, queues, scheduled jobs, monitoring. Export your cloud provider's resource list. Azure: az resource list. AWS: aws resourcegroupstaggingapi get-resources.
Map dependencies. Which services talk to which? Draw the arrows. Every managed service you use (e.g., Azure Service Bus) needs a self-hosted replacement (e.g., RabbitMQ) or a redesign.
Identify stateful components. Databases, file storage, caches. These are your hardest migration targets. Plan them first.
Baseline current performance. Document response times, throughput, and error rates before migration. You need this to validate after cutover.
Audit cloud-specific SDK usage. Search your codebase for cloud provider SDKs. Each call is a potential migration task.

Phase 2: Infrastructure Preparation (2–6 weeks)

Provision hardware. For a typical Nordic SMB, four VMs or bare-metal servers cover most needs: DEV, TEST, PROD, and a TOOLS server (for CI/CD agents, container registry, monitoring). Budget €15,000–€30,000 for three-year hardware, depending on spec.
Choose your OS. Rocky Linux 9 or Ubuntu 22.04 LTS. Both are solid. I use Rocky Linux for production servers — it is the CentOS successor and has a 10-year support cycle.
Set up configuration management. Ansible is the right choice for teams under 200 people. It is agentless, readable, and does not require a PhD to operate. Write playbooks for every server role.
Deploy your container stack. Docker Compose for orchestration at SMB scale. Kubernetes is overkill unless you are running 50+ services — and even then, think twice.
Stand up supporting services. Container registry (Harbor), monitoring (Grafana + Loki + Promtail), secrets management (Vaultwarden or HashiCorp Vault), reverse proxy (Nginx with SSL termination).

Phase 3: Application Migration (4–8 weeks)

Containerize everything that is not already containerized. If your .NET app runs on Azure App Service, it needs a Dockerfile.
Replace managed services one by one. Azure SQL → PostgreSQL. Azure Service Bus → RabbitMQ. Azure Blob Storage → MinIO. Test each replacement in isolation.
Update CI/CD pipelines. Your build agents need to push to your private registry and deploy to your servers, not to Azure. Self-hosted Azure DevOps agents or Gitea + Drone CI both work.
Migrate data. Schedule a maintenance window. For databases, use pg_dump/pg_restore or the equivalent. Test the restore on your target environment before the real cutover.
Validate. Compare against your Phase 1 baselines. Response times, error rates, throughput. If something regressed, fix it before going live.

Phase 4: Cutover and DNS Switch (1 day)

Final data sync during a planned maintenance window.
Switch DNS to point to the on-prem servers. Keep the cloud environment running in parallel for 1–2 weeks as a rollback option.
Monitor aggressively for the first 72 hours. Grafana dashboards and alerts should be in place before cutover, not after.

Common Pitfalls

I have hit all of these. Learn from my mistakes.

Underestimating bandwidth requirements. Cloud providers give you fast, free inter-service networking. On-prem, your network is your own problem. Make sure your internal network can handle the traffic between services. A 1 Gbps switch is the minimum; 10 Gbps is cheap insurance.

Licensing traps. Some software (looking at you, SQL Server) has on-premise licensing that costs more than the cloud version. Check every license before committing. PostgreSQL, Redis, and RabbitMQ are free — and for most Nordic SMBs, they are more than enough.

The "we will figure out backups later" mistake. On Azure, backups are mostly automatic. On-prem, they are your responsibility from day one. Set up automated backups to an offsite location before you migrate production data. Not after. Before.

Ignoring the human factor. Someone needs to be on call for hardware failures. In the cloud, you do not think about disk failures or power outages. On-prem, you do. If your team does not want this responsibility, either hire for it or use a colocation facility with managed hardware.

Trying to replicate the cloud on-prem. Do not install Kubernetes, a service mesh, and a cloud-native API gateway just because you had them in Azure. Start simple: Docker Compose, Nginx, PostgreSQL. Add complexity only when the workload demands it.

Real Cost Comparison: 3-Year TCO

Here is a simplified but realistic comparison for a Nordic SMB running a .NET backend API, Angular frontend, PostgreSQL database, message queue, and monitoring — supporting a 20-person development team.

Cloud (Azure)

Item

Monthly Cost

3-Year Total

App Service (2x B2, prod + staging)

€400

€14,400

Azure SQL (S3)

€500

€18,000

Azure Service Bus (Standard)

€50

€1,800

Blob Storage (500 GB)

€30

€1,080

Azure DevOps (5 parallel jobs)

€200

€7,200

Monitoring (Application Insights, Log Analytics)

€250

€9,000

Networking (bandwidth, DNS, load balancer)

€150

€5,400

Total

€1,580/mo

€56,880

On-Premises

Item

Cost

3-Year Total

4x servers (Dell PowerEdge T350 or equivalent)

one-time €20,000

€20,000

Colocation or server room power/cooling

€200/mo

€7,200

Internet (dedicated 1 Gbps, Nordic ISP)

€300/mo

€10,800

Software licenses (all open source)

€0

Offsite backup storage (Backblaze B2, 1 TB)

€5/mo

€180

Additional sysadmin time (~4 hrs/mo at €100/hr)

€400/mo

€14,400

Total

€52,580

3-year savings: approximately €4,300. That is not dramatic — but it compounds. The on-prem cost is mostly front-loaded (hardware), while cloud costs only go up. By year five, the gap widens to roughly €25,000–€35,000 because the hardware is already paid for.

And this comparison is conservative. Many Nordic SMBs I talk to are spending €3,000–€8,000/month on cloud — at which point the on-prem savings are significant from year one.

When NOT to Do This

I would not recommend on-prem migration if:

Your team has fewer than three developers and zero ops experience. The learning curve will eat your savings.
Your application is genuinely elastic — scaling from 2 to 200 instances based on demand.
You are a startup that might pivot next quarter. Do not buy hardware for a product that might not exist in six months.
You are in a regulated industry that requires specific cloud certifications you cannot replicate on-prem (rare in the Nordics, but worth checking).

Next Steps

If the numbers look interesting for your situation, start with the inventory in Phase 1. You do not need to commit to anything — just map what you have and run your own TCO comparison with real figures.

I have put together a cloud migration checklist template you can download, along with production-ready Ansible playbook templates for the base server setup.

Or if you want to talk through your specific situation — whether migration makes sense, what it would cost, and how long it would take — book a free 30-minute call. No pitch, just an honest assessment from someone who has done it.

When to Modernize Your Legacy .NET Application (And When Not To)

DanielG — Thu, 09 Apr 2026 17:13:01 +0000

When to Modernize Your Legacy .NET Application (And When Not To)

Your .NET Framework 4.6 application works. It processes orders, generates reports, handles the business logic that keeps the company running. Nobody touches it unless something breaks. Deployments happen once a quarter — if you are lucky — and they involve a nervous developer, a checklist from 2018, and a prayer.

Sound familiar? You are sitting on a legacy .NET application, and someone in leadership is asking whether it is time to modernize. The answer is not always yes. But when it is yes, doing it right saves you years of pain. Doing it wrong costs you the same.

I have modernized .NET applications for Nordic SMBs for the past decade — from small internal tools to full line-of-business platforms with 50+ developers. Here is how I think about when to pull the trigger and when to leave things alone.

Five Signs Your .NET App Needs Modernization

Not every old application is a problem. Some .NET Framework apps will run fine for another decade. But these symptoms mean the clock is ticking.

1. Releases take weeks, not hours. If deploying a bug fix requires a full regression cycle, manual IIS configuration, and a maintenance window at 02:00 on a Saturday, your delivery pipeline is the bottleneck. Modern .NET with containerized deployments and CI/CD can get that down to minutes.

2. You cannot hire developers who want to work on it. Try posting a job ad for a .NET Framework 4.5 developer in Copenhagen or Stockholm in 2026. The candidates who respond will either be expensive specialists or junior developers who will struggle with the ancient toolchain. New graduates learn .NET 10, not Web Forms.

3. Security patches are getting harder — or impossible. .NET Framework 4.8 is in maintenance mode. Microsoft is not adding new features or backporting security improvements from .NET 10+. If your application depends on libraries that have stopped supporting .NET Framework, you are accumulating risk every month.

4. Your hosting costs are climbing for no reason. Legacy .NET Framework apps typically run on Windows Server with IIS. Windows Server licensing, especially in on-prem or hybrid setups, is significantly more expensive than running .NET 10 on Linux. One client I worked with cut their hosting costs by 40% just by moving from Windows VMs to Linux containers — before optimizing anything else.

5. Integration with modern tools is painful. Need to add OpenTelemetry for observability? A modern authentication provider like Keycloak? A message queue for async processing? In .NET Framework, each of these is a fight. In .NET 10, they are NuGet packages and a few lines of configuration.

If you are nodding at three or more of these, modernization is worth scoping. If you are only seeing one, you might be fine for now — read the "when not to modernize" section before making any decisions.

The .NET Application Modernization Spectrum

Modernization is not a binary choice. There is a spectrum, and where you land depends on your budget, timeline, and how far gone your current architecture is.

Rehost (Lift and Shift)

Move the application to new infrastructure without changing the code. Put it in a container or a new VM, update the deployment scripts, done.

Best for: Applications that work fine but are stuck on expensive or end-of-life infrastructure. A .NET Framework app running on a Windows Server 2012 VM is a candidate.

Cost: Low. Days to weeks.

What you get: Lower hosting costs, better infrastructure automation. The application itself is unchanged.

What you do not get: Any of the developer experience or performance benefits of modern .NET.

Re-Platform

Upgrade the runtime and framework version while keeping the overall architecture. Migrate from .NET Framework 4.x to .NET 10, replace deprecated libraries, update the build pipeline.

Best for: Applications with decent architecture that are held back by the framework version. If the code is reasonably structured — controllers, services, repositories — re-platforming is often the sweet spot.

Cost: Medium. Weeks to a few months, depending on size.

What you get: Modern runtime performance (often 2–5x faster for API workloads), Linux hosting, current library ecosystem, easier hiring.

What you do not get: A fix for fundamental architecture problems. If the codebase is a tangled mess of static classes and God objects, re-platforming puts a new engine in a car with no steering wheel.

Re-Architect

Restructure the application while migrating. Break a monolith into bounded contexts or services. Introduce proper domain modeling. Fix the sins of the past.

Best for: Applications where the business logic is valuable but the architecture prevents the team from moving fast. Typically systems that have grown organically for 8+ years.

Cost: High. Months. Requires experienced architects.

What you get: A maintainable, testable system that the team can extend without fear. Plus all the re-platform benefits.

What you do not get: Speed. This is the slowest option, and the risk of scope creep is real.

Rewrite

Start from scratch. New codebase, new architecture, modern stack from day one.

Best for: Almost nothing. I am serious. Rewrites are the most expensive, highest-risk option and should be a last resort. The only time I recommend a rewrite is when the existing code is so unmaintainable that understanding it takes longer than rebuilding it — and that is rarer than most people think.

Cost: Very high. 6–18 months. Budget overruns are the norm, not the exception.

What you get: A clean codebase — if you get it right.

What you do not get: Guarantees. Joel Spolsky wrote about this in 2000 and the advice still holds: rewrites kill companies. The old system encodes years of business rules, edge cases, and institutional knowledge that no specification document captures.

.NET Framework to .NET 10: What Actually Changes

If you are going the re-platform route — and for most Nordic SMBs, this is where I start — here is what the migration involves in practice.

The Big Shifts

Project and solution file format. Old-style .csproj files with hundreds of lines of XML become the new SDK-style format. Solutions get the same treatment — the new .slnx format replaces the legacy .sln with a clean, readable XML file that is easy to diff and merge. This alone makes the project manageable.

<!-- Before: .NET Framework csproj (abbreviated — the real ones are 200+ lines) -->
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\...\Microsoft.CSharp.targets" />
  <PropertyGroup>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <!-- ... 40 more properties ... -->
  </PropertyGroup>
  <!-- ... ItemGroups with explicit file references ... -->
</Project>

<!-- After: .NET 10 csproj -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>
</Project>

Dependency injection is built in. If your .NET Framework app uses Autofac, Ninject, or Unity, the built-in DI container in .NET 10 handles most scenarios. One less dependency to maintain.

Configuration moves from web.config to appsettings.json. The new configuration system supports environment-specific overrides, user secrets, and environment variables out of the box. No more XML transforms.

Entity Framework → EF Core. The migration path is well-documented but not trivial. Lazy loading works differently, some LINQ queries need rewriting, and the migration tooling has changed. Budget a week for a medium-sized data layer.

Authentication and Identity. If you are using ASP.NET Identity or Windows Authentication, the migration requires attention. ASP.NET Core Identity is a different library with a different API. If you are planning to introduce Keycloak or another OpenID Connect provider, modernization is a good time to make that switch.

What Catches Teams Off Guard

System.Web is gone. Completely. If your code references HttpContext.Current, System.Web.Mvc, or any System.Web namespace, every one of those calls needs to be replaced. For large codebases, this is the single biggest migration task.

SOAP/WCF services. .NET 10 has limited WCF client support via CoreWCF, but if you are hosting WCF services, you need to rewrite them as REST or gRPC endpoints. There is no direct migration path.

Global.asax and HTTP Modules. The request pipeline is completely different. Startup.cs (or the new minimal hosting model) replaces Global.asax. HTTP modules become middleware. The concepts map cleanly, but the code does not copy-paste.

Third-party library compatibility. Check every NuGet package you depend on. Many have .NET 10 versions, but some are abandoned or have been replaced by alternatives. The .NET Upgrade Assistant tool flags these, and it is worth running early.

The Tool That Helps

Microsoft's .NET Upgrade Assistant automates the mechanical parts: project file conversion, namespace changes, known API replacements. It will not fix your architecture, but it handles the tedious work. Run it first, then fix what it cannot handle.

# Install and run the Upgrade Assistant
dotnet tool install -g upgrade-assistant
upgrade-assistant upgrade ./YourSolution.sln

In a recent re-platform project, the Upgrade Assistant handled about 60% of the changes automatically. The remaining 40% was manual work — mostly replacing System.Web references and updating EF queries.

When NOT to Modernize

Here is the part most consultants skip: sometimes the right answer is to leave your legacy .NET application alone.

The application is stable and requirements are frozen. If the system processes invoices the same way it has for five years, nobody is asking for new features, and it runs without issues — why touch it? Modernization has real risk. If the risk is not justified by a real need, the smart move is to leave it running.

The business case does not add up. Modernization costs money. If the application will be decommissioned in two years because the business is switching to a SaaS product, spending six months re-platforming it is a waste. Ask the hard question: how long will this application need to exist?

You do not have the team for it. A .NET Framework-to-.NET 10 migration requires developers who understand both. If your team only knows .NET Framework and you cannot bring in experienced help, the migration will take 3x longer and introduce bugs you did not have before.

The application is a small internal tool. A small WinForms app used by five people in accounting does not need to be on .NET 10. If it works and the maintenance cost is near zero, let it be.

You are doing it for the resume. This sounds absurd, but I have seen it. A team pushes for modernization because they want to work with the new tech, not because the business needs it. Modernization should be driven by business outcomes — reduced costs, faster delivery, lower risk — not by developer boredom.

How to Scope and Budget a .NET Modernization Project

If you have decided to move forward, here is how I scope these projects for Nordic SMBs.

Step 1: Audit the Codebase

Before estimating anything, you need to understand what you are working with.

Lines of code (rough indicator of size)
Number of projects in the solution
.NET Framework version(s) in use
Third-party dependencies and their .NET 10 compatibility
Database access layer (raw ADO.NET, EF6, Dapper, stored procedures)
External integrations (SOAP services, file shares, third-party APIs)

Run the .NET Upgrade Assistant in analysis mode to get a compatibility report.

Step 2: Pick Your Strategy

Based on the audit, choose your point on the spectrum. Most Nordic SMBs I work with land on re-platform for the core application, with selective re-architecting of the worst modules.

Step 3: Estimate in Phases

Break the work into phases that deliver value independently. Do not plan a six-month migration with value only at the end — that is how projects get cancelled.

Phase 1 — Core API migration. Get the backend running on .NET 10 with existing functionality. 4–8 weeks for a medium-sized application.

Phase 2 — Infrastructure modernization. Containerize, set up CI/CD, deploy to Linux. 2–4 weeks, can overlap with Phase 1.

Phase 3 — Data layer migration. EF6 to EF Core, database schema cleanup. 2–6 weeks depending on complexity.

Phase 4 — Frontend and integration cleanup. Update any tightly coupled frontend code, replace deprecated integrations. 2–4 weeks.

Ballpark Budget

For a typical Nordic SMB application (50–200k lines of code, 10–30 projects in the solution, one database):

Re-platform only: DKK 300,000–600,000 (€40,000–€80,000)
Re-platform with selective re-architecture: DKK 500,000–1,200,000 (€67,000–€160,000)
Full rewrite: DKK 1,500,000+ (€200,000+) — and it will go over budget

These numbers assume a senior .NET developer or a small team working focused hours. Your actual cost depends on codebase size, architectural debt, and how many System.Web references your search turns up.

Next Steps

If your .NET Framework application is showing the symptoms I described above, start with the audit. Install the .NET Upgrade Assistant, run the analysis, and get a clear picture of what a migration would involve. That costs you an afternoon, not a budget approval.

If you want an experienced set of eyes on the analysis — someone who has done this migration multiple times for Nordic companies — book a free 30-minute assessment call. I will tell you honestly whether modernization makes sense for your situation, and what it would realistically cost.