@ECRTechZ How many images are you talking about?
Either way if you can’t access the database, exporting the image records will be not possible.
In regards to FOG and images, there are two parts. The raw disk images are stored in /images/<image_name>
on the FOG server hard drive. The second bit is the image metadata stored in the database. You should be able to reconstruct the image name from the directory path on the old hard drive. If the customer was smart they would have embedded a bit about the image in the image name, i.e. Win7SP1OEM
. That would tell you what OS the image was in.
The fields that are going to trip you up are Image Type and Image Manager
The image type defines how the image was captured. Raw, Single disk resizable, multiple disk resizable.
The image manager tell the FOS engine what image cloning tool to use. For images that came from 0.3x days then its PartImage. For the 1.2.0 it could be PartImage or more probably PartClone. You can disregard the zstd images because that is something new in 1.3.5 and later.
I see that you deployed FOG 1.4.0. The latest release is 1.4.2 and maybe worth the upgrade. If you had FOG 1.4.1 then I would say for sure upgrade. There was a bug in the new install version of 1.4.1 that caused a client check-in issue, that was resolved in 1.4.2.
FWIW, I think your client will be much better off with the setup you are proposing now than trying to resurrect FOG 1.2.0. The newer version of FOG are much faster and have more abilities than FOG 1.2.0 ever dreamed. Plus FOG 1.3.x and newer support Win10, GPT format, NVMe drives, UEFI firmware and much newer hardware than 1.2.0. Its a good move all the way around.