What the University of Dhaka's Proxmox Migration Gets Right

The headline number is 45,000 students. The more useful part of the University of Dhaka's Proxmox story is the sequence behind the migration.

The university did not begin by moving every workload at once. Its team tested the platform, validated the design, refreshed the network and storage where necessary, and treated backup and recovery as part of the target architecture.

That is what makes the public case relevant beyond higher education. A VMware-to-Proxmox migration is rarely just a hypervisor conversion. It changes how the organization handles storage, network traffic, administrator access, backups, recovery and day-to-day operations.

Computer Port has no relationship with the University of Dhaka. This article analyses the official Proxmox success story and draws out the planning questions that apply to other infrastructure teams.

What changed at the university

According to the official Proxmox case study, the University of Dhaka had critical workloads spread across VMware ESXi and XenServer. Licensing costs were increasing, upgrade options had become restrictive, and the existing environment did not provide the high-availability model the team wanted for important services.

The university began with a pilot. After validating cluster behaviour and management workflows under real workload patterns, it put a five-node Proxmox VE cluster into production and moved critical applications in controlled stages.

The target design included more than the hypervisor:

• a redundant 10 Gbps network backbone
• separation of public, management, cluster and Ceph traffic
• SSD storage for I/O-intensive workloads
• a combination of Ceph and existing SAN storage
• Proxmox Backup Server for local recovery
• remote-site replication for protection against a local failure

The university now uses Proxmox VE for most core applications and as the default platform for new deployments.

Lesson 1: a pilot should answer a decision

Many migration pilots become product demonstrations. A few test VMs are created, the interface is explored, and the team confirms that the platform starts.

That is not enough evidence for a production decision.

A useful pilot should represent the estate that will eventually move. It should include at least one workload with meaningful storage activity, one Windows workload, one Linux workload, one application with network dependencies and one system that must be restored from backup.

The pilot should produce written answers:

• Does the guest operate correctly with the target drivers?
• Does application performance remain acceptable under realistic load?
• Do VLANs, firewall rules, DNS and time services behave as expected?
• Can monitoring, backup and identity systems reach the new environment?
• Can the team restore the workload and validate it without improvising?
• Which operating tasks require training or new documentation?

The output is not simply pass or fail. It is a list of what can move, what needs remediation and what should wait.

Lesson 2: the network is part of the platform

The University of Dhaka case makes network separation visible. That matters because cluster communication and distributed storage can place very different demands on the network from ordinary user traffic.

A Proxmox design may need distinct paths for:

• management access
• cluster communication
• Ceph replication and recovery
• VM and container traffic
• backup traffic
• migration traffic

The exact separation depends on workload, scale, hardware and recovery requirements. The important point is that these flows must be measured and designed before cutover.

A migration can appear successful while a network bottleneck is waiting for the first node failure, backup window or Ceph recovery event. Testing only steady-state performance misses the moment when the infrastructure is under pressure.

Lesson 3: local restore and off-site protection solve different failures

The university combined Proxmox Backup Server with remote-site replication. That is a useful reminder that a fast local restore and protection from a local incident are different requirements.

Local backup storage can shorten recovery time for common failures. An off-site copy protects against a broader event affecting the primary location. Neither one removes the need to test a restore.

For each critical service, the recovery plan should identify:

• the system or data that must be protected
• the required restore point
• the dependencies needed before the service can start
• the person responsible for initiating recovery
• the person who confirms that the application is usable
• the evidence retained after the test

A green backup job confirms that data was written. It does not confirm that the business service can return in the required order.

Lesson 4: migration is also an operating-model change

The University of Dhaka moved Proxmox from pilot to production and then made it the standard for new deployments. That shift requires more than a successful cutover.

The operating team needs clear practices for:

• host and cluster updates
• capacity and performance review
• storage-health monitoring
• backup exceptions and restore tests
• administrator access
• alert ownership and escalation
• change records
• hardware and firmware lifecycle
• incident response

Without this work, the organization replaces one virtualization platform but carries the same unclear ownership into the new environment.

A practical readiness review

Before choosing a migration date, an infrastructure team should be able to answer five groups of questions.

Workloads

Which VMs are in scope? Which applications, databases, operating systems and licensing constraints sit inside them? Which workloads should remain on the current platform for now?

Hardware and storage

Can the existing servers, controllers, NICs and storage support the target design? Is local ZFS, shared storage or Ceph appropriate for the required failure model and operating capability?

Network and dependencies

Which VLANs, firewall paths, DNS services, directories, monitoring tools, backup systems and external integrations are required by each workload?

Recovery and rollback

Is there current restore evidence? What is the rollback condition for each migration wave? Who decides whether a workload is ready to remain on the new platform?

Operations

Who owns updates, backup review, capacity, alerts, documentation and post-cutover support? What does the team need to practise before production migration begins?

The real lesson from 45,000 students

Scale attracts attention, but the University of Dhaka story is valuable because it shows a disciplined order of work: pilot, design, segmentation, migration, recovery and standardization.

That order is more reusable than any single hardware specification.

Computer Port IT Solutions is a Proxmox Silver Partner in India. We help organizations assess VMware estates, select representative pilot workloads, design Proxmox VE and Proxmox Backup Server environments, plan migration waves and define post-cutover ownership.

If your organization is reviewing its virtualization platform, start with the estate and the operating requirements before setting the migration date.

Discuss a VMware-to-Proxmox readiness assessment

Sources and image credit

• University of Dhaka chooses Proxmox to keep 45,000 students online, Proxmox Server Solutions, 25 February 2026
• Cover photograph by Brett Sayles on Pexels. The photograph is illustrative and does not show the University of Dhaka infrastructure.