Humans have always been obsessed with speed. We have always wanted to move faster. We have engineered race cars that zoom past 200 miles per hour. We have invented airplanes that break the sound barrier. We are drawn to speed – sellout crowds pack stadiums to watch Usain Bolt and cheer for the World’s Fastest Man.
The need for speed is the same when it comes to consuming, processing and sending information. The way we send critical information has evolved – from letters to faxes to emails to smartphones and tablets. We are constantly in a race to do things quicker and more efficiently. Why should that be any different for SharePoint?
For organizations deploying SharePoint, the platform is now a business-critical application with hundreds of thousands of users collaborating constantly, sometimes from across the world. There is no downtime for SharePoint – losing precious time to improve SharePoint infrastructure could be a crippling blow to an organization’s bottom line.
Since the release of SharePoint 2010 and its enhanced, robust set of features, organizations have discovered that the best way to maximize productivity and collaboration is to be fully deployed on SharePoint 2010. However, this can be a daunting task – whether it entails upgrading from SharePoint 2003 or SharePoint 2007 or migrating content into SharePoint from file shares, Google Apps, eRoom or Documentum to name a few.
Regardless of project’s scope, all administrators have a common desire – to perform the SharePoint migration or upgrade as quickly and efficiently as possible. There has never been a SharePoint administrator who has complained that a migration project was completed too quickly.
To address the need for speed, Microsoft SharePoint MVPs Stephen Cawood and Michael Noel have co-authored a white paper on the topic, entitled “Migration Performance and Speed Considerations for SharePoint 2010.” The authors take you step-by-step through a SharePoint migration, highlighting the key points you need to know before even starting a project.
For example, here’s an excerpt from the white paper discussing why the size of your SharePoint content doesn’t matter.
THE COMPOSITION OF YOUR DATA – SIZE DOESN’T MATTER!
The composition of your data set will be the largest single factor that influences the time it takes for you to migrate your content. For example, very large documents will have a much higher gigabyte (GB)/hr throughput than the equivalent amount of data stored within a SharePoint list containing thousands of items. This means that SharePoint databases with only large documents will achieve higher speeds (when measured in GB/hr) than SharePoint databases that contain lists with thousands of items. The reason for this is that the list with lots of entries will require a long time to reproduce on the target server while the large documents will simply be a steady stream of data—more data will be copied for the large documents and therefore higher GB/hr.
When discussing performance, migration speeds are generally measured in GB/hr, but that value doesn’t have any meaning whatsoever unless we understand the composition of the content. It is important that you plan specifically for the type of data that you are migrating. The best advice is “test early and test often.” Find out as soon as possible what sort of data set you have. Also, by running tests early, you’ll be able to compare results as you look at the various factors that influence migration performance. Only by having your own baseline tests will you be able to compare apples to apples.
The authors also discuss the different type of migration methods and determining the best way to maximize migrations speed while maintaining the full-fidelity of your content. One way of improving migration speeds is through a shallow copy migration.
While traditional migrations using third-party solutions copy entire items or documents, shallow copy migrations involve the use of Binary Large Object (BLOB) offloading solutions such as Metalogix StoragePoint. This means that the bulk of the items and files to remain in the same place during the migration, which reduces the total volume of data copied by up to 95% and leads to radically faster migrations. Cawood and Noel help explain shallow copy migrations in this excerpt from the white paper:
UNDERSTANDING SHALLOW COPY MIGRATIONS
A shallow copy migration is one where only the metadata for each item or file is migrated directly into the SharePoint content databases and the BLOBs are left in place. BLOB offloading is accomplished using Remote BLOB Storage (RBS) technology, which is supported in SharePoint 2010.
RBS removes BLOBs from content databases and stores them on an alternative storage location and mechanism of your choice. RBS works at the SQL Server level and is transparent to SharePoint users. To perform a shallow copy migration, you’ll need to combine a solution, such as Metalogix StoragePoint, that utilizes RBS together with a migration solution that is shallow copy enabled, such as Metalogix Migration Manager for SharePoint 5.0.
The end result of the migration process is the same as other migrations or upgrades. SharePoint—and all the SharePoint users—see the content exactly as it would if the BLOBs were stored within the SQL Server content database, but migration times can be vastly reduced because there is no need to physically copy the bulk of the data from source to target. Users are still able to perform all of the tasks within SharePoint that would normally be possible, and the interface is unchanged.
You can read the full white paper by clicking here: Migration Performance and Speed Considerations for SharePoint 2010
In December, Metalogix announced the release of Migration Manager for SharePoint 5.0, which includes full support for Nintex Workflow and can produce full-fidelity migration speeds of more than 500GB per day. You can read the full announcement here: Metalogix Announces General Release of Migration Manager For SharePoint 5.0 With Full Nintex Workflow Support And Enhanced High-Fidelity Migrations In Excess Of 500GB Per Day
