For many organizations the consideration of moving their documents and files into enterprise cloud storage such as SharePoint and Dropbox is a priority. This priority has been driven not only for companies wishing to stay agile and flexible, but primarily due to the remote work phase that has taken place since COVID-19. Having a legacy file server sitting in a data centre or a cabinet in an office has been seen to be unproductive and costly for organizations looking to enable their remote workforce. From a productivity view, the inability to easily collaborate with a file server hinders teams as VPNs and other barriers negatively impacts a user experience. From a technology perspective, a file server does not have the resilience nor redundancy and is a large capital and continuous support expense.
Migrating from a file server into the likes of SharePoint needs to be treated with correct project management practices, as well organizational communication, education and alignment is required to ensure a smooth transition. Before considering a migration into SharePoint Online, it is important to understand your current data, its structure and distribution. This exercise is key to understand how your data will look in SharePoint for comparison, but will also make sure that SharePoint is the correct platform for you. SharePoint has limitations with indexing and large data sets, but working through an exercise like this will help you mitigate these issues and assist with planning how you will structure your data in SharePoint or another platform.
Understanding your data can be a timely exercise if looking to do it manually, however there are tools available that can run a simple discovery scan across your file server and network attached storage. These tools will provide file and folder structure, sizes, amount of files, they will also provide insights on when the files were last modified and a breakdown on where your data resides within your current infrastructure.
When comparing migration tools it is paramount to understand the requirements for each solution, whether you need to host it on your own infrastructure, how does the licensing work and is there support included. The majority of migration tools on the market require you to pay per user or drive/site and often this can quickly become expensive, especially when your data exceeds your user licensing. Additionally, these tools require you to host their software on your own cloud infrastructure which introduces further costs with regards to compute, data transfer and engineering time. Finally, due to you hosting this infrastructure support can be challenging and providers can often point blame at your infrastructure in contrast to the software or performance. If you are considering migrating terabytes of data into SharePoint it would also be wise to consider a solution that can scale with your migration to ensure adequate performance in contrast to a single node solution.
One of the biggest limiting factors of the migration will be your on-premises infrastructure and network upload. Often the physical upload link or file server resources are the areas which impacts the migration the most, one thing to take into account is that a 100mbps uplink enables you to transmit 12.5MB/s and this does not take into account other network saturation, business as usual activities or protocol overhead such as the TCP bandwidth-delay product. To ensure your infrastructure can stomach a migration it would be wise to work closely with your migration partner and tool to test throughput prior to going through with the vendor and to plan for an accurate timeframe for the migration.
Aside from the indexing challenges that SharePoint has, there are other limitations and items that you should be aware of prior to migrating into SharePoint Online. SharePoint has the following limitations:
- Filename length — where the filename and its path cannot be over 400 characters long
- Filename characters — SharePoint has limitations around characters in file and folder names, some of these are “ * ? and leading or trailing spaces in names.
- Max file upload — The maximum file you can upload into SharePoint is 250GB
- Certain files are not allowed — For example, TMP, .ds_store, desktop.ini
The above does not take into account OneDrive sync with your Windows PC and the limitations with that. For further see here. When considering migration tools, it would be wise to identify what tools can automatically resolve the above issues, re-run failures or if unable to resolve at least provide adequate alerts, notifications and audit logs on your migration. An even better feature is part of the above mentioned discovery scan, it should provide you warnings on what files may not be migrated. This ensures that you have an opportunity to resolve these issues prior to transferring a single file.
When it comes to the migration itself, it should be done in phases or waves. First the discovery scan (mentioned above). After the scan a proof of concept should be tested where it involves everything that you wish to migrate across this includes users and sites and their associated folder structure, permissions, versions. This way you get a feel of what to expect and to ensure the migration is configured correctly and if not it enables you to amend and try again.
When it comes to the migration there is almost two phases, one is the mass migration where you migrate all the data, this can be done in sub-phases depending how many users or sites you have. With this migration users can continue to work as most migration software should be a ‘copy and paste’ rather than a ‘move’. It is better to run the mass migration as soon as you can to provide enough time to work through any platform limitations, rate limiting and to know that the majority of the data is there. Then once the data is on the destination you can begin the delta phase. This then keeps up the destination up to date with modified files, you’ll find that most delta’s are less than 2–4% of your data. Because of the small size these ‘update’ styled migrations are quick and the cadence should speed up closer to the go-live date. For example, 3 weeks out run a single delta one day during the week, 2 weeks out — run two deltas one mid week and another on the weekend then one week out it would pay to run two deltas during the week and a final one on the weekend when no one should be working.
Post-migration should revolve around user acceptance testing and everything being where it should be. You should aim to download any audits and logs you can locate, as well any files that did not make it across should be downloaded or attempted to be manually uploaded.
If you are looking to migrate from an on-premises file server or another storage system, be it cloud based or local then your migration tool should work with you rather than against you. Everything that has been mentioned in this article should be covered by the tool in some way or another. Movebot is a leader in the enterprise and business data migration space when it comes to the likes of SharePoint, Google Drive, Dropbox, etc.
Movebot is simple to use and is fully hosted and web based, ensuring you don’t need to install software or run your own infrastructure. Its pricing is competitive and often cheaper than its competitors, especially when you remove the self hosted compute and data transfer overheads you need to pay. As the solution is cloud hosted, it is fully scalable and caters for migrations in the 100s of GBs through to those in the 100s of TBs regardless how many sites or users you look to migrate.
For more information or to work with a Movebot human, contact us at sales@movebot.io and we can help you move your data — no matter the project complexity or size.
This blog is part of SharePoint Week. For more great content, click here
About the Author:
CEO of Movebot and Couchdrop and who has a passion for making cloud storage simple and accessible
Reference:
