Alternatives to vMotion for moving virtual machines to a different Datastore

The company i work for is running a small virtual environment and has several virtual servers on 2 different ESXi hosts managed by a vCenter, for reasons relating to backup verification i need to make room on one of the ESXi hosts datastores. The host has a NAS Datastore mounted that still has plenty of room left on it, so i figured it would be a good idea to move a few of the larger VMs there, the Problem is our ESXi Hosts are licensed with an essentials license, so i don't have access to storage vmotion, or even enhanced vMotion for this task. Alternatively i thought of using our backup solution (nakivo) to do a full backup of the machines and restore them to the desired Datastore, or cloning the VMs to the desired Datastore or just powering off the machines and migrating them. none of these options are as comfortable as just using vMotion, but i would like to know which of these methods would be the best, in terms of risk, and downtime. Obviously if any of have a better idea on how i could accomplish this with minimal risk and minimal downtime i'm always open to new ideas. The hosts are running ESXi-Version 7.0.2

Forgive me if what I suggest isn't feasible due to your licencing options but while StorageVMotion might not work how about just shutting down the VM/s, browsing to the datastore they're on and moving the files manually from old to new datastore - pretty sure that's 'free' to do, just not while the VMs are running. You may need to remove the VMs from the VC Inventory and then re-add in them from the .vmx file but that's quick to do.

Estimate the price of a couple options, and have the organization - whomever pays the bills - help decide. Both downtime and minimizing downtime have costs. Include costs of downtime and your time, as well as anything purchased.

Backup restore is using tech you already have, so possibly no software cost. You should already be taking backups and doing the occasional restore test, and so have an idea of how long this takes. If you have never done a restore, this is an excellent reason to do one. A simple shut it down and restore is easy to do correctly maintaining data integrity, but could possibly incur hours of downtime. Recovery time and recovery point likely could be improved by being more clever with the restore.

Minimalizing downtime of the system requires some design and infrastructure. Can the applications be made highly available, by being load balanced across multiple compute VMs? Then an option could be to bring up a new instance, have both behind a load balancer for some time, then drain and remove the old instance. High cost of infrastructure, design, and maintenance time, but small downtime of the service. Further, maintaining separate compute instances can be useful, for example during OS upgrades.

And the live migration option. Almost certainly vMotion Storage will involve paying VMware, have sales tell you how much. Also live storage migration has considerable network demands. What this investment buys is a command to move a VM with almost zero downtime. Although this does not exercise your restores, it does not count as backup in a business continuity plan.

You could use VMWare Converter Standalone - a free tool offerd by VMWare themself for virtualization of hardware systems or migration from other virutalization platforms to VMWare. Here you can use the "Virtual2Virtual" function, where you can connect to one virtualization system, and the converter will migrate the system to another. Or you can use the "Physical2Virtual" function - here you handle your source VM like it would be a physical server that needs to be virutalized.

This can also be done as "hot migration" without turning off the source machine - at least if it is no something like a MS Domain Controler, also very with very busy databases I would not really use the "hot migration".