# Co-Managed Kubernetes and VMware Migration Planning

> URL: https://www.atlantic.net/cloud-platform/managed-kubernetes-vmware-migration/ | Published: 2026-10-29 | Author: Richard Bailey

An enterprise infrastructure team approached Atlantic.Net about replacing its on-premises VMware environment with hosted dedicated infrastructure. The customer wanted to eliminate the cost and responsibility of owning physical hardware while supporting a combination of Kubernetes application workloads and virtual machines for databases and infrastructure services.

We began reviewing the infrastructure and network requirements to determine the most suitable hosting approach. Both our[ Bare Metal Servers](https://www.atlantic.net/dedicated-server-hosting/bare-metal-servers/) and[Managed Private Cloud](https://www.atlantic.net/dedicated-server-hosting/managed-private-cloud/) services were relevant options, though each offered different levels of infrastructure management.

The initial discussions focused on understanding the existing environment, identifying technical requirements, and exploring possible architectures. A final server configuration and production service agreement had not yet been established.

## Reviewing The Existing Infrastructure And Capacity Requirements

The customer operated 22 VMware ESXi hosts supporting its existing application and database workloads. At the time of the inquiry, the applications still ran on virtual machines, although the customer planned to move them into Kubernetes as part of the migration.

The customer expected containerization and consolidation to reduce its CPU requirements. It anticipated that memory demand would remain broadly unchanged.

The preliminary infrastructure inventory provided the following estimates:

| **Workload** | **Customer’s Supplied Sizing** | **What Needed Reviewing** |
| --- | --- | --- |
| **Existing application estate** | 283 VMs, 794 vCPUs, 2.6 TB RAM, 11.3 TB storage | Actual utilization and application dependencies |
| **Projected application estate** | 400–480 vCPUs, approximately 2.6 TB RAM | Expected savings from consolidation and Kubernetes scheduling |
| **Database estate** | 90 VMs, each with 8 vCPUs, 64 GB RAM, and 200 GB storage | Database performance, I/O demand, and recovery requirements |
| **Database totals supplied** | 720 vCPUs, 5.76 TB RAM, and 18 TB storage | Allocated resources compared with actual usage |
| **Infrastructure services** | Approximately 30 additional VMs | Individual resource requirements and service dependencies |
| **Expected growth** | Less than 10% annual compute and memory growth | Capacity planning and future expansion |

One of the main considerations was the difference between allocated virtual CPUs and the physical processor capacity required to run them. The customer-supplied figures described its existing allocations but did not necessarily reflect the hardware needed in a replacement environment.

We therefore requested additional information about CPU utilization and oversubscription. This would help establish how efficiently the workloads could be consolidated and how much physical capacity the proposed infrastructure would require.

Memory was another important consideration. Although the customer expected to reduce its allocated CPU requirements, it still anticipated approximately 2.6 TB of application memory alongside the database estate.

Any proposed configuration needed sufficient memory for normal operations, expected growth, and workload availability during a host failure. We also needed to examine storage utilization and I/O performance rather than relying solely on the allocated capacity figures.

## Establishing The Co-Managed Responsibilities

The customer preferred a co-managed hosting arrangement. The customer wanted Atlantic.Net to manage the underlying physical infrastructure while retaining control of Kubernetes, virtual machines, operating systems, and applications within its internal engineering team.

Around-the-clock infrastructure support was also an important requirement.

Our[Managed Private Cloud](https://www.atlantic.net/dedicated-server-hosting/managed-private-cloud/) service offered managed virtualization infrastructure, but the customer’s proposed division of responsibilities required a more specific agreement. During the assessment, we needed to establish which activities Atlantic.Net would manage and which would remain with the customer’s engineers.

The customer was also interested in moving away from VMware licensing. It had identified Proxmox as a possible alternative but remained open to other suitable virtualization platforms.

No final hypervisor had been selected during the initial discussions. The customer also had not chosen a Kubernetes distribution, and the application containerization work was still in the planning stage.

Our[Infrastructure Cluster Solutions](https://www.atlantic.net/dedicated-server-hosting/infrastructure-cluster-solutions/) provided another option worth considering. These solutions combined dedicated infrastructure with networking, security, monitoring, and protection capabilities.

The size and scope of the customer’s environment meant we needed to assess the hardware and operational requirements independently, rather than assume a standard cluster configuration was sufficient.

## Evaluating Network Capacity And Connectivity

Network performance was a consideration for the proposed migration.

The customer reported an average historical throughput of about 1.9 Gbps, with peaks reaching about 2.8 Gbps. Estimated monthly data transfer was about 600 TB.

These figures gave us a starting point for capacity planning, but we needed to understand traffic patterns in more detail before recommending a network configuration.

In particular, we needed to determine how much traffic went to and from the Internet, how much stayed within the existing infrastructure, and which applications or services drove the highest demand.

The network assessment covered communication between Kubernetes workers, databases, storage, and recovery systems. These internal connections could have different bandwidth and latency requirements from public-facing application traffic.

The proposed environment also required private networking, firewall rules, IP addressing, and any existing external security services.

The customer also identified HIPAA requirements for some of its workloads. This introduced a further assessment of the hosting environment, applicable security controls, and the division of compliance responsibilities. We needed to establish which workloads handled regulated information rather than assume the same requirements applied across the entire platform.

## Defining High Availability And Disaster Recovery Requirements

The customer wanted high availability across its production workloads and identified specific recovery objectives for critical applications and databases.

The customer requested a recovery time of about two to four hours, with a recovery point objective of less than 30 minutes for critical systems.

These figures represented the customer’s requirements during the initial discussions. We had not yet agreed on a recovery architecture or confirmed that the proposed infrastructure could meet those objectives.

A key part of the assessment involved understanding which failures the environment needed to withstand.

For example, recovering from an individual physical host failure presented different challenges from restoring a database, recovering corrupted data, or bringing an entire application online following a major infrastructure outage.

The Kubernetes environment introduced additional considerations around workload scheduling, application availability, persistent storage, and dependencies between services.

We also needed to determine how the customer intended to handle recovery across separate physical locations, if the final design included geographic redundancy.

Importantly, infrastructure availability alone would not guarantee that an application had recovered successfully. The customer’s engineering team would need to test database recovery, application functionality, and service dependencies before the recovery arrangements could be considered suitable for production.

## Assessing Backup Storage And Retention

The customer already used Veeam and wanted to retain a structured backup policy following the migration.

Requirements included seven days of application backups, database backup retention of seven and fourteen days, and monthly database backups retained for one year.

Our[Managed Veeam Service](https://www.atlantic.net/managed-services/veeam-services/) was relevant to these discussions, although the customer had not yet provided a complete inventory of its backup data.

Without that information, we could not accurately estimate the storage capacity needed for the proposed retention policy.

We needed to understand the total volume of protected data, how often it changed, and the required backup type. Repository placement, off-site copies, and restore procedures would also influence the final design.

The requested recovery point objective introduced a further consideration. Retaining backups for seven or fourteen days did not automatically allow recovery from less than 30 minutes before an incident.

We therefore needed to assess whether additional backup frequency, database-specific protection, or replication would be required to meet the customer’s recovery expectations.

## Reviewing Processor Configuration And Licensing

During the technical review, our engineering team noticed a discrepancy in the existing VMware host information.

The supplied host export appeared to show fewer active processor cores than expected from the listed hardware specifications. We asked the customer whether this configuration had been influenced by software licensing.

The customer considered VMware licensing a possible explanation and said it did not expect to keep the same restriction after moving away from the platform.

Although this appeared plausible, the correspondence did not establish the exact reason for the configuration.

The observation highlighted another important part of the migration assessment. Changes to the physical processor configuration, enabled core counts, and workload placement could affect the customer’s software licensing costs.

Before finalizing the hardware design, we needed to establish whether any operating systems, databases, or other licensed applications imposed restrictions or additional costs based on processor capacity.

## Planning The Proof Of Concept And Migration

The customer proposed beginning with a proof of concept (POC) before migrating its production workloads.

It wanted the existing VMware environment and the new infrastructure to run alongside each other until the replacement platform was tested and validated.

This approach allowed the customer’s engineering team to evaluate the proposed virtualization platform, assess Kubernetes performance, and confirm how its applications and databases behaved in the new environment.

The customer expected to handle most application migration activities internally. It requested assistance with infrastructure provisioning, network configuration, and the initial platform deployment.

Our[Migration Services](https://www.atlantic.net/managed-services/migration-services/) were relevant to the infrastructure work discussed, but the teams needed to agree on the exact responsibilities.

We identified several areas to validate during the POC, including application and database performance, network throughput, backup restoration, and the operational responsibilities associated with the co-managed arrangement.

The customer also discussed a longer commercial commitment and potential upfront requirements. These conversations remained preliminary, with the final scope and commercial terms still to be agreed.

The correspondence raised a year-end migration target, although this was an initial planning objective rather than a confirmed deployment schedule.

## Bringing The Infrastructure Requirements Together

The discussions gave us a clearer understanding of the customer’s plans to replace its VMware infrastructure while preparing its applications for Kubernetes.

The proposed environment needed to accommodate substantial database and memory requirements, high network throughput, and a combination of virtualized and containerized workloads. It also needed a clearly defined co-managed support arrangement that allowed the customer’s engineering team to retain control of its applications and software platforms.

Further technical validation was necessary to establish the appropriate physical hardware, virtualization platform, storage architecture, and recovery arrangements.

The proposed proof of concept offered a practical way to assess these requirements before committing to a production migration. It also provided an opportunity to clarify operational responsibilities and determine whether the proposed infrastructure could accommodate future growth.

If your organization is considering a similar move from VMware to dedicated infrastructure,[contact our solutions team](https://www.atlantic.net/about-us/corporate-contact/). Share your existing virtualization inventory, workload utilization, Kubernetes migration plans, and backup requirements. We can help assess your infrastructure options and develop a phased migration plan that reflects your technical and operational needs.