What NOT to Migrate into SharePoint 2010

For SPS 2003 I wrote a post titled What Not to do in SharePoint.  I updated that post for SharePoint 2007 titled What Not to Store in SharePoint. 

I think it’s time to visit this topic with SharePoint 2010.  It’s amazing both how much and yet how little things have changed in terms of what this list consisted of in SPS 2003 and now in SharePoint 2010.  I’ll call out what I think are the main differences to help you understand what has changed.

Start by researching: File name, length, size and character restrictions.  There are a lot of absolutes in that post that there’s really not much you could do without building an ISAPI filter which I don’t recommend doing.  This topic is also very relevant to various migrations including public folder migrations, notes, and file share / file server migrations.

Rather than rehash all my explanations of what I mean, you can read my previous posts on this topic to understand the background, rather, I’ll give you the updated thoughts.

Really Large Files

Guess what?  The 2GB limit persists.  I do think you’ll see many more pushing the limits way beyond the default 50MB with many more adopting the remote blob storage and yes based on document based on Microsoft R&D they suggest that those that store large files should be looking at the remote blob storage.  I do think people should still keep their limits at 2GB.

Files with Dependencies

The dependencies list has been reduced with the work in external lists.  I do think the relationship work in webparts and lists help a lot as well.  The multi user scenarios of Excel and the new work in Excel Services and Access and Visio Services in the application space take this a long way.  I still think people need to be smart about what excel spreadsheets they simply upload.  There are still some legacy SMB/CIFS calls that are made by Excel across workbooks that don’t work well with SharePoint when simply copied from a file server to SharePoint.  My encouragement… test.  While Access databases still shouldn’t just simply be uploaded, there are some great scenarios around publishing access tables as lists.  You just have to analyze what you’re doing.  There definitely IS new Scenarios in SharePoint 2010 and it’s more than simply uploading files, and more about rethinking the scenarios for how best to store the data in lists rather than in files or publishing the access, excel, etc… look at office web apps as the other new scenario.

Improvements: Service Applications: Access, Visio, Excel and new editing scenarios in Office Web Applications

Transactional Applications, Logging and files which require locks
While you still shouldn’t save your .pst to SharePoint, you definitely should consider syncing your contacts, tasks, and calendar.  I do think more in SharePoint 2010 will look at their lists as closer to relational, and tiny bit closer to transactional.  It still is NOT a transactional application and you still can’t wrap your changes.  Yes you have events and workflows, so you do have to think differently about using SharePoint as application storage.  Full CRUD operations against external lists. As objects SharePoint list scale takes this a long way.  I do think people will find using SharePoint for storing changes has come a long way.  Simply the scale of task lists and building applications on SharePoint has come a long way.

Using SharePoint lists as tables and building applications on those tables won’t give you primary keys and foreign keys, but you will find usefulness in the new external list functionality where you can do your work on the SQL side and bring SharePoint in as your interface.  This has come a long way.  I also think you’ll appreciate ECM enhancements like Document ID.

I would still suggest that people NOT store their logs or even be very careful about .NET applications that are highly transactional and highly relational in SharePoint. Consider something like IIS logs.  You wouldn’t store them on SharePoint because they are large, and it will be more difficult to work with them.  SharePoint as an interface, that’s another consideration.  If you’re going to have more than 10 million entries in the life of the application then it’s a no starter.  Better to put it in SQL and look at integrating SQL 2008 R2 and PowerPivot for SharePoint 2010.

Improvements: External lists, Scalable lists, Enhancements in Workflow, and document ID

Application Developer Resources and Source Control (i.e. files commonly generated by Visual Studio)
First I think the packaging built into saving SharePoint’s own applications as solutions is a big deal in SharePoint 2010.  You still shouldn’t store your your C# code in SharePoint.  I think that makes sense these days.  TFS itself has come a long way, especially in it’s SharePoint story.

I do think it’s great to see improvements in file groups.

Improvements: Better Visual Studio Packaging for SharePoint, File Groups

Application Distribution
I do more and more see SharePoint as a front end for product distribution, but those packages are difficult to manage in SharePoint not only due to blocked file types, but also in the management of the groups of files.  File groups should make it easier to bring things together like a folder to build a package, but the access would be strange for both loading and extracting from a file and run perspective.  I don’t like the idea of storage of a product like Office or IE the application itself.

Improvements: File groups

Server Side Scripts
Bad idea.  Still not a good idea to store random ASP or .NET files.  From a pure SharePoint perspective there is a new scenario you should be aware of.  Administrators can now allow client solutions to be uploaded.  These WSP web solution packages known as sandbox solutions can be performance limited and controlled.

Improvements: Sandbox Solutions for templates, the new client API, and new packaged changes produced by SharePoint designer

Backup
SharePoint is not designed to act as a backup (i.e. *.bak, *.iso, etc) resource.   Along with the large files, SharePoint while you will find it more common as a backup for collaboration data and even more and more files with SharePoint seen as an archiving system with remote blob storage and it’s usefulness as an ECM platform repository, it is still not a place to store large ISO files. 

The new scenarios are record repository, file repository, and as people are working with file formats that are compatible with SharePoint and leveraging common desktop applications that have been updated to work with the web, like pictures, desktop applications are becoming more compliant and understanding the way we work with the web.  So essentially SharePoint does not become a tape device, but will more and more be seen as a mechanism for archive.

Improvements: ECM and RM enhancements including remote blob storage in SQL 2008 increase it’s viability

Large Media
Media itself has taken a turn in SharePoint 2010.  With the silverlight webpart and support for streaming media straight from document libraries, SharePoint 2010 takes a leap forward in support for media.  If you were to analyze youtube.com you’d find that the maximum upload is 10 minutes or 100MB.  I think that’s totally acceptable for SharePoint 2010 and with the large list enhancements and RBS you’ll find SharePoint as digital asset management more and more common.  Note the 2GB limit mentioned above.  For feasibility I still think it’s a bit crazy to store more than a few hundred MB in SharePoint databases, but RBS enhancements SQL 2008 R2 with third party do make me consider exceptions of up to 1GB.

I still don’t think you should dump most Training CDs or Product or that kind of media to SharePoint.  Most are still designed to run from the file system.

Improvements: Streaming media support, silverlight webpart for media, better image and thumbnail support, better all around digital asset management including remote blob storage considerations with third party vendors with SQL 2008 R2 (I don’t recommend using the SharePoint 2007 SP2 API)

Blocked Files:  Careful with Non "Web Friendly" Characters and Long File and Long Site Names
More data on this topic at the post referenced in the first paragraph.  SharePoint sites may not include the following characters:

/ : * ? " < > | # { } % & <TAB>”.

Additionally, the following characters cannot be used in the naming of files to be uploaded to SharePoint:

" # % & * : < > ? { | } ~ .

SharePoint file names cannot exceed 128 characters in length.  Filename + folder structure + site structure + hostname should not exceed 256 characters.

Understanding the Evolution of SharePoint as a cloud based storage not traditional file system

While SharePoint isn’t a file system, there have been a couple of significant changes that should be noticed.  One Azure and the SharePoint Service, and the other the Office Web Applications.  With Word, Excel, PowerPoint and One Note as not only viewers, but editors in the SharePoint 2010 interface it is now even more easy to see SharePoint 2010 as a kind of file system, but sure you can’t run your desktop from it.  As those who design applications consider the cloud more and more applications will work better with SharePoint. Many would point to quotes from Ballmer in the past when asked if SharePoint was the future operating system in the cloud, and his flippant response.  It’s interesting to watch this evolution, but please don’t look at this as a pure replacement for file shares as it’s far from that.  The better you understand what works well and what doesn’t, you can make better decisions about how and when data should and shouldn’t be moved.