Speed Freak! How to Speed Up SharePoint Migrations
“How do we get the best speed from a SharePoint migration?”
It is one of the most common questions the Metalogix team is asked. I know a lot of people are looking for that magical GB/hour figure but there isn’t really a one-size-fits-all answer to this question. Let’s face it – we shouldn’t really expect that since SharePoint deployments are rarely, if ever, the same.
Instead, we should look at the various factors – namely data and technical – that can impact SharePoint migration performance and select the size that best fits our particular situation.
From a data perspective, the migration speed can be impacted by a number of things. The amount of data to be migrated is perhaps the most obvious thing to consider. However, I am willing to wager that if you were to take two SharePoint farms with 500GB of content, even with hardware specifications, network connections etc. all equal; the migration time for each farm is very likely to be different.
Why would that be? Simple, it’s not just the amount of data that impacts speed of migration but the composition of the data that plays a part. It is one of the main factors that affect SharePoint migration performance. If our 500GB was comprised of mainly large documents, then the GB/Hour figure would be much higher than lots of smaller documents. Having your documents in a single document library rather than multiple document libraries would also result in faster migration speeds. Same would go for a single site compared to multiple sites.
So what can you do to optimize? It would be ridiculous for me to say that you should consolidate all of your content into a single site or merge together smaller Word documents. But you should consider doing a little housekeeping prior to migration. Anyone embarking on a SharePoint migration should have diligently prepared a Content Strategy and an updated Information Architecture, so does that call for a consolidation of some sites or a merge of document libraries or lists? A little prep work can go a long way.
An often overlooked technical factor is how you are making the connection to either the source and target environments. I frequently see “no server side install required” being touted as a feature of many migration tools, whilst others require services or agents to be installed. Not requiring a server side install is certainly an advantage – rather a must – when it comes to an Office 365 migration since Microsoft doesn’t allow third-party products to be installed on their servers. For migrations to on-premises SharePoint farms, you should weigh whether this is actually the best way to go.
Opting not to install anything on the server often means that you are sacrificing the longer term benefit of a larger time saving during migration for the sake of a smaller, short term gain for missing out the server install. There is a reason that migration tools come with these server side “optional” installs. The speed advantage over the out of the box connection methods from Microsoft is only one of them. They also open up the door for more complex migration scenarios or advanced migration features that are just not possible with Microsoft tools.
How Metalogix Content Matrix Helps
Thankfully, Metalogix Content Matrix has the best of both worlds. We recognize that it isn’t just those moving to Office 365 who can’t install a third party product on their server, therefore zero footprint migrations for both your existing and new SharePoint server are possible. If you do have the option of installing either Content Matrix itself or our web service on your servers, then we would encourage you to do so. The performance and migration capability benefits can be significant. Avoid spending a few minutes installing on the server or see a 4x, 5x or even 10x improvement in performance? I know which option I’d pick.
Above, I alluded to enhanced migration capabilities. There is one that can have a huge impact on speed – integration with Metalogix StoragePoint.
How Remote BLOB Storage (RBS) Fits In
StoragePoint uses Remote BLOB Storage (RBS) to remove up to 95% of your SharePoint content from SQL server. There are various advantages for using RBS with SharePoint, e.g. reduced storage costs, easier back-up and restore. But when it comes to migration, we can take advantage of not having SQL full of all our content.
Without RBS, you would have to migrate all content through the new SharePoint server and into SQL. Writing large amounts of data to SQL all at once is slow. With StoragePoint and RBS, you now only have to move approximately 5% of the data volume (metadata, site structures, etc.) that was left in your old SQL server into the new SharePoint. This method is usually referred to as a Shallow Migration. The rest of the data, the BLOBs, can remain in the alternative storage.
You will see a huge performance boost by removing the BLOBs using StoragePoint and therefore removing them from our speed equation for migration. The resulting time for the migration isn’t 5% of what it would have taken without StoragePoint, but it allows you to move over 500GB per day and see GB/hour speed that reach the high 10s. We have seen speeds that fly past the 100 GB/hour mark!
Another neat trick and performance benefit from Content Matrix and StoragePoint is when they are paired up for a migration – something called Side Loading. Whereas Shallow Migration leaves the BLOBs in their existing storage location, it is possible to move the BLOBs to new storage during the migration without the need to first write the data back into SQL.
Again, this results in faster migration speeds than without StoragePoint as part of your migration. Moving the BLOBs between an existing store, such as a file share, to a shiny new file share that perhaps uses faster drives is going to be quicker than migrating everything to end up in SQL. The added benefit is that you can also apply a new storage strategy at the same time as moving to a new SharePoint.
Find Your Speed By Testing
There are other technical factors that can impact migration performance. Making the best use of your hardware resources by employing multithreading for your migration or spinning up some dedicated hardware to help with the migration are a couple of examples. There are others, but I think I’ve given you enough food for thought right now.
In summary, I would love to give you a definitive GB/hour figure to help plan your migration. Unfortunately, there are too many moving parts. I’d be concerned that I was making a promise that I couldn’t keep due to the exact nature of your SharePoint. What I can do is help you to come up with your own exact number. The way you do that is test, test, and test some more.
Migrating to Office 365? You can migrate 25GB for free using Content Matrix Migration Express, a great way to test.
One size fits all? Nope. Tailored fit is always better than off the rack.