For any application such as this, I would suggest that you not alter any of the existing data in the incoming XML file in any way.   Instead, perhaps add a second top-level element to the XML file which describes exactly what you did:   the identity of each element that was replaced, the old and new values (or at least the old ones, since the new ones are elsewhere), and a date/time stamp in the top-level element indicating exactly when this was done.   Then, if you wish, it moves the file ... taking care not to overwrite any existing copy that might already be there, but instead to add a new one beside it.   (If you plan things right, existing utilities like Unix logrotate can be pressed into service if you need to clean-up sufficiently old copies.)

If the program is run again, it has the option of looking for the existence of this new, sentinel element, to detect if it has already been run.   Or, it might add “yet another” top-level element to describe the outcome of this new run.   My point is that the entirety of this strategy is, by design, non-destructive.   None of the original data is lost, and the program records its own activities in a way that is also non-destructive to any previous records.