Is there a procedure I can read that will teach me how to move/copy files from an NFS mount to a directory on the local VM
That's a fairly open ended question. If it were me I would use "scp". Possibly in conjunction with "tar". But I would also have Linux running on both sides and I have a feeling that you are running Windows.
Of course this is also all starting with the db on an NFS share so it might be even simpler to just (temporarily)) mount that share on the target server.
... and redirect the applicaiton/database to the new landing zone?
DO NOT JUST MAKE OS COPIES OF A LIVE DATABASE. They will be corrupted.
If you are going to copy files using os commands first shutdown the db. You can then safely copy the files but you must get all of the pieces (and they might be spread around) and you must preserve the timestamps.
The preferred method is to use probkup and prorest. These tools know all about what it takes to make a proper copy of a Progress database. 3rd party tools usually have no idea what a Progress database is and even less of an idea how to properly back it up.
To make a probkup:
proenv> probkup online dbname dbname.pbk -com -Bp 10
(Omit "online" if the db has been shutdown.)
This will create a single dbname.pbk file. It might be quite large if your database is large. There are ways to break it into multiple files but I will assume that one file is easier to work with and more in line with your needs right now.
If you can preserve the path names then you should just be able to restore a backup of the database to the same path that you backed it up from. That would be the safest and easiest solution.
proenv> prorest dbname dbname.pbk
(This pre-supposes that Progress has been installed in the local VM.)
If you feel that you must change the path then you can still do that by restoring a backup.
If the "structure" of the db is complex -- IOW different parts are on different paths, then you will need a dbname.st (structure file) that describes those paths. You can get a copy of the current structure file by running this command on the current server:
proenv> prostrct list dbname
That will create dbname.st. Copy that to the new server and then edit it on the new server.
The procedure above moves the db files. You will need to adapt whatever your current management procedures (scripts, config files, whatever...) to start, stop, backup and generally manage the backend of the db. There is no "one size fits all" answer to that. It is usually very highly specific to the application. Likewise the client side of the application will need to have it's connection configuration redirected if you change anything like the server name or IP address. If you keep the server name the same and just use DNS to point it to the new server and you do not change the connection port numbers then maybe you get lucky and the application never notices anything.
Obviously you would do all of this with a test system before you tried to do it with production.