If you’re like most organizations, you still have files residing on-premises. They could be in a NAS, or a DFS replicated Windows Server. Your users might know this collection of files as the “S Drive” or something similar. It’s time to modernize your file experience and move files into the cloud where you get versioning and redundancy built in.
Did you know Microsoft has a free utility called Migration Manager (https://aka.ms/migrate-createsite) that can help you through this process? While this article is focused on file shares, the migration manager tool can also copy files from 3rd-party services like Box, Google, Dropbox, and Egnyte.
Getting Started
- Download agent. – You’ll need to download and install an agent onto a Windows computer.
- This should be a domain joined machine. (this way permissions can be matched to Azure AD)
- It does NOT need to be the actual server where the files live. This could be a Windows 10 PC sitting on your desk but able to access the file server via a UNC path.
- If moving a ton of files, consider installing multiple agents as migration manager can share the load among more than one agent.
- By default the agent will create a logging and temp files directory in AppData, which likely resides on your C drive. If you don’t have adequate space on C, I recommend moving this to a different drive. This can be done from the agent settings within the Migration Manager web interface.
- Add a source path – Before we start migrating data, we want to scan the content to find any potential issues ahead of the migration.
- Enter the UNC path to your file share. Local paths are not supported.
- Leave the default option of “Add all subfolders as source paths” checked as this will help you determine which of your top levels folders have issues as the scan progresses. For example, if my file share is \\myfileserver\shared and within that I have folders like Content, HR, Marketing, Staff, etc… then I will get a line item (distinct source path) for each of those folders that tells me how large they are, how many items, and the issues that are found. This is not recursive so only the top-level folders get created as source paths. Of course, all the files/folders in each source path is scanned.
- Leave the default option of “Automatically scan content” checked. This will immediately queue each of your subfolders to be scanned and reported. This does not start the migration as we haven’t yet set a destination.
- Now we wait. Depending on how much data you’re scanning, this could take well over an hour to complete. You’ll see a screen similar to the one below. Scan results will appear as Ready to migrate or Migration warnings found. For any paths where migration warnings are found you can download the scan log to see exactly what files were flagged. Once you remediate those, trigger another scan content task on the source path.
Remediation Tips
Tip # 1 – INVALID_SHAREPOINT_NAME
Once you pull down the scan log, it may be a very large Excel file. My tip would be to filter the ResultCode column to show non-blanks. Then you can sort the SourcePath column to get a list that would be easy to go through your file system and cleanup. In the example below, you’ll see all the files have a result code of “INVALID_SHAREPOINT_NAME” and if we look at the actual files they are all temp files that start ~$. In this case I was able to go through the file system and simply delete those files. After re-running the scan content task it now comes back as Ready to migrate!
Tip #2 – ITEM_IS_EMPTY
Another result code you’ll get is “ITEM_IS_EMPTY”. This means it’s a 0 byte file. If you only have a handful of these you simply find them in explorer and delete. However, if you have dozens or hundreds of these files and they are spread out in various folders, PowerShell will come to the rescue! Use the code below to find all of the files. Once you’ve verified the correct files were returned, go ahead and delete.
# Run this first to store all the files into a variable
$files = Get-ChildItem -Path 'S:\myfiles\shared' -Recurse -Force | ? {$_.Length -eq 0}
# Run this next to output the names of all the files and verify
$files | select FullName
# Run this to get a count, compare to the number of filtered rows in your Excel file
$files | measure
# Lastly, once you've verified you have the correct files, run this to delete them
$files | Remove-Item -ForceStarting the migration
Once you’ve completed any and all necessary remediation on your files, it is time to start the migration. Follow along to see the steps I recommend:
- Run the initial migration.
- Chances are your source data may be quite large and won’t complete upload within your cutover window. In this case, run an initial (or 1st pass) migration to get everything uploaded but hold off on giving your users access to the migrated data as you don’t want to end up with multiple active copies of a file.
- If you ran a scan as demonstrated above, you can simply select that scan and choose “Copy to migrations” to get started.
- The copy to migrations wizard will walk you through a few steps. First select your destination. Choices are OneDrive, SharePoint, and Teams. In this example, we’ll choose SharePoint and click next.
- Enter in the URL of the SharePoint site. For example if your site was called LanguageArts and you want to copy the files to a folder called Assignments within a document library called Class Files you would specify the site url as https://acme-edu.sharepoint.com/sites/LanguageArts and then browse to the Class Files library and the Assignments folder within. See screenshot below for details.
- Provide a task name and optionally set other config like run now vs run later, or whether you want to migrate files created after a specific date.
- Once this task completes you’re done until you’re ready to cutover.
- When you are ready to cutover, follow these steps
- Disable writes to the source data.
- You don’t want to end up with users writing files in both locations so be sure to disable writes on-prem. This could be done by deleting the share and point your migration task at the administrative share (ex. delete \\fileserver\share and instead point your migration task at \\fileserver\e$\share) or if you’re only migrating a small subset of an existing share, set the NTFS permissions so the users only have read access.
- Find your existing migration task and run it again. This second time should run faster as it will only be copying changes since the last run. (if you have a longer gap in-between the initial copy and the cutover, feel free to run additional copy jobs so that the final copy during the cutover window runs faster)
- That’s it! Your on-prem files are now accessible inside of a SharePoint site. Take a look at a post that MicrosoftBlogs.com author @dlloyd made last month regarding how to have a “Mapped Drive” experience with SharePoint Online using the Microsoft OneDrive Client.
Hopefully this article was informative and helpful. Please comment below with any questions or perhaps provide tips and tricks that you may have come across in your environment that could help fellow IT Pros!
