The first in a series, this article addresses the challenges and process of moving to Microsoft SharePoint 2013. I'll share some of the experiences that I've had and wisdom that I've gained working with many companies of all sizes and shapes over the past decade. My overall goal is to help you learn more about SharePoint 2013 and better understand the challenges and benefits of migrating to the platform.
Related: Top 10 SharePoint 2013 Features Cheat Sheet
The sources and combinations of data and applications that clients want to move to SharePoint come in every shape and size. However, I'll share my experiences with some of the more common sources that my team and I have run into.
For example, many clients have a previous version of SharePoint—some even as far back as SharePoint 2003—and want to get on the "cutting edge" with SharePoint 2013. I'll provide information about what's new and different in SharePoint 2013, compared with previous versions. Another typical requirement is to move from file shares to SharePoint. This task spawns numerous discussion topics that pertain to SharePoint tools. In this situation, metadata, folders, documents sets, versioning, records management, and other related issues are important to understand.
Read More: Installing SharePoint 2013
I can't touch on every possible source of content and data (e.g., specific wiki products). But I'll identify nuggets of wisdom that can help your organization understand the size of the challenge and obstacles that you might encounter.
What Is SharePoint 2013?
Many people use the analogy of SharePoint as a Swiss Army knife to describe all the product's useful tools and capabilities. Microsoft has marketed the platform in a variety of ways over the years. Although the company tends to overcomplicate SharePoint, let's start with the Microsoft "message."
Figures 1 and 2 show the current marketing images that Microsoft uses to educate people about the SharePoint 2013 product line. Figure 1 provides a high-level overview; Figure 2 shows the more detailed overview. (Search the Internet for "SharePoint Overview FINAL" and you'll find more overview information on all sorts of sites.)
I find that the high-level overview doesn't go deeply enough into SharePoint's purpose, yet the detailed version goes too deeply into the toolset and becomes overly technical. Therefore, I like to break down the capabilities of SharePoint into the following buckets:
- Sites
- Content
- Search
- Applications
These will be the main categories that I'll explore in this and upcoming articles.
The Sites bucket includes the organizational units of web applications that house site collections, site collections that house sites, and the sites themselves. The Content bucket includes not only files and metadata about those files, but also databases, intranet content, blog content, RSS feeds, and so on. The Search bucket includes SharePoint 2013 search tools, which incorporate FAST search tools from the SharePoint 2010 FAST search add-on product, search refiners, and other search tools. The Applications bucket covers features such as workflows, dashboards, mash-ups, scorecards, full-blown .NET applications sitting on the SharePoint platform, and the new apps as defined by SharePoint 2013 technologies. (For more specifics about the new features in SharePoint 2013, a great place to start is the Microsoft SharePoint 2013 page; expand the Explore node on the left side of the page.)
Meeting Business Needs with SharePoint 2013
Since SharePoint hit the market in 2003, organizations have had similar questions and concerns:
- We've put all these documents on file shares, but no one can find anything, and there's no organizational structure to it all.
- We want to automate business processes and fire the person who carries the stapler from one side of the office to the other.
- We want to get rid of some weird applications that we're using. Can we port them to SharePoint?
- How do we do records management and enterprise content management?
- We need an intranet. Our old one is terrible. People hate it and don't use it.
- We need an extranet to collaborate better with our external partners.
- Did we mention that no one can find anything?
Each client has unique and varied requirements that can take many hours to clarify and gain agreement on. (One client recently requested a "sexy" UI!) An important point to remember is that a goal should be actionable and measurable. In a SharePoint project, this should translate to a deliverable or deliverables. For example, the goal "SharePoint should make employees happier" is so high-level that it is difficult to translate into specific features and deliverables. On the other hand, the statement "SharePoint should improve social interactions between employees" can be translated into deliverables such as My Sites and Communities and can include the gathering of more details about the current gaps in social interactions.
To begin, I use a basic workflow with clients. It's adaptable to the different business requirements that drive the use of SharePoint, so I'll provide several iterations in this and future articles. I'll revisit various portions and dig deeper into its sub-routines in following articles. Figure 3 shows this workflow, simplified at a high level (as evident from the telltale loops that are a warning sign in any workflow diagram). This workflow captures the process needed to get from Requirement (i.e., "I need a new home for my data") to an Approval or Rejection decision.
Digging a little deeper into this process, most organizations have file shares, Microsoft Exchange public folders, Google Docs, and Dropbox or Box repositories that are out of IT's control. Many organizations want to centralize a portion of this data. Step 2 in Figure 3 forces (or encourages) the organization to qualify and quantify the specifics of this data.
For example, data often lives in databases, which can be Microsoft SQL Server or Access, IBM, Oracle, cloud-based, or many other formats. Most organizations have adopted various wiki, blog, data-streaming technologies, or other document-management tools that compete with SharePoint. These organizations have specific needs depending on file types: A construction firm might have a ton of Autodesk AutoCAD files; a marketing organization might have many .raw files; a law firm might have Corel WordPerfect files. And don't forget about all the Apple Macintosh-specific file types. It is a rare company that simply wants to move Microsoft Word, Excel, and PowerPoint files to SharePoint. So Step 2, innocuously encased in its little box, can be quite a bit more complex than a quick review of a file share.
Likewise, Step 3 ("Determine if SharePoint 2013 offers the right tools for housing the data") can quickly become complicated. Research and discussions with experts in the SharePoint field might suffice, but actual lab testing with the SharePoint 2013 toolset might be needed. In addition, whether to use SharePoint Foundation 2013, SharePoint Server 2013 Standard, or SharePoint Server 2013 Enterprise is an important decision. Depending on the details of Step 3, Steps 4 and 5 might be theoretical (if no actual testing was done) or official and backed up by real evidence.
Building On Your SharePoint Knowledge
I'll dig more into the details of these steps in the next article in this series. I'll also delve into the capabilities of SharePoint 2013 in managing different types of files, since the product has so many types of repositories and capabilities. Lists and libraries are the main two types of repositories, but you need to understand the capabilities and limitations of lists and libraries in terms of supporting different file sizes and types. You also need to understand the use of folders and document sets. And I'll share some common tools that I've used to help clients get a handle on the type of files they actually have, the quantity of those files, when they were last accessed, and more.
