Kubernetes adoption

We help you move your applications to Kubernetes (AKS or EKS) so they run reliably, scale and deploy automatically. For every application we prepare a container, a Helm chart, GitOps deployment through ArgoCD, monitoring and quality checks.

from CZK 392,000

6 to 8 weeks, up to 3 applications, each extra one +CZK 145,000. Excl. VAT.

Book a consultation

What we offer

We move applications in waves: first one pilot application, then the rest. Every wave has its own verification, parallel running alongside the old environment and a rollback plan, so the move does not put your services at risk.

If an application needs a code change (for example configuration through environment variables, or storing files off the local disk), we describe it precisely and your development team makes it.

We do not write applications. We work only on infrastructure, cloud and DevOps.

When it makes sense

Your applications run on virtual machines or App Service and you want better scaling, density and one way of running them.
You already have Kubernetes, but applications run on it without a standard, each one differently.
Deployment is manual and depends on particular people.
You are consolidating several environments into one platform.

What you get

Applications running on Kubernetes to one standard, verified by quality checks.
GitOps deployment: the state of every environment is always in git.
Automatic scaling and recovery when a pod or node fails.
Monitoring, alerts and a runbook for every application.
A team that understands the new environment.

What exactly we do

Cluster readiness: We check and add the baseline components: ArgoCD, ingress controller, cert-manager, External Secrets and monitoring. Building a new cluster from scratch is priced separately.
Containerisation: A Dockerfile to standard (multi-stage build, non-root, minimal image), configuration through environment variables and secrets.
Helm and deployment: Helm chart, an ArgoCD application per environment, probes, requests and limits, PodDisruptionBudget, HPA, pod spread, ingress and TLS, External Secrets.
Quality checks: Workload Scorecard, 10 checks per application (probes, resources, PDB, non-root, pinned image tag, secrets outside code, scaling, pod spread, logs to stdout, labels). The goal is green for all of them.
Moving traffic: Parallel running on the old and the new environment, traffic switch (DNS or ingress) in an agreed window, rollback plan.
Monitoring and runbook: A dashboard, alerts and a first-line runbook for every application.

Who works on it

Three people work on the project. The effort in days is for three applications.

Senior, project lead
8.5 days

Responsible for
Migration and wave plan, deployment architecture, quality control, go/no-go decision for every switch, risk communication.

What you get from them
Main contact, migration plan, decisions
Middle
28 days

Responsible for
Cluster readiness, Helm charts and ArgoCD, the pilot application, harder applications, traffic switches.

What you get from them
Migrated applications, templates
Junior
25.5 days

Responsible for
Dockerfiles and configuration from templates, tests in dev and test, scorecard, dashboards, runbooks and documentation.

What you get from them
Containers, tests, documentation

We assign work by complexity: juniors do routine work from templates, the middle takes the harder parts, and the senior owns the design, quality control and risk decisions. You do not need to decide who does what. The effort in days is indicative and only explains the price. The price is fixed and does not depend on the days actually worked.

How the project runs

For three applications we plan 6 to 8 weeks, and each extra application adds roughly 1 to 2 weeks. The pilot application proves the process and templates, so the rest move faster and with less risk.

Weeks 1 and 2: analysis and migration plan
Goal: Understand the applications, prepare the cluster and plan the waves.
- Inventory of applications: dependencies, state (sessions, files on disk), scheduled jobs, ports, configuration.
- Assessment of how well each application fits Kubernetes.
- A list of code changes for your developers, if needed.
- Cluster review and the missing baseline components added.
- Choice of the pilot application and a wave plan with switch windows.
Output: A migration plan approved by you. Who: senior, middle on the cluster
Weeks 2 and 3: pilot application
Goal: Prove the whole process on one application, all the way to production.
- Container, Helm chart, ArgoCD and monitoring for the pilot application.
- Deployment to dev and test, verified by your tests.
- Parallel running and the production traffic switch in an agreed window.
- Review and adjustment of the templates for the next waves.
Output: Pilot application in production on Kubernetes, proven templates. Who: middle, switch decision by the senior
Weeks 4 to 6: further waves
Goal: Move the remaining applications.
- For every application: container, chart, dev, test, production.
- Parallel running on the old environment until you confirm.
- A scorecard for every application.
Output: All applications in scope in production on Kubernetes. Who: junior from templates, middle on harder applications and switches, senior review
Weeks 7 and 8: stabilisation and handover
Goal: Tune operations and hand over to your team.
- Tuning requests, limits and scaling to the real load.
- Shutting down the old environment once you confirm.
- Documentation, runbooks, a workshop for developers and operations.
Output: Stable operations, documentation handed over, a trained team. Who: the whole team, the senior leads the workshop

How we work together

Main contact: The project lead (a senior). Accountable for the result, deadlines, risks and decisions. Day to day you can talk to anyone on the team directly.
Communication: A shared Slack or Teams channel and a ticketing system of your choice. Every question and change leaves a trail.
Kick-off: At the start we confirm the scope, access, contacts and the dates of the key milestones.
Weekly status: A short 15 to 30 minute sync: what is done, what is next, what we need from you and which risks we see.
Final readout: We present the results to your team and management and go through the next steps.
Escalation: Junior → middle → project lead. If a deadline or a major risk is at stake, the project lead contacts you the same day.
Working hours: Working days, 8:00 to 17:00 Central European Time. Production changes happen in a window you choose, always through your change management.

What we need from you

The timeline holds if we have the following. If something is delayed, the schedule moves by the same time and we tell you straight away.

An existing AKS or EKS cluster and cluster-admin rights for the duration of the project.
Access to the cloud, the registry and DNS.
A developer or tech lead for each application, and the code changes made if needed.
Test scenarios or smoke tests to verify the applications.
Decisions on the traffic switch windows (within working hours).
Information about databases and application state.

Access and security

Every team member has their own named account. We do not use shared accounts.
We ask only for the permissions a phase needs. Where read access is enough, we work read-only.
We do not take data out of your environment. Our documents contain only the summaries the result needs.
When the project ends, you remove our access, or we remove it on request and confirm it.
If you wish, we sign an NDA before the kick-off.

What is included and what is not

Included in the price

Analysis, migration and wave plan
Missing baseline cluster components added
Move of up to three applications, pilot included
Helm charts, ArgoCD, monitoring, scorecard and runbook for every application
Parallel running and traffic switch
Documentation and workshop

Not included: priced separately or on your side

Migration of databases, persistent data and shared files
Application code changes (we describe them, your developers make them)
Building a new cluster from scratch
Load testing beyond the verification tests
24/7 on-call and cloud costs

If we find during the project that reality differs from what we assumed, we tell you before we work outside the scope. We send a short estimate of the impact on price and timeline and continue only once you agree.

Deliverables and acceptance

Deliverable	Contents	Form
Migration plan	Inventory, assessment, waves, code changes	PDF and Word
Containers and charts	Dockerfile, Helm chart, ArgoCD for every application	In your repository
Scorecard	Result of the 10 checks for every application	Report
Monitoring	Dashboards and alerts	In your monitoring
Runbooks	First line for every application	Markdown in the repository
Workshop	Training for development and operations	Recorded meeting

The project is done when:

Every application in scope runs in production on Kubernetes.
The scorecard is green for all applications.
Deployment runs through ArgoCD from git and rolling back to the previous version is verified.
Applications run for 5 working days after the switch without an incident caused by the migration.

We hand over the deliverables and go through them with you. We incorporate comments in one round within 5 working days of receiving them.

Risks and how we handle them

Risk	How we handle it
The application keeps state locally	We find it in the first phase and propose a change, or move the application to a later wave.
Hidden dependencies	Parallel running and a gradual switch. Traffic can go back to the old environment.
Different performance on Kubernetes	Resource and scaling tuning in phase 4, monitoring during parallel running.
Code changes are delayed	We pick a pilot that needs no changes and adjust the order of the waves.
A database needs migrating	Handled separately, with its own plan and price.

Price and terms

from CZK 392,000 excl. VAT for up to three applications, each extra application +CZK 145,000.

Duration: 6 to 8 weeks for three applications.
Prices exclude VAT, invoiced in CZK or EUR.
Work outside the scope: a separate quote, always in advance.

What can follow

Next steps

1A short 30 minute call: we look at your environment and check that the service fits what you need.
2We confirm the scope, the start date and the contact people.
3We send the contract and the list of access we need to start.

Frequently asked questions

Do we need a cluster?

The price is for an existing cluster. If you do not have one, we build it from our module and price it as a separate item.

Why not everything at once?

The pilot proves the process and templates on one application. Later waves are then faster and the risk of an outage is minimal.

What about databases?

Databases and persistent data are handled separately. It is often better to keep them as a managed cloud service, outside the cluster.

Tell us what you are working on.

Thirty minutes, free. We reply within one working day.