@ChrisH a few notes on what others have written above
There is no compatibility between the Windows and the MAC database whatsoever so database bound items, like ‘Projects’ will “die” with the Windows machine.
Ensure all edits are captured in the DOPs, either by setting the ‘Preferences’ settings
The DOP is effectively a copy of the database entries relating to the image and contains the metadata first, followed by edit data followed by the ‘Reject’ etc. Tag. This group is repeated for every (Virtual) copy created by the user, i.e. [M] (metadata, edit data, Tag),  (metadata, edit data, Tag), … (metadata, edit data, Tag) etc… My own setting preference is the ‘Preferences’ option for automatically Reading and writing DOPs.
- Metadata can be handled in a similar manner via the ‘Preference’ option shown in Moving PhotoLab from Windows PC to a Mac Mini - #5 by Aearenda but this is a single option that causes metadata to be read and written automatically (AS=ON), you cannot have automatic reading without automatic writing!
I typically run with this option set but also do some work where the manual options need to be used i.e.
The perceived minus seen by some users is that DxPL will write keywords back to the image in its own favourite format, which may or may not be the same format that the users favourite keyword handler provides!
If any metadata has been set in DxPL that needs to be “flushed” back to the image (for RAW that will be to the xmp sidecar) it should have been written to the image automatically (AS=ON) or will need to be flushed back to the image using the ‘File’/‘Metadata’/‘Write to Image’'command (AS=OFF but can be used regardless of the AS setting).
Any metadata read from the image automatically by DxPL or manually, or added/updated by the user in DxPL will be present in the database and, therefore, will also be in the DOP.
Once all the edit data and metadata has been brought up to date, in the images, metadata sidecars and DOP sidecars it can be transferred to the new system for “importation” by DxPL(Mac), i.e. the following are required for the Transfer to the other system
- The image file
- The xmp sidecar where applicable (only RAW Images are expected to have xmp sidecars files).
- DOP which contains IPTC and keyword metadata, ‘Rating’, ‘Orientation’, ‘Colour Labels’, image edits and the ‘Reject’ flag.
Such importation happens in the usual way by DxPL “discovering” the image folders and/or by using ‘indexing’.
The selection of the automatic synchronisation preference now has a new role (one I object to, it should have been a separate option) or rather it has a new role if it is not set (AS=OFF)!
If AS (automatic Synchronisation) = ON (SET) then the metadata will be taken from the image (xmp embedded or xmp sidecar) as each new image is “discovered”.
But if AS = OFF (not SET) then the metadata will be taken from the DOP as part of the first discovery process and IPTC and keyword metadata etc. in the image (embedded and/or sidecar) will be ignored!!
(While AS=ON/OFF is straightforward in normal use the additional role for first discovery should have been handled with another ‘Preference’ option, in my opinion!)
Agreed, I have USB 3 drives attached to my machines that are copies of my main drive but how do you propose to use that backup copy!? If the receiving DxPL database has no ‘Projects’ then you could simply attach the replacement drive and start discovering the directories again.
But all the old data will still be in the database attached to the original drive id! Because of that issue any ‘Project’ pointers will point to the old data which is no longer available.
So if no ‘Projects’ then backup the database, remove the database and start again using the (hopefully up-to-date) data from the backup copy!
If ‘Projects’ exist then you have one of the following option options
- Assign the old drive identity to the backup drive using a system utility, which implies you have that identity (it will be in the DxPL database of course).
- Hack the database (after making one or two database backups) and change the drive identifier in the ‘Folders’ structure (that is the Windows identifier for the database Table) to the identifier of the replacement backup copy.
- Vote for DxO making the process a whole lot easier but that won’t take the “sting” out of the problem until any such feature is implemented!!
- Abandon the existing database with the ‘Projects’ and start with a new database!!
Hope that doesn’t sound too scary.
While I can help on the Windows side I know nothing about Macs!
PS:- If you have your data on an external drive and decide to move to a machine with the same OS then you should be able to take the database to the new machine and attach the same external drive. I believe my testing (on Win 10) indicated that the UUID of the drive took precedence over the drive letter, i.e. the drive letter on the new system does not matter.
But you cannot carry the database from Windows to Mac.