The following are observations from using the ‘Move To’ function in a SharePoint Online library to move close to 18,500 files and folders over a weekend, from a ‘classic’ SharePoint subsite in a SharePoint Online site to a new and ‘free standing’ site in the same tenant. The moving was completed over a weekend to minimise disruption to end-users.
This post extends on my previous post ‘What happens when files are moved in SharePoint‘ by explaining the process in more detail.
The main reasons for the move were: to move the files out of sub-site of a classic site with all the legacy classic site features, to a new ‘standalone’ site; to address access control issues caused by the site collection/sub-site permissions inheritance complexity; and provide a modern way for end-users to work with SharePoint.
As a general comment, the ‘Move To’ was found suitable for moving 1000s of files, but there were a couple of things to be aware of. These included: legacy content types and metadata; checked out or declared records; and the time it would take to migrate the files. There are of course ‘better’ migration tools out there, but ‘Move To’ is fine for most routine and relatively small migration projects – taking into account the comments below.
Pre-migration preparation
The primary pre-migration preparation was to document the list of libraries that contained content that needed to be moved. The volume of content, as shown via Site Contents, was also recorded as there needed to a reconciliation between the two numbers at the end.
The next step was to document what (a) content types and (b) metadata columns were available on the source site/library. Although some content types had been created at the site level (not in the old content type hub or the new content services area in SharePoint admin), it was decided that not all of these would need to be re-created in the destination library. Instead, only site columns would be required. In two cases, the site columns assigned a content type no longer existed (which seemed odd).
Site and library permissions were also checked. In this case, the source libraries had a mix of permissions reflecting the fact that they were located in the sub-site of a classic site collection, whereas the new ‘free standing’ destination site had permissions that were inherited by the library by default. All moved documents would inherit the new permissions and any existing sharing would be lost. This meant that some people would lose access to the files, but this was intentional to ‘clean up’ the complexity.
Although it didn’t come up in the pre-migration activity, the Move To process highlighted a couple of other issues that could prevent files being moved: files declared as a record; and files that were checked out.
Some pre-moving suggestions:
- Declared records: Check to see if the source library includes the ability to declare records and decide what should be done about these records. In this case it was decided to undeclare these on a case by case basis, since fewer than 20 appeared out of 18,500 files. They were not to be re-declared as records in the destination site because it was assessed this option was no longer required.
- Checked out files: Use the Library Settings option ‘Manage files which have no checked in version’ to see if there are any items that are checked out and check them in. Alternatively, check them in on a case-by-case basis during the moving process; they remain in the source location and then be processed individually. For this moving exercise, fewer than 20 appeared.
From a destination site point of view, ensure that each destination library has the same metadata columns and, where necessary, the same content types as the source library. If content types are going to be used, ensure that the destination library settings: allow the management of content types; and all content types have been added. Make sure the destination metadata columns are the same as the source (e.g., Single Line of Text, Choice, Date and Time).
One final tip. Consider testing the ‘Move To’ process first with some other files to learn how it works. And keep in mind, as discussed in the previous post, that all moved files are placed in the source site Recycle Bin for 93 days, so can be restored if things go wrong.
Ready to Move
For the purpose of this process, both the source and destination sites were open, mostly to monitor the volumes in the new site via the Site Contents page.
Items to be moved were selected in the source library. In most cases, these were folders but also some documents at the same level. Given the potential for things to go wrong or issues with declared or checked out files, it was decided to move a small number of folders or files at first, then increase that to 10 to 20 at a time. Choose ‘Move To’ from the library menu bar.
The next step in the process can be slightly confusing at first. The dialogue box shows the name of the source site (in this case ‘Administration’) and the names of the source libraries with a folder icon (even though they are libraries).
At the bottom right of this dialogue box is a ‘Move Here’ option that is not greyed out. You can ignore this but be mindful that the option appears, as it could be confusing if the destination library has the same name.
The ‘Quick access’ menu on the left displays a list of sites in the tenant. Select the destination site and then you will see the primary ‘Documents’ library at the top of the dialogue box, with a drop down option. Unless you are going to move the documents to this library, select the correct library from the drop down arrow.
NOW select ‘Move here’. If there is ANY mismatch with metadata, the following message will be displayed, giving the option to ignore it and ‘Move all anyway’. In this particular case, the decision was made that any metadata mismatch would be minor – older metadata columns that had no content were not created in the destination library.
During the migration
Almost all (98%) of the moving proceeded without any issue. As the folders were moved in batches of 10 to 20 depending on their size, checks were made from time to time to see if there were any issues such as declared or checked out documents, causing the source folder to remain even though the destination folder had been created. These were undeclared or checked in and then moved to the correct location. This left the original folder name which also had to be deleted.
The File Contents section was also checked from time to time to see the volume of content that had been moved compared with the original library. The final numbers should be the same.
How long did it take?
All of the 18,500 or so files, in two approximately similar batches (different libraries), were moved over two days taking 12 hours and 10 hours. Around 750 item (files/folders) were moved each hour on the first day, about 850 per hour on the second day.
One of the factors that slowed things down a little was not so much file size but the number of versions (and also the need to go back and fix up declared or checked out files). One file alone had well over 1000 versions. Each of these versions had to be moved, and this slowed the moving process. Folders with individual items that had no more than 5 versions moved very quickly. This might explain why moving almost the same number the following day was much faster, as there were fewer versions.
Post-moving checks and actions
As noted already, most of the checks occurred during the moving process – undeclaring and checking-in files and then moving them, and checking to ensure the file numbers were the same in the source and destination. These activities took no more than one hour over the elapsed period.
To help the business with the move, the navigation element on the left hand side of the original site was changed to add the word ‘OLD’, while a new navigation element with a similar name and ‘NEW’ was added. A link to the new library was added in the original source library, in case anyone had bookmarked it and ended up there. (Note that permission changes meant that some end-users would no longer have access to the content in the new library, but this was part of the plan).
After the moving process was completed, the business area was also asked to check that everything seemed in order.
Final comments
Overall, the moving process was straightforward but pre-moving checks and planning (volumes, permissions, what goes where, content types, metadata) are essential.
Records about the world 
I love all what you have shared