Not really. That would just be the easiest way to do that.
Another equally easy implementation would be to assign the user an internal name and database ID, stored outside of the card, and use that to identify the user and generate the passphrase.
You can clone the UID into any “magic” card with the correct UID length.
But that would only work if the system in question uses only UID and don’t even check for card type.
The reason why a DF can’t be clone goes beyond the UID.
You would need not only to be able to find a magic DF card, but would also be able to have access to the application Key in order to read the encrypted block of information relating to said application and clone it to the new card.
(there is more than that in play, but in a nutshell, that’s it).
Since the application key should only be found on the application admin side, you wouldn’t find it by sniffing neither the card nor the terminals.
If they are migrating from Classic to DF, I would expect (hope?) that they would also be upgrading to a more robust security practice.
But let’s assume they would just be tossing some credentials into blocks 14 & 15…
Even then, this scenario tells me they would be going lazy and probably getting a ready made script from someone else (there are quite a few available).
Those scripts take into consideration that the interface between reader and card is slightly different based on which card it is.
i.e. the way a reader would ask for a Mifare Classic “what’s the data on your Sector X” could be slightly different from how it would ask a DF “what’s the data on your Sector X”.
So the system should first query the card about “what type of card are you?” and then it knows how to interface properly with the card.
If you have 2 systems being implemented, that’s most likely to be the case, and it makes cloning cross cards very challenging for any system which is not UID based.