With that option, the Data Migration Tool, instead of transferring the actual Data to a new file, it would scramble the data, so the destination file would only contain gibberish data.
The end result would be a complete clone of the production files, but with concealed data.
This would revolutionize tech support, especially FMI's, because the engineer would be able to work in the same condition as actual production file, but without being exposed to sensitive data.
Everything, but the meaning of the data, would be exactly the same, so debugging would be much closer, if not identical as production file. Including the volume of data (so performance problems would show up).
For regular developers, this may even make possible to allow developers without any confidentiality credential to work on the solution, with a sizable volume of data.
Here's how it would work.
Prior migrating the file the DMT would create a random characters substitution table, that wouldn't be stored at all. For making the substitution, impossible to undo, that table will have 2 characters substituted by the same one.
As the same substitution table would be applied on every fields, key matching will be preserved.
The scrambling would have 3 levels that the user could choose, each providing more similarity to the production files :
- Total scrambling like above
- Only text scrambling (number would be left untouched). As number alone are often meaningless it may work great, and would preserve some numeric keys like ids
- Not substitue one character only fields. 1 character is not enough to convey exploitable data, but can be used in some keys like 1
Or some variant of that, for instance, not touching serial auto_enter fields.
With that, never again, FMI's tech support would see people not sending them their solution for debug. This would offer tremendous debugging time gains. Especially for hard to reproduce issues.
Developpers would be able to allow more devs to work on a solution.
It would be a revolutionary tool