What’s the best way to move a large Docker-based application to the cloud?

The most important part is reliability planning, not just choosing where each container runs. Make sure every important service has tested backups, documented restore procedures, monitoring, alerting, encryption, and a clear recovery target. A deployment that works under normal conditions can still fail badly if a disk, VM, zone, or database is lost.

Before migrating, document dependencies and define what data can be rebuilt versus what must be replicated. Then move in stages and test each migration, rather than changing the entire architecture at once.

Start by separating the stateless services from the stateful ones. The Node.js app, API, and processing workers should be easy to redeploy and scale independently. Databases, Kafka, object storage, and similar services need a much more careful plan for persistence, backups, replication, and recovery.

Don’t split every container into a managed service immediately. First collect real usage data for at least a few weeks: CPU, memory, disk I/O, query latency, storage growth, and queue lag. That will show whether the actual bottleneck is compute, memory, storage, or a particular database.

A sensible migration could move one stateful component at a time. PostgreSQL is often a good first candidate for a managed service because automated backups and recovery are valuable. MinIO could potentially be replaced with the cloud provider’s object storage, provided your application does not depend on MinIO-specific behavior. Be especially cautious with Kafka and ZooKeeper; managed Kafka may be worthwhile if you don’t already have strong operational experience with it.

For the resource-heavy processors, use separate compute instances or a container platform with autoscaling rather than placing them alongside your databases. If their workloads are interruptible, spot or preemptible instances can reduce costs, as long as the jobs can resume safely.

Keep the web and API containers stateless behind a load balancer, then scale the workers based on workload indicators such as queue depth or processing latency. Stateful services should not be scaled just because the application tier needs more capacity.

I wouldn’t assume that a fully managed version of every component is the cheapest or best design. Managed ClickHouse and Neo4j can become expensive quickly, while operating them yourself requires reliable monitoring, backups, upgrades, and failure testing.

A practical lower-cost approach is to place stateful systems on a small number of appropriately sized VMs and run the stateless applications and workers separately. You might use managed PostgreSQL and cloud object storage first, while keeping ClickHouse or Neo4j self-hosted until measurements show that their operational burden justifies a managed offering. Size the machines from actual resource history rather than estimates.