10 Tips for Navigating Shared Network Drive Migrations to SharePoint

Reading Time: 8 minutes

Blog post: 3 minute read.

LucilleBallChocolateFactory Cropped

Whether an organization has been using SharePoint for a while or just starting down that road, many will still have large shared network drives holding some content that should rightfully belong in SharePoint. Migrating this content is a challenging and messy task; one that many of us are being asked to do. I am neck-deep in one of these migrations right now and have discovered there are expectations this process should be straightforward and therefore quick. In my experience, this is usually not the case.

For those unfamiliar with the notorious Lucille Ball skit pictured above, here is a link. I don’t mean to suggest wrapping chocolates is like SharePoint migrations, however the conveyer belt analogy partly holds true. The migration process is not a cookie-cutter, conveyer belt one even if people perceive it to be that way. Each migration is unique and requires up-front planning, preparation and therefore time to do it right. If you don’t do this, you run the risk of ending up with a SharePoint mess.

In this post I’ll share my 10 tips for getting thru these messy migrations in a more controlled manner – one that will allow your organization to realize the benefits of having this content stored in SharePoint as opposed to a network drive.

Applies to: SharePoint On-premises, SharePoint Online.

TLDR? I get it, here’s the list…

  1. Get buy-in from your Leadership team.
  2. Don’t just “lift and shift”.
  3. Get a lay of the land.
  4. Clean-up what’s there.
  5. Not everything belongs in SharePoint.
  6. Work with the team to build their new home.
  7. Put your Information Management/Architecture hat on.
  8. Know your migration options.
  9. Break old habits.
  10. Demonstrate ROI.

Tip #1

Get buy-in from your Leadership Team.

Let’s face it; this is not an exciting project to be on. The Leadership team in your organization has likely identified the need to move content off shared network drives since they were promised the goodness of SharePoint to store content and are wondering why we still have them. Key points to consider:

  • You will need to work with people throughout the organization, the “owners” of the content, to clean up what’s there and identify what should be moved to SharePoint. Unless the organization’s leadership has identified this as a priority to them, you will likely not get the attention/dedication you require.
  • You need to demonstrate to your organization’s leadership how messy, complicated, and slow this process can be. Perhaps give them a presentation (feel free to take some of these tips if you want) on the value-add SharePoint brings to the table, and why it needs to be more than just a “lift and shift” approach. This should demonstrate to them why the process will take some time.
  • There will always be a need for some content to remain on shared network drives so they will likely never completely go away. Make sure your leadership understands this.


Tip #2

Don’t just “lift and shift”.

If you have a mess on your shared network drive, migrating it into SharePoint “as-is” will just move the mess. I can’t stress enough how important it is NOT to do this. The only thing accomplished with this approach is content is no longer taking up space on your network drives. There are tangible benefits of moving content to SharePoint, but it does require some up-front planning and work to realize some of them. I will demonstrate some of these in subsequent tips.

The takeaway? This is not a “conveyer belt” type of project.

Tip #3

Get a lay of the land.

You will benefit from having a tool to analyze the content you’re about to migrate into SharePoint. Tools can detect things like duplicate files, size of files, folder structure, etc. The intent of this tool is to identify what kinds of files exist, what can be deleted, automatically delete duplicate files, etc. and the output can be provided to the content owner to assist them in their cleanup (Tip #4). An example of a tool that will provide this type of information is Treesize although there are likely others on the market. This will also give the migration team an idea of the number of files about to be migrated into SharePoint which is an important thing to know both in terms of the # of items as well as the overall storage.

There is a 5000 View List Threshold in SharePoint and you need to ensure you are remaining within it. (Refer to my blogpost SharePoint Online List View Threshold for more information)

Tip #4

Cleanup what’s there.

This ties back to Tip #2. Don’t just move the mess. Clean-up can potentially take a lot of time by the owner of the content. This is why executive support (Tip #1) is so important. There are different strategies you could suggest for doing the clean-up, but generally you will end up with 4 buckets:

  • content that needs to be migrated for active use
  • content that needs to be migrated for archive only
  • content that can be deleted
  • content that needs to be retained, but not in SharePoint

Note: this is where you will soon identify the hoarders in your organization. You will likely have to spend more time with these users to help break them of their habit by leveraging SharePoint capabilities. (more on that in Tip #9)

To encourage clean-up I’ve seen organizations create contests that award teams/individuals who clean up the highest percentage of their content prior to migration. Sometimes this is just the motivation required to get team’s to clean up their old legacy content.

Tip #5

Not everything belongs in SharePoint.

Just because you can doesn’t mean you should. This saying definitely applies here. You will find all kinds of things other than Office files and PDFs on shared network drives… executables, installation packages, report backups, etc. and most of them can be migrated into a SharePoint document library just fine. However, there are other, more suitable, repositories for some of that content, like a source code repository for example. Make sure you work with teams that have this type of content and find alternative storage repositories for them. Some of this content may also remain on a shared network drive and this is completely fine.

Tip #6

Work with the team to build their new home.

Each team will be different which is why this is not a “conveyer belt” process. First, you need to decide what you will migrate the content into. Does the team already have an existing SharePoint site or will you be provisioning a new site for them? Will you provision an O365 Group for their content? Second, take the opportunity to look for ways to leverage some of the SharePoint capabilities in their new environment. This step can take a lot of time, but is also where the value-add of SharePoint can be seen. Some ideas:

  • Build an approval workflow around a certain set of documents they are attaching and emailing around now.
  • Turn on versioning in a library and train users how to use that instead of storing individual copies of documents like they may have done on a network drive.
  • Create a SharePoint list for things they are currently tracking thru other means. Set up alerts or Microsoft Flows on this list to kick off other business processes that may be manual today.
  • Add some metadata on files so they can find them easier once they get into SharePoint. This may replace some of the nested folder structure that exists on the shared network drive.
  • Look for ways to leverage SharePoint search to allow end-users to find the content that was once buried in network folders.

The possibilities are endless and is really a factor of how much time you can dedicate to each team and the in-house capabilities you have for designing and building SharePoint solutions.

This is one of the key differentiators between storing files on a Network drive versus storing them in SharePoint.

Tip #7

Put your Information Management/Architecture hat on.

This tip goes hand-in-hand with tip #6 when you are working with teams while designing their new home. At a very high-level, you need to be thinking about these things:

  • How many sites/document libraries will this content migrate into?
  • Will you define any content types for this content?
  • Will you default the metadata on this content during migration?
  • Will you want to restructure their content during migration?
  • What retention settings will we apply?
  • Will you turn versioning on for these libraries?

Tip #8

Know your migration options.

You have several migration options and the one you pick will depend on several factors, some of which are:

  • Do you care if you retain the last modified by and last modified date metadata properties from the shared network drive?  If you do, then you will want to use a migration tool to assist. (If you plan on applying retention, your Information Management team will want to retain this metadata on migration)
  • What is the volume of content you are migrating? If it is a small amount and you don’t care about the metadata then you could do it manually.
  • Who will be doing the migration? Will their be a central project team doing this or will you rely on the content owner to do the migration?

There are several migration tools on the market to help and I would recommend trying them out particularly if you have a large migration effort in front of you.

Tip #9

Break old habits.

This is a big one. My observations have been if left untrained, end-users will immediately want to open up their SharePoint document library in File Explorer and operate exactly the same way they did in the Shared Network drive world. There are a few problems with this:

  • you cannot update metadata in File Explorer
  • you cannot leverage any of the SharePoint capabilities if you operate solely within File Explorer (show version history, custom views, filters, apply retention labels, etc.)
  • folders aren’t the only way of organizing content which is really all you have in File Explorer. A planned use of metadata can go a long way in assisting users to find their content. Unfortunately, in File Explorer, metadata cannot be seen.

Information hoarders deserve special mention as they will likely be the most challenging group to work with. You will need to train them on SharePoint features they can use to reduce the number of files they feel the need to keep. (Versioning) Also, you may want to educate them on the risk of keeping content longer than they should and leverage the mechanisms within SharePoint and O365 to automate the retention and destruction of them. Ask for help from your Information Management teams on this one.

Another concept you need to ensure your end-users understand is SharePoint syncing. Most users are used to syncing their entire OneDrive library to their local drive. In SharePoint, this can be problematic due to large library sizes. Encourage end-users to only use syncing as an offline tool and to sync folders rather than the entire library.

NOTE: The Windows 10 Creators Update will offer OneDrive placeholders to make files appear as though they’re downloaded locally, but in fact they aren’t. Only when you click on the file link will it download. This will also hold true for files stored in SharePoint making syncing a better option than it is today when this update rolls out.

Tip #10

Demonstrate ROI

You will want to demonstrate both the progress and the value-add of the migration project to your leadership team. Some good ways of doing this are to track the storage reduced on the network drives, the number of teams moved to SharePoint, the number of solutions built using SharePoint/O365 capabilities, the amount of content now covered by retention, etc. This should target the specific metrics your organization has identified as key to its success.

You could track this information in a SharePoint list and build a Power BI dashboard to share with the Executive team. They eat this stuff up. 😉


I think we can all agree a network drive migration is not a sexy project to be on, but it is a very important one. Unless we tackle the mountain of content living in the Shared Network drive space, I believe we are only partly realizing the business value of our SharePoint/O365 investment. However, don’t be fooled into thinking you can push thru the migrations like wrapping chocolates on a conveyer belt.

Thanks for reading.



  1. Excellent tips Joanne! A few questions for you…

    1. Regarding your content buckets “active use” and “archive only”, what does “archive” look like in Microsoft 365? Is there a cheaper storage tier we can use?

    2. Another “archive” question… we tell our staff “when you are done with your project in Teams, let’s archive it.” Not sure what archive looks like, apart from migrating the project docs to a standalone SP site called “Project Archive” and deleting the collaborative Team. Any other options available to us?

    1. Hi Aaron! This is a longer answer than I have time for now. Might blog about it. Short answer: no built-in archive option in M365 for “cheaper storage”. You can offload business records for long term archival to cheaper storage locations: Azure Data Storage, Amazon S3, etc. but it’s on you to do that. There are options at the end of a disposition review in M365 to help with that (Power Automate flow, relabel)
      I’ll answer the Teams archive question in another post likely. 🙂

      1. When we started our Teams journey over a year ago, our guidance was “only keep your teams running as long as you need.” It begged the question “where do we put this stuff afterwards?”

        Today we employ ShareGate Apricot to remind us to delete, renew, or archive dormant Teams. In this case, “archive” means the Team and it’s associated data are saved to cold storage and deleted from M365. Accessing this archive means reconstituting the archive back into M365 if there’s documents someone desperately needs. Not sure what the retention schedule is for Apricot backups.

        Given we are all thinking about governance, compliance, and retention, perhaps the dirty secret we’re not telling our co-workers is “there is no archive, use it or lose it!” In that case, the answer may be 1) move the important documents somewhere they will be actively used in business processes, 2) let the Team expire and be deleted after a period of time (eg delete 90 days since last accessed).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.