VMware to Proxmox: preparing your migration strategy
Licensing changes are pushing many organisations to reconsider their hypervisor. Proxmox VE is a mature alternative, but a successful migration needs preparation.
Start with an inventory. List every virtual machine with its operating system, disks, criticality and dependencies. Identify applications sensitive to virtual hardware changes, such as software licensed to a MAC address.
Size the target. Storage drives everything: existing shared array, or Ceph distributed storage on at least three nodes. Plan a dedicated network for storage and replication.
Migrate in waves. Non-critical machines first, to validate the procedure and drivers, then business services in agreed windows. Every wave has its rollback plan.
Finally, plan for operations: backup, monitoring, patch management and team training. That is what turns a successful migration into a platform you control over time.
Resilience cannot be bought as a single device. It is designed layer by layer, removing single points of failure.
At compute level, a cluster of at least two or three nodes restarts virtual machines automatically when a server fails.
For storage and networking, double the paths: redundant controllers, aggregated links, stacked or paired switches. A single cable should never be able to stop production.
Power backup, cooling and room monitoring are often overlooked, yet they cause many incidents.
Finally, test. A resilient architecture is one whose behaviour has been checked by simulating failures, and whose procedures are written down.
Having backups is essential. Knowing how fast and in which order to restart services is another question.
Backup protects data. A disaster recovery plan defines how applications are brought back: recovery time and recovery point objectives (RTO, RPO), priorities, standby resources and responsibilities.
Apply the 3-2-1 rule: three copies, on two different media, one off site. Add an immutable copy to withstand ransomware, which now targets backups first.
Document the restart order: directory, databases, then business applications. Without it, recovery takes far longer than expected.
Above all, test restores regularly. A backup that has never been restored is only an assumption.
Sending all shop-floor data to a remote datacenter is neither fast, nor economical, nor always desirable.
Edge computing processes data close to the machines: filtering, aggregation and real-time anomaly detection, without depending on the link to the rest of the IS.
For manufacturers the benefits are concrete: lower latency for control, continuity during network outages, and only useful data sent up to business applications.
The typical architecture combines sensors and PLCs, an Edge gateway that collects and normalises data, then MES, monitoring or digital twin applications.
Cybersecurity must be designed in from the start: IT/OT segmentation, remote access control and equipment updates.
OPC UA and MQTT in modern industrial architectures
Two protocols appear in almost every connected-industry project. They do not compete: they complement each other.
OPC UA is the standard for industrial interoperability. It describes data with context (units, structure, state) and has built-in security. It is ideal for talking to PLCs and equipment.
MQTT is a lightweight publish and subscribe messaging protocol. It excels at efficiently moving large numbers of measurements to data platforms and the cloud.
In a modern architecture, OPC UA collects at shop-floor level, an Edge gateway translates, then MQTT distributes to consuming applications.
The choice depends on the need: semantic richness and control on one side, lightness and large-scale distribution on the other.
Virtualisation
Infrastructure
Business continuity
Industry 4.0
Industry 4.0