Migrating Physical File Servers to SharePoint
Introduction
With the increase in remote/hybrid working it is become increasingly more important to centralise key data in way that is accessible to teams working anywhere, the on-premise file server are becoming redundant being replaced by modern cloud-based storage such as SharePoint Document libraries or Azure Storage to name a few there are many non-Microsoft based cloud storage options.
Many organisations already use productivity tools such as Microsoft Teams we see a lot of scenarios where some key data is stored within the Teams SharePoint sites and some stored in physical file servers, which often leads to data duplication and difficulties finding the most recent version of a document.
Storing information in Teams SharePoint sites is great until you need to secure individual folders and begin creating private channels to do this (which is one method) but not necessarily the neatest way to separate and secure information.
Planning the Cloud Migration
It is imperative when undertaking a data migration that adequate time is dedicated to the planning of the operation, some of the key things to establish early on is how many file servers, how have permissions been assigned (group membership or direct assignment), if those permissions are correct, the structure of the file system are the folders named appropriately do any folders require merging, renaming, or removing during migration.
The answers to these questions will aid in the set up of the new folder structure and the assigning of custom security permissions via security groups, it is worthwhile spending extra time reviewing the folder structure checking for any blocked inheritance or running a PowerShell script against the file server to pull out all security permissions into a CSV file to review more closely.
Establish how the data will be organised within SharePoint methods include:
Option 1
SharePoint site for each top level departmental on-premise folder (Sales, Accounts, Operations, Marketing and so on), structuring this way has benefits in that you can use the built in read/view SharePoint group for read access to all data, the Edit SharePoint group for editing of those documents, this is the preferred method as it allows the teams to then take full ownership of the SharePoint site and can be used as a full knowledge sharing resource, informational site as well as being linked to Teams, Planner, Lists and other popular Microsoft services resulting in greater collaboration opportunities for the team.
Option 2
A Document Library for each top-level folder all contained within the same SharePoint site, this will help in terms of setting permissions on the top level of each of the document libraries, permission groups will need to be created to mimic the file server permissions and assigning to each of the top-level document libraries.
Option 3
One SharePoint site and one Document Repository for all data, this method is only for migrations with less than 1TB of data, and is best used when the data is not structured or organised appropriately move it to here with a view to segregate further in the future, this is not the best method but is useful for a quick migration to cloud, it is advised to do further migrations to split up the data at a later time once a hierarchical structure is in place (just like option 1 above).
Communicate changes early on to the teams to ensure they are aware that the change is taking place, and what to expect from the new file system, popular benefit of moving all documents to a SharePoint repository is document co-authoring – users having the ability to simultaneously update documents and see their colleagues updating the documents in real-time.
Important note: if a folder is open for everyone read or read/write on a file server some users may never realise they have access to that data, when the data is moved to SharePoint recently changed files show in the users SharePoint explorer or Microsoft office home screen, this is something to be mindful of as some may think they have extra permissions when in fact they could always access that data its just not been as visible to them. On that point we would recommend reviewing with a local folder owner if such folders should be open to all or if when moved those permissions need restricting.
Another note on planning the migration, if the users would like to access the files based on the channels within Microsoft teams as well as SharePoint, before migrating any data ensure the Teams and Channels have been created and named correctly, then map the data for those folders separately to each of those channels as different jobs don’t migrate all to the root of the SharePoint site as this will cause problems.
Analysing the current permissions & folder structure
Permissions set on the file server for user access to those files and folders will need replicating on the new folder structure, we advise checking through all the on-premise folders create a spreadsheet of all permissions to which folder names and any associated Active Directory groups, next get a list of users for each of the assigned groups and then re-create these groups as security groups within Azure Active Directory.
For larger migrations it is more useful to pull all the permissions via PowerShell, especially for those organisations who have inheritance blocked 1 or 2 folders down from the root which are more difficult to spot, and if missed result in users having access to data they shouldn’t have.
It may also be useful for larger migrations to use Azure Active directory connect to hybrid join your on-premise Active Directory to Azure AD this can then be used to sync groups which can save time during a migration, but if it is a small data or not too many groups to set or small organisation then we would advise manually creating the groups and assigning the permissions this way to get a clean break from on premise Active Directory.
Download the Azure Active Directory connector here https://www.microsoft.com/en-us/download/details.aspx?id=47594
At this stage it is useful to create a spreadsheet of all the folders to be migrated where they are now and where they are going too, what permissions are currently assigned and what permissions will be assigned once moved and any other notes about the folders, we would recommend that once this document is complete share it with the file server owners and ensure they agree to the new structure and the permissions assigned to ensure key stake holders understand what is going where.
We use these headers for our mapping document:
Source Locations | Destination Location Permissions | Group Association/SP Permissions | Notes
Replicating Custom Permissions
Create the Groups within Azure Active Directory, add the members to these security groups, next go to the SharePoint Document libraries and disable inheritance, remove the two groups one for edit/modify and the other for view and add in the newly created security group/s and assign the relevant permissions.
Migrating the Data
- Setup the SharePoint/Teams sites
- Setup Document Repositories
- Assign permissions as mapped out during the analysis phase
- Install the SharePoint Migration Tool on the File Servers, if they are not all on the same network the SPMT would need installing on each, if they are all connected then you can just install it on one of the file servers best to install it on the highest spec server with the quickest internet connection
- Use the SharePoint Migration Tool to map the data
- When ready begin the migration process, it may be wise to run this over the weekend due to better connectivity and less disruption to end users.
Resources
SharePoint Migration Tool
Mover for Cloud to Cloud Migrations
More About SharePoint Online
SharePoint Web Parts Explained
Need SharePoint Help?
Would you like training on SharePoint for your teams? or do you need help setting up your SharePoint knowledge resource and guidance on how to best use the built in tools, schedule a consultation today