versioning fails when copying

Silver Contributor

I apologize if this is answered elsewhere but I couldn't find it.  

So we have multiple libraries of which 1 is 'controlled' and has versioning turned on.  I am trying to use the versioning to maintain released file history.

When I have a file in the controlled library that I want to update I can download it, work on it and when ready to 'release' it I check it out from the library, upload the new version (overwrite the existing with the new version), and check it back in.  That seems to work and I can add in the comment field the new Rev #/letter and such.

But if I have the updated file in a different sharepoint library (a working library) and I copy it to the controlled library, it again prompts if I want to overwrite, but in that case I lose the prior history of the controlled file (it is completely wiped out and only the new copy exists).

I know that 'copying' a file only copies the most current version of that file, but I'm not sure why the 2 different methods of 'over-writing' a new version of a controlled file should act so differently.  I know that the 'proper' method is to check out and replace the contents of the file and check in, but that doesn't work so well with pdf files and such.

ALSO, but similar, when I upload to the controlled library the file new or changed file is checked out and must be checked in (which is good so I can add the Rev info and such), but when I copy from another library to the controlled library the new (or overwritten) file is NOT checked out and hence I do not have an opportunity to make a comment on the check in process.

Am I missing something, or is this how it is supposed to work?

14 Replies

Hi - @mtarler - I don't have an answer, just more details that my team figured out recently.


Like you said, if you drag and drop a file into a library, you'll be adding a version (if a file with the same name exists).


However, if you use the Move or Copy feature to move/copy a file from another SharePoint/OneDrive library, then it'll completely replace the existing file, including the version history.


If you use the Move or Copy feature when there is no existing file in the destination, the Move feature will bring the version history but the Copy feature won't.


Before we tested all of this, we assumed that copying a file would simply add a new version (like uploading a file) but that's not the case and it feels like a bug to us (poor user experience at best).

Hello @mtarler and @Deleted,


This is interesting behavior and not what I would have expected. I've reached out to others for confirmation of the behavior. I will follow up when I hear back


I hope this helps.



Turns out this behaviour is by design.


When you use Copy to with documents that have version history, only the latest version is copied. To copy earlier versions, you need to restore and copy each one. 


More information on the Copy files and folders between OneDrive and SharePoint sites site.


Thanks to Susan Hanley for pointing us to the official answer.


I hope this helps.



@Norman Youngthank you for looking into this.  I have some more information to add:

If you map a network drive to sharepoint I found everything appears to work correctly from there. Specifically:

a) copying a file from another library to the controlled library (both using file explorer windows) will say 'no' if it isn't checked out or create a new version if it is checked out and you 'over write'.

b) copying from another library using file explorer and dragging to edge window with controlled library will also create a new version when you over write a checked out file

also interestingly:

a) in the mapped drive in file explorer you can rename a file in a controlled library without checking it out

b) you can right click (or ctrl click) to copy a file you are dragging (in edge it will only move the file using the click and drag)

c) a down side to using the mapped drive in file explorer appears to be the inability to check out/ check in documents (although you are prompted when you open documents and such)

@Norman Youngsorry I didn't see your reply while I posting my updated info.  

But your answer does NOT help.  I know that behavior and even mentioned it in my original post.  The behavior I have complaint with is that if you copy or move a file to over write a file in a protected library it doesn't save the previous version.  If I upload from my computer (which is basically what I guess is also happening using the mapped drive technique I mentioned just a few mins ago) it overwrites the file but adds it as a new version (i.e. maintains the old file a prior version).  Even, as I just noted in my update, if I copy or move a file between 2 windows using the mapped drive in file explorer it over writes the file as a new version.  BUT if you use the copy or move feature in the online sharepoint to over write a file with a new version it completely wipes out the prior version.  That seems to defeat the whole controlled library point.

Let me give an example because I think it might be confusing:

I have Doc123 and it is an a controlled library with versions 1.0, 2.0, 3.0, 4.0 and the current version is 5.0

IF I copy that Doc123 somewhere else I understand that it will ONLY copy version 5.0 and lose all the prior history.

IF I check out Doc123 and upload a local updated version of the document to over write it, it will then become version 6.0 and I can then check it back in.

IF my new updated version of the document is in a shared working directory in a different sharepoint library, then if I copy that file (using the online copy to feature) when it overwrites Doc123 in the controlled library it wipes out all previous versions there also (i.e. not only does it not keep prior versions from the source file you are copying from but it also wipes out all prior versions of the file you are copying it TO).

Let me explain why this is such a PROBLEM:

The 'how it is intended to work' is fine since if you MOVE a file you keep all version history and if you COPY a file you only keep the most recent version BUT the original still has the full version history.  So that is all fine.  But if I have a pdf file (let's say a pdf drawing from SolidWorks) in a protected controlled library that must keep all past versions  and I need to update it I have to overwrite it using a new pdf created from SolidWorks.  That works if I upload it from my desktop but gets destroyed if I copy it from a shared/working library.  Fine, I know to download the file then upload it to prevent loss, but what if a new employee comes in and doesn't know.  How do I protect my version history.

Hi @mtarler,


The issue was not clear to me at first.  Now that I follow, what are the specific settings do you have on in the "controlled library"?





@Norman Young  thank you.  In the controlled library the versioning settings are:

content approval - NO

Doc Vers History - Major Versions Only

Draft Items - any user (but not applicable since we have major versions only)

Require Check Out - YES


on a  side note.  If you consider the "copy to" function will not save prior versions on the source or destination, that doesn't explain the "move to" which is suppose to save prior versions.  That said I have no idea how a "move to" versioning would work with overwritting another file that also has versioning.  Hence I would expect that in a controlled versioning library the 'move to' function should not be allowed to overwrite another file, but the "copy to" could be used to copy the most recent version of the source and make it the destination's new version and keep the destination version history.



best response confirmed by mtarler (Silver Contributor)

Hi @mtarler,


I thought a custom permission level would work but it did not. I could not find a site, document library or versioning setting that would help either.


This is not ideal, but you can create a trigger to notify you when a file is deleted using Power Automate. This will provide an opportunity to intervene and restore the file (and version history) from the site recycle bin. 


I hope this helps.



@Norman Young  like you said, it is not ideal, but at least that will detect the problem and it can be addressed as opposed to being hidden and not discovered until it is too late (depending on the trash policy)

I think part of the problem is that the warnings are so similar or identical.  If you are trained/used to getting the "warning this will overwrite..." dialog when you drag and drop, you wont think twice about that same warning when you copy/move, but now you lost your version history.

Just to add to this ridiculous behavior, if you use Teams and add a cloud storage to be able to copy/move files from your team site to another SharePoint site, you will see that copying from your teams site to the cloud storage will add as a new version if the file already exist!!! Inconsistency seems to be a functional rule at Microsoft... Note that this will all go away in Teams when the new copy / move dialog will be deployed as it does not display your cloud storage as a destination... Very tired of all this mess.


Totally agree. We want to implement a document management system with version history and this behaviour completely threatens to undermine all of the security we have built into our controlled libraries. We should not have to depend on staff understanding that 'replace' means different things depending on if you are uploading or copying - especially as this does not appear to be documented - and we found it out by accident during testing. Another serious problem we ahve found is that copying a document with the same name from another site completely overrides a document in a check out to edit library even when it is not checked out - whole history gone!

How do we get Microsoft to address this now that uservoice has gone?

We also have this issue and it is of concern because it is used for audit and it does not replicate on premises copy using the file explorer (how users used to work). Copy To does not leave the previous history in the Copy To destination and also set the version being copied to be the Latest version. It deleted the entire file and replaces with a single version copy, which is not how it should work. In my opinion this is a straight forward bug, not inconsistent functionality and should be fixed.

1 best response

Accepted Solutions
best response confirmed by mtarler (Silver Contributor)

Hi @mtarler,


I thought a custom permission level would work but it did not. I could not find a site, document library or versioning setting that would help either.


This is not ideal, but you can create a trigger to notify you when a file is deleted using Power Automate. This will provide an opportunity to intervene and restore the file (and version history) from the site recycle bin. 


I hope this helps.



View solution in original post