Out of the box features for clustering your applications are adequate and you can tweak (e.g., replace the default service proxies with ingresses to your liking) whatever you like the way you want. The persistent volume mechanism is powerful. Horizontal pod scaling feature saved us a small fortune in hardware.
Installation of some crucial add-ons such as the Kubernetes Dashboard and cluster monitoring require a lot of trial and error and worse, the requirements and the installation steps change with almost every new version.
Assess your applications for their clustering and high availability support (e.g., a web application utilizing the server's web session is not cluster ready and will have to be modified) and their fault-tolerance. If you're not sure, keep the old workload as it is, start new projects with the goal of deploying on Kubernetes.
We saved a lot of money on hardware as we have multiple workloads that are time separated, (e.g., imagine an application that issues invoices and an application that processes payments through banks, invoice issuing requires resources for a few days at the beginning of each month, and the payment processing requires more resources at the end of the month, when the payments are due). We used to buy separate, full capacity servers for the workloads for the few days they required it. When you run over 20 mission critical workloads, that makes a lot of investment in hardware that is idle 70% of the time. After switching to Kubernetes, we have a server farm that is one third the capacity of the previous farm of dedicated servers, and Kubernetes automatically assigns resources to workloads using horizontal pod scalers. For the above example, the invoice issuing workload gets more pods (i.e., more CPU and memory) at the beginning of the month. Then as the invoice workload lightens, the extra pods are killed and the resources are available for other workloads.
As the workloads are not guaranteed to be completely separate in time (some clients will pay immediately on receiving the invoice, instead of waiting for the end of the month), you should plan the cluster capacity accordingly.
Our apps were already clustered so it did not take much effort to migrate to Kubernetes. If you have old-fashioned applications that assume its dependencies (disk space, network, services, database etc.) are always available, they'll need modifying, which is another to ponder about the cost of switching.