Nomad is not the standard anymore: how to migrate from Nomad to Kubernetes in your own cloud account

Yes, you can migrate from HashiCorp Nomad to Kubernetes in your own cloud account without re-architecting, as long as your jobs run on the docker task driver. Your container images, environment variables and health checks stay the same, and only the scheduler contract changes: HCL jobspecs become Deployments, StatefulSets, DaemonSets, Jobs and CronJobs. Teams make the move because Kubernetes became the orchestrator that cloud providers, vendors and the hiring market standardised on, even though Nomad never stopped working.

Key Points:

• Nomad lost the standards war on ecosystem gravity. It is a good scheduler, but Kubernetes is what the ecosystem, the cloud providers, the operators, the tooling and the hiring market all standardised on.
• With the docker driver, the migration is a translation project. The container image is the portability boundary and it does not change.
• The mapping is close to one-to-one. Job > group > task becomes Deployment > Pod > container, count becomes replicas, constraint becomes nodeSelector/nodeAffinity, spread becomes topologySpreadConstraints, periodic becomes CronJob, system becomes DaemonSet, and template becomes ConfigMaps, Secrets or the Vault Secrets Operator.
• There is no official or reliable Nomad-to-Kubernetes converter. kompose only handles Docker Compose. Budget engineering time, not tool hunting.
• Run both schedulers in parallel. Move stateless services first, batch next, stateful last, and move databases to managed cloud services instead of lifting CSI volumes into PVCs.
• The hard part is rebuilding the simplicity Nomad gave you. Staff a platform team on EKS/GKE/AKS plus GitOps, or put an internal developer platform like Qovery on Kubernetes in your own cloud account.

Why did Nomad never become the industry-standard orchestrator?

Nomad lost the orchestration standards war to Kubernetes on ecosystem gravity, not on engineering merit. Kubernetes became the default API that every cloud provider, vendor, operator and CI tool targets, so a Nomad shop pays an integration tax on nearly everything it adopts.

The adoption gap is large. The CNCF found that 80% of organisations ran Kubernetes in production in 2024, up from 66% in 2023, and 93% were using, piloting or evaluating it (CNCF Annual Survey 2024). In the 2025 Stack Overflow Developer Survey, 28.5% of all respondents reported using Kubernetes, and Nomad does not appear in the cloud development list at all (Stack Overflow Developer Survey 2025).

The structural reasons are easy to name:

• Governance. Kubernetes is a graduated CNCF project under the Apache 2.0 licence (CNCF). Nomad is a single-vendor product.
• No managed service from the big clouds. AWS, Google Cloud, Azure and Scaleway all sell managed Kubernetes. None of them sells managed Nomad.
• A thinner ecosystem. Operators, Helm charts, admission controllers and observability integrations ship for Kubernetes first, and often only for Kubernetes.

Two ownership events then pushed the teams that were on the fence. On August 10, 2023, HashiCorp moved its products from MPL 2.0 to the Business Source License 1.1 (HashiCorp). Nomad's licence now covers version 1.7.0 and later, allows production use except in offerings that compete with the vendor's paid versions, and converts each version to MPL 2.0 four years after release (Nomad LICENSE). IBM announced its acquisition of HashiCorp on April 24, 2024 (IBM) and closed it on February 27, 2025, at an enterprise value of $6.4 billion (IBM). None of this is malicious. It shows up as procurement questions and roadmap risk that a CNCF project avoids.

Hiring seals it. You can hire Kubernetes engineers, consultants and on-call support in every market. Nomad expertise is scarce, so your bus factor is the two engineers who read HCL.

To be fair to Nomad: it is one binary for server and client, it schedules more than containers (docker, exec, raw_exec, java, qemu and more, see the Nomad drivers docs), it has a small footprint, its jobspec reads well without training, and it performs at scale. Plenty of teams run it happily and should stay.

My decision rule: if Nomad only schedules containers for you, you pay the non-standard tax for nothing. If it schedules raw binaries, VMs and Java processes across mixed hosts, it still earns its place. Carve those workloads out and keep a small Nomad island.

Can you migrate from Nomad to Kubernetes without a full re-architecture?

Yes. If your Nomad jobs run on the docker task driver, your application code, images, environment variables and health checks carry over, and only the scheduler contract and the operational layer change. You only face a real re-architecture for workloads that are not containerized.

What transfers as-is: container images, environment variables, health checks (a Nomad check becomes liveness, readiness or startup probes), resource intent, rolling-update intent and service-discovery intent.

What needs rework:

• raw_exec, exec, java and qemu tasks.
• host_volume assumptions tied to specific clients.
• Parameterized/dispatch jobs, which have no native Kubernetes equivalent (Nomad parameterized docs).
• artifact blocks that fetch binaries at runtime. Bake those into the image instead.

Here is a decision rule you can count: group your jobspecs by task driver. If more than 80% use docker, plan for weeks of translation. If a meaningful share runs on raw_exec or exec, decide workload by workload whether to containerize it, move it to a VM with a systemd unit, or keep it on a small Nomad island.

The one capability you cannot bring along is multi-runtime scheduling. Kubernetes schedules containers (and VMs through KubeVirt), not arbitrary processes.

Most of the effort goes into the landing zone (VPC, CNI, CSI, ingress, observability, RBAC) and the developer experience. The YAML is the small part.

How do Nomad concepts map to Kubernetes objects?

Nearly every Nomad primitive has a direct Kubernetes equivalent. Writing this mapping before you touch a cluster is the most valuable hour of the whole migration. Two traps break parity: CPU (Nomad MHz versus Kubernetes millicores) and memory (Nomad hard limit versus Kubernetes requests and limits).

The hierarchy maps cleanly. A Nomad job > group > task becomes Deployment > Pod template > container, and a group with several tasks becomes a multi-container Pod, sidecars included. Nomad has four schedulers, service, system, batch and sysbatch, plus periodic and parameterized blocks on top (Nomad job docs).

The CPU trap. In Nomad, resources { cpu = 500 } means 500 MHz, or you reserve whole cores (Nomad resources docs). Kubernetes counts CPU in millicores of a vCPU (Kubernetes docs). A MHz figure depends on the clock speed of the host, so no clean arithmetic converts between the two. Derive requests from observed allocation metrics on Nomad, then tune.

The memory trap. Nomad memory is a hard limit unless you set memory_max, in which case memory becomes the reservation (Nomad resources docs). In Kubernetes you set requests and limits separately. A container that goes over its CPU limit gets throttled, one that goes over its memory limit gets OOMKilled, and the request/limit combination sets the Pod's QoS class: Guaranteed, Burstable or BestEffort (Kubernetes Pod QoS).

Consul and Vault come with you if you want them. Consul runs on Kubernetes as a service mesh (Consul on Kubernetes), and cluster peering connects independent Consul clusters (Consul cluster peering). Vault delivers secrets through the Vault Secrets Operator, which syncs them into native Kubernetes Secrets (Vault Secrets Operator), or through the Vault Agent Injector.

Tooling. There is no official or reliable Nomad-to-Kubernetes converter. kompose converts Docker Compose files to Kubernetes and nothing else (kompose). Most teams write a small script that parses HCL and emits Helm values, then review every manifest by hand.

What is the step-by-step migration path that keeps production running?

Run Nomad and Kubernetes in parallel and move one workload class at a time, starting with the most stateless, lowest-traffic service. Never do a big-bang cutover. At every step, the original Nomad jobspec must still be deployable as your rollback.

1. Inventory. Export every jobspec with nomad job inspect and tag each one by task driver, statefulness, external dependencies, traffic class and blast radius. The deliverable is a spreadsheet, not YAML.
2. Landing zone. Stand up Kubernetes in your own cloud account (EKS, GKE, AKS, Scaleway Kapsule, or an existing self-managed cluster). Networking, CNI, CSI, ingress or Gateway API, log shipping, metrics and alerting all need to work before a single app moves.
3. Pilot one service. Translate its jobspec and check parity on five axes: probes firing, resource usage versus the Nomad allocation, log format, metric labels, and p95 latency under real traffic.
4. Bridge the two worlds. Peer Consul between the Nomad datacenter and the cluster, or keep it simple and register both backends behind the same load-balancer target groups or DNS records.
5. Shift traffic gradually. Use weighted DNS (Route 53, Cloud DNS, Azure Traffic Manager), ALB/NLB target-group weights, or mesh routing. Keep the Nomad allocation warm until the shift survives a full peak period.
6. Stateful last, on managed services. Point databases at RDS, Cloud SQL, Azure Database or Scaleway Managed Databases instead of lifting Nomad CSI volumes into PVCs. Snapshot and restore beats volume surgery.
7. Batch, periodic, decommission. Migrate batch and periodic jobs, confirm a full cycle of CronJob runs, drain and remove Nomad clients and then servers, and archive every jobspec in git next to its Kubernetes equivalent.

The rollback contract: Nomad stays up and deployable until one full business cycle (month-end, peak day, a restore test) has passed on Kubernetes.

What do you lose when you leave Nomad, and how do you get it back?

You lose operational simplicity. Nomad is a single binary with a small control plane that a two-person team can reason about. Kubernetes adds a control plane, CRDs, controllers, add-on version drift, and a release train you have to keep up with. That gap is the real cost of the migration, far more than the YAML.

The release train is concrete. Kubernetes ships minor releases roughly three times a year (Kubernetes release cycle), and each minor version gets about 14 months of patch support: 12 months standard plus 2 months of maintenance mode (Kubernetes patch releases). Fall behind on Amazon EKS and the control plane goes from $0.10 to $0.60 per cluster per hour under extended support (Amazon EKS pricing). The CNCF also reports that cultural and operational shifts have overtaken security as the main hurdle to cloud native adoption (CNCF).

What Kubernetes gives back is large: the operator ecosystem, Helm and Kustomize, HPA and KEDA autoscaling, Gateway API, the CNCF observability stack, deep cloud integration and a much larger hiring pool.

The work that rarely makes the migration budget: control-plane and node-group upgrades, add-on compatibility matrices, RBAC design, NetworkPolicy, cost attribution, and a developer experience that stays worse than Nomad's until someone builds it.

You have three ways to close the gap:

• Staff platform engineers on managed Kubernetes with Argo CD or Flux, plus Terraform or Crossplane.
• Adopt an internal developer platform that operates the cluster and gives developers self-service.
• Move to a hosted PaaS and give up running in your own cloud account.

So the real question is who operates the Kubernetes layer on Monday morning.

How can Qovery make the Nomad to Kubernetes migration fast?

Qovery provisions and operates Kubernetes inside your own AWS, GCP, Azure or Scaleway account, or connects to your existing self-managed cluster. That removes the two slowest parts of a Nomad migration: building the landing zone, and rebuilding a developer experience as simple as nomad job run. Your cluster, data, VPC and cloud bill stay in your name.

BYOC, precisely. Your workloads run in your cloud account, so you keep your committed-spend discounts, VPC peering, private networking and audit boundary. With a hosted PaaS, the workloads leave your account and those advantages go with them.

Why it shortens the timeline. The landing zone (cluster, networking, ingress, observability wiring, RBAC) takes the longest in most migrations. Qovery sets it up, so your team spends those weeks moving workloads.

What you get: Kubernetes on AWS, GCP, Azure, Scaleway or your own cluster, git-push deployments, a preview environment per pull request, auto-stop for non-production environments, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

It fits Nomad habits. Bad ergonomics kill these migrations. A team that ran nomad job run app.hcl should not get a 300-line Helm chart in return. With Qovery they push to git (or ask their coding agent), and the Deployment, Service, ingress and secrets get generated for them.

It maps to the table above. Nomad namespaces and ACLs become per-environment RBAC, the update block becomes a managed rollout, Consul and Vault can still live in your cluster, and stateful jobs land on managed databases.

Qovery is not the only option. Staying on Nomad makes sense for largely non-containerized fleets. Raw EKS/GKE/AKS with Argo CD and Crossplane is right if you already have platform engineers. Heroku, Render, Fly.io or Northflank are simpler if you truly do not need your own cloud account. Humanitec, Porter and Backstage occupy adjacent positions and deserve a look. Qovery fits teams that must keep workloads in their own cloud account and want to ship without a dedicated DevOps hire.

*Time to first production deploy is my engineering estimate, not survey data.

How long does a Nomad to Kubernetes migration take, and what does it cost?

For a containerized fleet, plan in weeks. As an engineering estimate (my judgement from running Kubernetes in production and talking with CTOs, not survey data), a 20 to 50 job estate takes roughly 4 to 8 engineer-weeks of translation plus one or two release cycles of parallel running. The cluster and platform build takes longer than the jobspecs.

Rough phase breakdown: inventory (days), landing zone (1 to 3 weeks), pilot (1 week), bulk translation (2 to 5 weeks), stateful move (1 to 3 weeks), decommission (days).

Hard cost drivers, with control-plane prices as of November 2026:

• Amazon EKS: $0.10 per cluster per hour, $0.60 under extended support (AWS).
• Google GKE: $0.10 per cluster per hour for Standard and Autopilot, with a $74.40 monthly free tier credit per billing account covering one zonal or Autopilot cluster (Google Cloud).
• Azure AKS: free control plane on the Free tier, $0.10 per cluster per hour on Standard, $0.60 with Long Term Support (Azure).
• Scaleway Kapsule: free Mutualized control plane, Dedicated plans from €0.11 per hour (Scaleway).
• Double running both schedulers during the parallel period, data transfer during the stateful move, and engineer time at loaded cost, which is usually the largest line.

Budgets blow up on containerizing raw_exec workloads, databases sitting on Nomad CSI volumes, custom Consul-Template logic with signal-based reloads, and discovering too late that no one owns upgrades.

Levers that cut cost: managed databases instead of volume migration, right-sizing Kubernetes requests from real Nomad allocation metrics, and auto-stop for non-production environments. Respondents to the Flexera survey estimate that 29% of their IaaS and PaaS spend is wasted (Flexera 2026 State of the Cloud Report), and idle non-production environments are an easy place to claw some back.

A definition of done worth copying: zero Nomad clients running, every jobspec archived in git next to its Kubernetes equivalent, runbooks rewritten, alerts re-pointed, a restore test passed on the new storage, and on-call retrained.

How do I run the migration from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can scaffold the Kubernetes setup and deploy translated services into your own cloud account, proposing each change for your approval before anything runs.

Install for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI), globally:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope the skills to the current project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code (OAuth, read-only by default) so the agent can inspect what already exists:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it. It also requires turning on write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills are qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The skills deploy, and the MCP Server operates what is already running.

Then ask in plain language: "take the container image from this Nomad jobspec and deploy it to my GCP account with Qovery, with a preview environment per pull request". The agent proposes the change and waits for your approval. Setup details are in the AI agent quickstart and the Claude Code integration page.