Document migration in SharePoint: Considerations

Background

I mentioned in my last post entitled “Document Migration in SharePoint – Your options”, that there are basically 4 main options available to you when deciding whether to migrate content from your file shares and other repositories. To summarise:

• Migrate completely into SharePoint
• *Partial migration of a subset of the content into SharePoint
• **Leave where it is and continue to maintain both repositories independently
• ***Leave where it is and continue to maintain both repositories, but use SharePoint to index your old content, hence providing capability to search it.

One or more of these options may be the route you end up choosing depending on your needs and requirements.

*The older content may well be archived or just deleted.

**Consider the expense and risk here maintaining ageing equipment

***This has limited options, investigate thoroughly and test in particular the search results, hence use with caution.

Next steps and considerations

To help you through this decision process to determine which route is best for your circumstances, I have below written a few pointers for you to consider and debate within your core project team and stakeholders alike. These comments are based on several years of managing a variety of SharePoint projects, so hopefully you will avoid some of the painful lessons learnt that we and our clients went through! It’s probably not everything you need to think of, but a good start with a few thoughts to help you along your way.

“Migration can be expensive especially when you consider the volume of information you are intending to migrate, the true cost of the business and technical resources (internal and external) you intend to schedule in to help with the migration effort”

Question your stakeholders & senior users as to whether or not they really do need to move across all those documents and intranet pages, images, video, etc. Based to some degree on anecdotal and empirical, my experience shows time and time again, 80-90% of content is seldom if at all accessed beyond 12-18 months after it was created. So you could be creating a mountain of work, for very little return in value.

I therefore recommend trying to find supporting evidence to confirm it is (or isn’t) accessed frequently or other statements supporting or otherwise the migration requirement. Find out why it actually ‘needs to be migrated’, almost like putting together a mini business case decision process. Often business units will just say it is, to avoid doing the work of investigation or migration in the first place because they have other (naturally so) priorities. The reality is a good old clear out is often a welcome and good opportunity to freshen the content up, archive older elements of content not longer required.

I also strongly recommend you carry out a review of the content that has been amassed over the years. You may be surprised to find out how much of it really is no longer needed, relevant or appropriate and or actually identify content that needs to be refreshed anyway.

Remember also there is a subtle, but important difference between it being ‘available’ to the business and it being migrated and available in SharePoint. For example, you may keep it away from SharePoint in less available, but still accessible offline media or other perhaps cheaper forms of storage.

If you do determine that you will have a large amount of content to migrate, really do put in place a ‘blueprint’ for the migration team(s) you mobilise, make sure everyone is aware of their roles, their tasks and when they are supposed to be doing them and why. They in short need to be fully on board with what is being done.

You also need to ‘prove the process works in advance of proving the throughput’ for your migration teams. This goes for the manual, automated or mixture of both approaches. Be generous in your estimates for migration based on the results of your findings. This will give your stakeholders confidence in your project teams ability to meet the migration deadlines.

“Impact on overall SharePoint architecture needs to be planned into the overall design”

Hopefully you will have covered some or most of this in your original SharePoint architecture planning…Think about the increase in load on your physical server environment, capacity planning issues, impact on search results, overall navigation and usefulness of your content, to name but a few areas that need thought and evaluation when considering migrating existing content into SharePoint.

For example, if you’re going to move and or index any of the externally stored content into your SharePoint environment, consider the implication for the increase in storage you are about to place on your environment. Not least because the increase in size isn’t just for the raw data storage of content being added in your SQL databases, but also the new storage required to handle the increased index file sizes.

Then consider the additional load you have just placed on your backup & restore processes! You might bring potential pressure on your ability to meet your SLAs for service availability in case of downtime. For example can you still restore your newly increased content databases in the time allowed within the SLAs?

“Evaluate 3rd party tools to help you with the volume of data”

Many 3rd party products do a great job in helping you bulk migrate/upload content into your SharePoint environment. However, many will not meet your requirements fully, so review them carefully and plan their performance (or lack of) with migration and costs into your plans and budgets. It’s important to know their limitations as well as their strengths. You may find they migrate many, but not all of your document types. Also, quite often you will lose some important document properties or other meta data associated with the document or pages you are trying to migrate.

In addition you may lose data integrity for example the timestamp information. This is typically something that may be important from a records management perspective, as it may not be carried across to the new environment.

“Ensure you get the business to take the lead in migration”

By all means provide the blueprint (approach), tools and methods in which ensure content can be migrated. Ultimately however the business users should ‘own’ the actual migration and be fully involved in this part of the project from the beginning. They are best placed to know what content is or isn’t required, how it should look, be accessed, etc. It also happens to be one of the best methods to educate your end users in the use of SharePoint capabilities you are providing to them overall.

“Consider regulatory obligations to retain data”

Several business sectors in particular the government/public sector, finance, health and charities have particular regulatory rules they have to follow for data retention, availability and access (data protection issues as a whole). These will need to be factored into your plans.

“Disinvest and or reuse your old hardware”

The migration from old intranets, file shares or other applications potentially allows you to disinvest your hardware (or at least some of it).Plan for this effort, even if it just find out how are you are going to recycle the kit or have it removed from the server rooms. Do consider charitable organisations or schools that might benefit from the old equipment rather than dumping it in landfill.

“Remember, not all data should or can be stored in SharePoint”

It is true SharePoint can index a variety of content sources. But the painful reality is this rarely achieves the results originally desired, due in part not because of product failures per se, but because the general maintenance of SharePoint based searches take a lot of ongoing effort that is often forgotten or omitted in the design or on-going maintenance.

Quite often it’s the easy route to index your ageing and bulging file shares, but would you really want your search results to contain information from sources that is so old and out of date? Without the careful design at the beginning, fine tuning and regular maintenance required often you end up with a poor experience from a user perspective.

So by all means consider indexing your sources, but really do understand the implications from a design, planning and ongoing maintenance perspective not least the users experience with the search results pages. On the latter note, consider all of the out of the box options that you have with search and also introducing filtering for your search results content (custom or 3rd party route).

“Consider leaving the content where it is”

Try to understand both the tangible and intangible benefits of leaving the content in situ, and perhaps making the content ‘read only’ for a period of time whilst you consider your options and or carry out your migration, so as to not allow the increase, or changing of content stored in this area.

Conclusion

There are lots of things to consider as part of your discussions for deciding the approach to migration and the above are just some of the topics you may have to consider.

It’s often politically the ‘path of least resistance’ to just migrate all content, irrespective of the technical and sometimes the financial rational for doing something different. If you haven’t already, consider introducing archiving, quota and retention policies to manage the no doubt increasing volume of data in your environments.

Do engage with your stakeholders and get their buy-in to owning the migration piece. Often a strategy of making sure the business carries out this migration will make them think differently when it is their resources that are taken off their normal roles to do it.

Finally, in my experience migrating and refreshing a small subset of the original content into SharePoint, plus archiving the rest is the appropriate approach for most circumstances. Turning on SharePoint indexing capabilities for your file shares, but only in small and measured circumstances is also something you should consider.