--- /dev/null
+Broadly 4 strategies found:
+
+(1) Just copy
+
+ => Proxmox
+
+ => several others have this as a fallback for unsupported OSes
+ (including MTV)
+
+
+(2) Source agent does changes, followed by copy
+
+ => Nutanix, Platespin, NetApp
+
+ => IMHO the most compatible method, but requires guest credentials
+
+ => several other solutions have optional source agents, for faster copying
+
+
+(3) Copy, then modify on the target
+
+ => Coriolis, Azure, AWS, GCP, VMware
+
+ => virt-v2v conceptually works like this too
+
+
+(4) Managed VMware ESXi
+
+ => Azure, AWS, GCP have hosted VMware offerings
+
+
+(5) Emulate VMware drivers
+
+ => QEMU can support this since it can emulate VMware pvscsi & vmxnet3.
+
+ => I only mention this because no one does it, which was surprising.
+
+
+(6) Not enough info to tell what they are doing
+
+ => Starwind, Datamotive, Civo
+
+
+
+
+== Proxmox
+
+https://www.proxmox.com/en/services/training-courses/videos/proxmox-virtual-environment/proxmox-ve-import-wizard-for-vmware
+
+Just a disk copy. The guest is initially booted with SATA. They give
+you a recommended set of manual steps to run afterwards, which
+includes attaching the virtio-win ISO and installing drivers, and
+manually installing the guest agent.
+
+== Nutanix Move
+
+https://www.nutanix.com/how-to/steps-to-migrate-to-nutanix-from-vmware
+https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_6:Nutanix-Move-v4_6
+
+They have useful adjacent sizing and workload gathering tools.
+
+VMware Tools must be installed on the source.
+
+"Source preparation scripts" must be run on the source VM before
+conversion. This rebuilds the initramfs / installs virtio drivers,
+and retains IP addresses.
+
+"Data-only" conversions are also possible. Also you can do the source
+preparation manually.
+
+Warm copying + cut-over (using snapshots + VDDK + CBT).
+
+== Platespin Migrate
+
+https://www.microfocus.com/documentation/platespin/
+https://www.youtube.com/watch?v=cjgWoqgNbbM
+
+Requires VM login credentials (at Administrator / root level).
+
+The source and target VMs appear to communicate directly with
+each other over a TCP port.
+
+Can do some crazy stuff like consolidating filesystems from different
+disks together into a single disk, and changing EFI to BIOS, so it
+seems likely that it may be rebuilding the VM on the target from
+scratch.
+
+On Linux, uses blkwatch, LVM snapshots and fsfreeze/thaw, so it is
+likely doing in-guest, block-level change block tracking.
+
+== Coriolis
+
+https://cloudbase.it/coriolis-vmware-to-openstack-web/
+
+Copy disk over
+
+"OS morphing" step, which appears to mount the OS disks somewhere and
+presumably modify them.
+
+It's source available here:
+https://github.com/cloudbase/coriolis/tree/cef6f690744745ff3d9f19f26ab177b85158cc21/coriolis/osmorphing
+
+== StarWind
+
+https://www.starwindsoftware.com/starwind-v2v-converter
+
+I could find no useful information about what this is. It possibly
+just converts the VM disk format and nothing else?
+
+== NetApp Shift
+
+Pre-conversion with an agent installed in the source VM, followed by a
+clever in-place copy-and-format-conversion which means the copy can be
+very fast. Requires you to use NetApp storage on both ends.
+
+== HPE Zerto
+
+https://www.hpe.com/us/en/zerto-software.html
+
+This is not really V2V as such. The software allows VMs to be
+replicated between vSphere and Hyper-V (only) for some kind of
+disaster recovery solution. While the live VM is running, block-level
+replication keeps the replica in synch. Somehow VMs that are
+replicated this way can run on either kind of hypervisor, which I
+guess is quite clever.
+
+== Datamotive EasyMigrate
+
+https://www.datamotive.io/blog/moving-off-of-vmware-make-it-easy-with-datamotive
+
+The website is so full of BS it's really hard to tell what's going on.
+
+== Civo
+
+https://www.civo.com/vmware-alternative
+https://www.youtube.com/watch?v=31eKJybGu1o
+
+No real technical details.
+
+== Microsoft VMware to Azure
+
+https://learn.microsoft.com/en-us/azure/migrate/start-here-vmware?view=migrate-classic
+https://learn.microsoft.com/en-us/azure/azure-local/migrate/migration-azure-migrate-vmware-overview?view=azloc-2507
+
+They have "agent-based" and "agentless" but this appears to be
+something like our cold vs warm conversions. Agentless uses VMware
+snapshots + CBT.
+
+"Hydration" is the name they use for VM conversion. It is only done
+for supported OSes, other OSes are converted unchanged.
+
+Hydration works by creating a new VM and attaching the copied disks
+from the source VM, to make the changes.
+
+They also have a native VMware on Azure offering:
+
+https://learn.microsoft.com/en-us/azure/azure-vmware/introduction
+
+== Amazon AWS Transform
+
+https://aws.amazon.com/transform/vmware/
+
+(Acquisition of CloudEndure Migration, but I think this software is
+different.)
+
+"MGN Connector" connects to each source guest over SSH or WinRM
+(requiring credentials). Can also be done by manual installation.
+
+Snapshots + cutover. Uses VDDK.
+
+Seems as if driver installation is done post-copying.
+
+I think there may be two different pieces of software here, the older
+MGN and the new VMware Transform?
+
+Amazon also have a VMware Service (Amazon EVS)
+
+== Google Cloud VMware Engine
+
+Google Cloud VMware Engine is essentially VMware on GCP:
+
+https://cloud.google.com/vmware-engine
+
+== Google Migrate to Virtual Machines services
+
+True VMware conversion, based on a 2018 acquisition of Velostrata
+Manager. It boots the VM on the cloud directy, reading
+disk blocks from the source. Claims to be agentless, and
+yet able to convert the VM to run on GCP.
+
+Migrate Connector OVA running on VMware (instead of VDDK?)
+
+The current version seems to work quite differently from Velostrata.
+
+https://cloud.google.com/migrate/virtual-machines/docs/5.0/resources/vm-adaptations
+
+"OS adaptions" which are done after copying, include deploying the
+agent and installing virtio drivers. Doesn't appear to require
+credentials.
+
+List of errors possible is interesting:
+https://cloud.google.com/migrate/virtual-machines/docs/5.0/support/os-adaptation-errors-warnings
+
+== VMware Converter
+
+https://knowledge.broadcom.com/external/article/389242/vmware-vcenter-converter-download.html
+
+Can do P2V and V2V from a variety of other hypervisors.
+
+For Windows, requires installation of a guest agent on the source to
+prepare the guest for conversion. It uses snapshots (so maybe CBT?).
+At cut over, drivers are installed on the target and guest agents are
+removed and installed. IP addresses are preserved.
+
+For Linux, it requires SSH access to inspect the source VM. After
+copying over (which also happens over the SSH connection), it does
+some reconfiguration inside the target VM presumably to create the new
+initramfs, and then reboots.