Its the most popular cloud collaboration platform worldwide and most businesses are heavy users of the Microsoft stack. Whether that be Office 365, the collaboration suite, or M365 the end-to-end stack including security tools, etc we’re all familiar. But talking to ex-colleagues, and other IT folk, people use it for Teams, Outlook and the office suite, but rely heavily still on other platforms for document storage and the general feeling is because of the complexity of migrating those documents. This article is to go over the various options to fully utelise the platform that your business is already paying for….
Like most businesses nowadays, there will be millions of documents, terabytes upon terabytes of files, in Sharepoint directories, in Google Drive, on-premise file shares, or just shared on Slack – they are everywhere. Migrating all those documents into a single platform has plenty of benefits, whether it be the ability to run a GDPR search, to classify your documents to make sure they aren’t shared to the wrong person, or whether its purely to improve collaboration within Teams or Outlook.
For many businesses, M365 seems like the right DMS (document management system) to use. Firstly, your company is already paying for it through their O365 subscription, you may already have some files within your Microsoft Teams channels – it makes sense. Don’t get me wrong though, its far from perfect, and far from the finished article.
One of the bigger challenges is understanding Microsoft’s complex licensing as to whether you are correctly licensed for what your end-game is (Tip: M365Maps is a great resource). For example, one friend of mine requires data loss prevention which is included in E3, but if you want Teams DLP, you need E5. Make sure you know up front what you want out the file storage, and functionality post migration. It may be that M365 isn’t the right fit for your business, and adopting a cloud-based tool like box.com suits better.
Anyway, assuming M365 is the right product for you, there are some gotchas along the way, and also a lot of planning up front.
Step 1: Migration Process
So lets look the best way of moving those documents:
Delete first, then move. Without doubt the best practise, getting rid of the documents that aren’t needed, whether that means utelising a company-wide retention policy, or getting users to delete or archive their files, this means far less documents to sort and then move. It means that the migration is likely to take longer and most likely rely on your end users, but will mean the end-game should be a more organised document store
Lift and shift. I suspect this is the most common method for a few reasons, its quick, requires the lowest end-user involvement. However, it means once all is said-and-done you end up with a rather cluttered document store, with lots of unneccessary documents, decreasing productivity
Lift, shift and tidy. This, I guess, is the halfway house. Get your documents up into M365, and then begin the cleanup. Although the end game could well be similar to option 1, the liklihood is that the cleanup never gets finished – so it ends up looking more like option 2.
So, you’ve decided which of the above options you’re going to choose (hopefully option 1), so the next stage is to identify where your files are, and could you potentially break anything? Common examples are things such as:
Access / Permissions to shared working areas
Linked files (such as excel workbooks, etc)
Output directories (from third party applications, etc)
Step 2: Document Mapping
You need to understand where the files are, and why they are there. So its worth speaking to staff to understand how they handle their files, and why. Look into those third party applications to see if and where they output files to.
Once you’ve got this far, its time to look at creating a map to describe where different documents should live, i.e. personal data goes into OneDrive, Team files live inside a Microsoft Teams channel, and application outputs live in a Sharepoint Online site, for example. Its worth noting at this point, you may decide that Microsoft’s M365 stack doesn’t fit a particular use case, because it requires a certain feature. Call this out quickly, as it has the potential to case risk to your project, your security and your collaboration strategy moving forward. At this stage your map should be pretty high level, something along these lines:
| Current File Store | Microsoft File Store | Notes | ||
| User Home Folders | One Drive | By default, its permissions allow only the user, so is the natural location for personal files. | ||
| Team File Shares | Teams | Encourages use of Teams as a platform for sharing and collaborating on typical file platforms, such as Excel or Word. Also, has a very simple interface and can still map drives to end-user-devices | ||
| File Share Permissions | Groups | Rather than using Active Directory security groups, M365 Groups are the natural progression and keep everything consistent | ||
| Application Outputs | Sharepoint Online | Sharepoint Online still supports share names, which in most scenarios satisfies outputs from third party apps. |
Step 3: Toolsets
Now you know your plan, and a high level mapping, you need a tool to support your move. The good news about this, is that there a plenty of tools, free or paid to help with this process, as there are a number of gotchas. I’ve put a few of the apps that I’ve come across during my research:
Microsoft Migration Manager Great for migrating network file shares
Microsoft Mover SaaS based app, aquired by Microsoft back in 2019 with support for file shares, box, dropbox, G-Suite and Sharepoint. Can also be used in conjunction with Microsoft’s Fastrack service if you want that helping hand.
SPMT The last Microsoft tool, this time focused around the migration of on-prem Sharepoint sites, libraries and lists
Aside from the Microsoft ones, there are some third parties, that do charge for their software, but hold their own for particular use cases:
BitTitan, CloudM, Sharegate, Avepoint and Quest are all excellent examples of this. They all have their pros and cons, for example CloudM are more focused around Cloud platforms, and Sharegate’s strength is mostly in Sharepoint, but they are pretty versatile.
Some of the considerations, aside from the type of data you’ve got to migrate, is things such as, what are the scheduling and reporting capabilities like? Does it create the structures within M365 such as a the Teams channels, or the Sharepoint sites? Does it handle exceptions such as invalid characters or character limit which could cause issues whilst uploading? Can it retain the original metadata from the files, such as created and modified dates?
Some of these considerations will have a huge impact to how much manual work is required, and if you’re a large enterprise with terabytes of data to move from a variety of platforms then any manual work will increase cost and time of completing the migration.
There are further gotcha’s during the migration itself, particularly around the importing and throttling of data into the Microsoft 365 platform. I’ve experienced this first hand a few years back whilst doing a Exchange Online migration. Here’s a few tips:
Scale-Out: Use multiple VMs in parallel each running a migration job, and avoid each of those jobs running a job to a single Sharepoint site
Direct Internet: Microsoft’s endpoints and routing is frequently changing, so avoid backhauling traffic through VPNs. The quicker your traffic gets onto Microsoft’s network, the better
Package size: Most migration tools do this already, but Sharepoint will only inject data packages up to 250MB at a time so make sure your tool supports this.
Total migration size: Microsoft ask that any business migrating over 100GB of data to contact them in advance via a service request to understand when and how much data you are planning to move.
Leave a Reply