The best way to test modifications on the VM is probably by using either a "clone" or just by using "snapshots". Clones appear as an independent new VM but actually make use of the original base VM, allow you to make changes, but all changes apply only to the clone, not to the base VM. If you screw things up irreversibly you can always just delete the clone and create another.
Snapshots do not involve creating a new VM, but instead allow you to easily rollback the VM to its prior state if changes you make screw things up.
If you have problems understanding how clones and snapshots work after reading the documentation, or if you have to run a new VM using local files on a different machine, then you will want to make an actual copy. It's a little more work but simpler conceptually so an actual copy is probably the way for you to go.
If you want to make an actual copy this involves just copying the main files for the VM, which generally for VMWare would be the vmdk files, for VirtualBox the vdi's, etc. If you're not sure what you're doing then make copies from within the VM's interface. Once done, all you need to do is copy the file(s) for the VM to a new location and open them from there. I would suggest reading the appropriate documentation for your virtualizing software (e.g., VMWare, Virtualbox) and/or viewing tutorials or other info on the web like this one: http://www.kernelhardware.org/how-to-move-virtualbox-guest-vm/
If the application and database are both running within the same VM, it's very likely that the connection is made via the "loopback" address of "localhost" or 127.0.0.1. In this case there should be no configuration problem with the app and the db after moving them elsewhere on the network, since the application is already configured to always connect to the db running on the same VM as the application (regardless of what the VM's actual ip address is).
