In the past few years there has been a major uptake in organisations opting to migrate their content from on-premises locations, such as SharePoint or file shares, into cloud solutions like SharePoint Online.
Within this blog we will cover what is involved in planning and designing a file share to SharePoint Online content migration.
The first step in any organisation’s migration journey is to come up with a solution design approach that will work for their specific needs. At Professional Advantage, our approach to migrations is to start with a discovery phase which includes several workshops. These workshops will help identify what the drivers of change are within the organisation, their vision of a successful project, and highlight what opportunities for improvement exist within the teams.
The next step is to run a scan of the environment that needs to be migrated and identify some key information. This includes:
- Determining the number of files in the data source.
- Identifying what percentage of the content is media files, such as pictures or video, versus working files, like Office files or PDF’s.
- Identifying duplicate files.
- Determining the folder depth of files.
- Determining which files cannot be moved due to the file path length.
- Identifying how much content will be retained and migrated versus the number of files that need to be archived, for example only migrating the last two years’ worth of data.
An important part of the discussions with IT is to identify what the organisation’s plans are around archiving and what that might look like. Some organisations opt to store their old archived content in offsite blob storage, cloud storage solutions like Azure, or migrate the content to SharePoint Online.
Once a holistic view of the organisation’s content and archiving requirements is identified, workshops are scheduled with the different business area representatives to discuss their requirements. This will include their communication needs, collaboration requirements with team members, internal staff and external participants, and document lifecycle requirements. The outcome of the department workshops will give an indication as to whether Microsoft Teams should be included in the SharePoint design approach and whether there may be a need for custom development to meet their requirements.
In addition to the department workshops, a showcase of the collaboration and document management capabilities that SharePoint Online and Microsoft Teams offer will give the client a visual representation of where content will be moving and how content will be accessed. This will likely spark some ideas and highlight opportunities that might not have been considered previously.
Once the workshops have concluded it is time to start planning the solution design for the SharePoint Online migration. An information architecture plan for each business area affected by the migration must be devised in terms of the SharePoint library requirements, folders, and metadata. Additional workshops may be required to take the users through the use cases for using metadata and identifying whether it is useful to them and whether the team has the capacity, discipline, and technical know-how to maintain the metadata.
Another consideration for the different business areas is whether they will be cleaning up their content structures before the migration. The degree of clean up conducted and metadata requirements could increase the cost of the project so it is important to weigh up the business benefit to time effort for the migration. There are essentially three different migration approaches:
- Migrating the content as is, also referred to as a “lift and shift” migration.
With this approach all the content will be migrated in its current form in the exact folder structures they are now. This is a bit risky, though, as you are unlikely to get rid of those inherent issues on the file shares, like illogical folder structures, long file paths, unbearably deep folder levels, and difficulty navigating content. - Giving teams a window of time to reorganise their content into more acceptable structures before migrating those files as is into SharePoint.
This is by far the most popular option, as it allows teams to go through their existing information, delete what is irrelevant or add it to an archive folder, and then migrate only relevant content to SharePoint. - In addition to the latter, users may also be given time to identify metadata to be added to the destination SharePoint library, but not applied to the content automatically during migration. The end users will be responsible for applying the metadata themselves once the content is migrated to SharePoint.
- Flattening out folder structures and applying metadata automatically.
Teams take the time to review their folder structures and reduce as many folder levels as possible, often retaining 1, 2, or no subfolders in the libraries, and metadata is identified to classify content instead. Teams then need to map what metadata is applied to the individual files upfront. This is a very cumbersome process as an export of all file names and locations needs to be done and the teams are required to go through the list of file names and specify the metadata prior to migration. This also adds a lot of overhead for consultants who need to script the migrations accordingly and can therefore increase the cost of the migration project substantially.
Before migration can start the teams will need to fill out an information architecture sheet, which will allow them to specify the libraries, folders, and metadata that are required on the SharePoint sites, as well as permissions that need to be applied both on the sites as well as any special libraries or folders within it. They will also be required to complete a content mapping worksheet to detail what content should be migrated from the data sources into which destination location.
From a planning point of view you would also have to consider existing Microsoft Teams or SharePoint Online sites that could be used for the migration, and identify where new SharePoint or Microsoft Teams may need to be created.
Once the discovery and solution design phase has been completed, the implementation can start. But that is a blog for another day.
