It's nearly impossible to miss all the buzz surrounding the cloud in recent years. However, there's no clear consensus on what the cloud actually is; the definition changes depending on who you talk to. This confusion exists especially when referring to Microsoft SharePoint cloud services. SharePoint can be an organization's intranet, extranet, document-management environment, records-management space, or full external website. Combined with the complexity of the SharePoint Service application layer, a cloud service could mean many different things to many different people.
In its broadest definition, the cloud for SharePoint refers to a service that allows an external provider to host and manage SharePoint functionality. This provider typically handles much of the administration and maintenance of the environment. This approach provides significant incentives for many organizations -- particularly the promise of reduced overhead, a serious enticement when IT resources are consistently tasked to do more with less. At the same time, the cloud is no panacea and doesn't necessarily work for all organizations. The key to determining whether SharePoint in the cloud makes sense for your environment is first to understand how hosted SharePoint differs from an on-premises SharePoint deployment.
What Is the Cloud?
Ask 100 SharePoint administrators to define the cloud, and you'll likely get 100 answers. Although the catchphrase is used extensively across the industry, there is no one definition. There are many types of clouds, and various services offer cloud options, each of which differs slightly from the others.
For the most part, a cloud service is defined as an IT function that is housed, maintained, and (usually) administered by a third-party. The driver toward cloud services for most organizations revolves around the fact that most modern organizations prefer to focus on their core businesses rather than on the busywork of maintaining IT. This opinion is the guiding principle and main perceived benefit -- mainly, the ability to offload IT to a company that specializes in it -- of cloud environments.
Cloud services come in many shapes and forms: application clouds, infrastructure farms (both shared and dedicated), and private clouds. Each of these cloud options will be described in more detail in the following sections.
Application Clouds
An application cloud is one in which the application layer of the service is offered to users. For SharePoint, this means environments that offer SharePoint sites and their associated document libraries, lists, and other application-level functionality. These types of clouds do not allow any type of low-level, infrastructure-based functionality, such as configuration of service applications in SharePoint (with some exceptions). Typically the most limited type of cloud offering, application clouds are also often the most cost-effective. The economies of scale with this type of cloud allow for massive numbers of small-to-midsized businesses (SMBs) to share the same physical hardware, reducing the total overall cost to each organization.
Several companies with SharePoint offerings can provide application clouds. These companies effectively allow you to host your SharePoint site or sites on their servers for a designated cost. This cost varies depending on the uptime requirements, level of support, amount of stored data, and provided services.
Microsoft provides one more well-known offering in this space, in the form of SharePoint Online, a component of Microsoft Office 365. Office 365 is Microsoft's application cloud offering and includes messaging functionality through Exchange Online, IM capabilities through Microsoft Lync, and the collaboration features of SharePoint Online. (See the sidebar "SharePoint Cloud Vendors" for a list of several third-party cloud providers.)
Figure 1 illustrates the various versions of Office 365, along with their typical list prices (subject to change). All plans include access to SharePoint Online, though some of the lower-level plans (e.g., the K1 and E1 plans) allow only read-only options for accessing content within SharePoint. The decision of which Office 365 plan to choose is complex and depends on the size of the organization, its messaging needs, the type of workers that it includes (i.e., knowledge worker versus kiosk worker) and whether the full Office suite of tools (e.g., Office Professional Plus) is already available or needs to be purchased. Organizations that are interested in purchasing Office 365 should check directly with Microsoft; costs can vary depending on your licensing situation and the particular geographic area in which your organization is based. Indeed, not all locations offer access to Office 365 or some of the other SharePoint cloud offerings.
Figure 1: Office 365 versions
Infrastructure and Private Clouds
Infrastructure cloud options differ from application clouds in that infrastructure clouds typically allow an organization's servers to be hosted and managed by a third-party but administered and provisioned by the organization. The customer's internal network often extends into the third-party cloud provider's network so that the servers within the private cloud can communicate directly with internal servers. This approach allows the full functionality that you'd expected from internal servers but has the cloud-based advantage of outsourcing the power, cooling, and rack-space requirements.
Private clouds are often created on virtualization platforms that allow for quick provisioning and de-provisioning and a flexible systems infrastructure. For example, private cloud providers might allow the customer to provision virtual servers; the provider simply bills back the customer for the processor time, storage, and memory used. This scenario is often useful for organizations that completely virtualize their SharePoint environments. Such an environment is a supported topology that Microsoft outlines as part of its Server Virtualization Validation Program (SVVP).
However, the setup does require special attention to the disk I/O, memory, and processor requirements of SharePoint Server 2010 and Microsoft SQL Server.
The main advantage that infrastructure and private clouds provide is flexibility to build servers to you specifications, to configure your farms as you prefer, and to take advantage of all the functionality of SharePoint, without needing to physically manage the servers yourself. For example, customers can take advantage of the Microsoft Business Connectivity Services (BCS) Service application to have SharePoint sites directly access data that's stored within business data repositories that are physically housed on internal database servers. (This arrangement includes scenarios such as a company that wants to display internal customer relationship management -- CRM -- or sales data in SharePoint sites.) This type of functionality is not readily available in the majority of application cloud models.
The disadvantage of private cloud models revolves around the need for customers to manage, maintain, patch, provision, and de-provision their servers as they would if the servers were stored internally. Much of the administration remains the same, aside from that required to maintain the virtual hosts that are stored at the virtual cloud provider.
From a migration perspective, however, infrastructure and private clouds offer the significant advantage of allowing out-of-the-box and traditional migration approaches. For example, site collections can be migrated directly via Windows PowerShell or the Stsadm tool, as opposed to requiring third-party tools.
Determining Cloud Requirements
Many factors can be overlooked during the process of determining whether to move to SharePoint cloud-based solutions. Cloud environments sometimes give administrators a false sense of completeness. For example, customers assume that the cloud provider will take care of everything. This is typically not the case, however, and many organizations still must put a significant amount of thought into how the new environment will look, how to categorize content, which type of authentication to use, and other crucial decisions.
Determine URL Strategy
A relatively minor but extremely important factor to consider for SharePoint is simply, what will the URL of the environment be? Some cloud solutions offer the ability to use a vanity URL, such as sharepoint.companyabc.com; others do not. For example, you might need to use a shared URL, such as customerx.sharedproviderabc.com. Current use of internal URLs to access SharePoint can further complicate the issue, particularly if content will be migrated to the cloud-based solution in phases. Determining what the URL will be and how to migrate content between URLs subsequently becomes a tricky task.
Some organizations deal with this issue by simply creating a landing page on the legacy environment, to direct clients to the appropriate site online. After all sites have been migrated, that landing page can then be changed to redirect content automatically. Certain application-layer intelligent systems, such as Microsoft Forefront Unified Access Gateway (UAG) or Threat Management Gateway (TMG), can also intercept and redirect specific paths within URLs.
Define Search Requirements
SharePoint Search is a crucial but often overlooked feature within both internal and cloud SharePoint environments. The ability to easily find the content a user is looking for can make or break a SharePoint environment, so you should put proper thought into the design of Search. However, putting SharePoint in the cloud complicates this equation, as not every SharePoint cloud provider allows the ability to provide for full search across the entire environment. In addition, a search service application in the cloud can rarely crawl and index internal content, so organizations might instead decide that search capabilities need to be kept internal.
You absolutely need to know the true search requirements of SharePoint, in advance of the migration. If, for example, enhanced Search using Microsoft FAST Search Server for SharePoint is required, then you might need an internal Search instance that in turn crawls the SharePoint cloud solution to provide federated search of both internal and external content.
Categorize Content
Proper information architecture and categorization of content is key to an organization's ability to locate required content. Unless a crucial document is tagged with the appropriate metadata, it becomes invisible and there will be a significant amount of duplication of content within the environment.
SharePoint in the cloud can also pose unique challenges in that you might not have access to the Managed Metadata Service application, which allows you to apply metadata tags consistently across multiple farms. If this application isn't provided, then finding a solution that allows you to properly tag content, especially during the migration process, becomes even more crucial.
Determine UI Requirements
Working on a consistent and attractive look and feel of the SharePoint environment is incredibly significant in improving end-user adoption. Users expect their collaboration environments to be easy to use, to be streamlined, and to have an appealing look.
The type of customization that is allowed with some cloud options -- particularly application cloud options -- might be subject to significant limitations. Some options allow customization with tools such as Microsoft SharePoint Designer, but others are completely locked down as far as what can be modified. It is important to define the requirements of the organization, in terms of UI customization, and to identify the cloud solutions that allow this level of customization.
Outline Security Requirements
The security of the target environment is a crucial part of the design, particularly when dealing with cloud deployments. By their very nature, these deployments are usually accessible to the entire Internet population. If the security of the source environment is tight and well-defined, then attempting to recreate the same security in the target environment might make sense, assuming that the same accounts or account names will be used in the cloud space. However, if the security is a mess to begin with, then restructuring security permissions during the migration might be a better option, even though it can lead to other access issues during the migration.
Define Authentication Requirements
An important question when determining whether to use a cloud service is, quite simply, which accounts will users use to log in? Determining which accounts to use and whether users will need to enter a username and password to access the system is a major decision that has significant long-term implications.
Bear in mind that not all cloud providers offer the option to authenticate to your own internal credentials. The noticeable exception is Office 365, which allows authentication options that use your own internal Active Directory (AD) environment and Active Directory Federation Services (AD FS) 2.0. This approach, which Figure 2 illustrates, requires federation between your internal AD environment and the cloud provider; in Office 365, this is accomplished by using AD FS. The result is that users don't need to authenticate twice to access the SharePoint environment, their mailboxes, or the Lync client.
Figure 2: Using internal AD accounts for cloud access
The alternative approach to authentication is to use the accounts that the cloud service provides, as Figure 3 shows. Cloud services typically provide this option, as does Office 365.
Figure 3: Using accounts provided by the cloud service
The obvious advantage to the AD FS option is single sign-on (SSO), but infrastructure and complexity are increased. Organizations should determine which strategy matches their requirements.
Migrating an On-Premises SharePoint Environment to a Cloud Offering
As I mentioned earlier, migrating to SharePoint in a cloud space has several limitations that can affect the migration process and limit the available options. In internal environments, an upgrade to SharePoint 2010 or a transfer of content from one farm to another supports many more options than migrating to the cloud supports. Therefore, identifying which methods are available and determining whether these methods provide the necessary capabilities is a crucial step.
Script Migration Process
For some cloud solutions, particularly infrastructure-based solutions, you might be able to use PowerShell to script the migration of SharePoint content. PowerShell allows you to backup individual site collections from one farm and restore them to another farm. Use the following syntax to perform a backup:
Backup-SPSite -Identity-Path [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]
You can then use the Restore-SPSite cmdlet to drop that site collection into the target SharePoint farm. The big limitation to using this approach is that it is only as granular as the site collection itself and requires a level of administrative access (on the target farm) that SharePoint cloud solutions seldom provide.
Keep in mind that PowerShell supports an export option for content, allowing a more granular export of specific document libraries or subwebs from a
site collection. The syntax for export is as follows:
Export-SPWeb -Identity-Path [-ItemUrl ] [-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression] [-GradualDelete] [-Verbose]
The major limitation to using export commands is that they don't perform a full-fidelity extract of the contents. Indeed, export and import operations concern themselves only with content, so features such as workflows are lost during the move process. Therefore, using the Backup-SPSite cmdlet is preferable, if possible.
Using SharePoint Designer and Outlook 2010
An alternative approach to performing migration on a small scale with SharePoint is to use client tools such as SharePoint Designer or Microsoft Outlook 2010, which can be connected to both source and target SharePoint farms and used to manually transfer content between the environments. This scenario scales for very small environments only and doesn't work if there is a significant amount of content to transfer. The advantage to this approach, however, is that it can be used when administrative access to the back end is not provided. Another option is to use Explorer view and mapped drives to provide the ability to move content, although this approach doesn't scale very easily.
Third-Party Migration Tools
Aside from these two rather limited options, the only effective way to improve on SharePoint migration is to enlist the help of third-party tools. Each tool is different, so it is important to examine each tool's functionality and compare it to the business and technical needs of the migration.
Understand the Pros and Cons
Determining whether to move to a SharePoint cloud model is by no means a simple proposition. The lack of any built-in migration tools is simply one of the challenges. IT planners also need to consider the authentication options, the services that they will need, and whether security will be restructured in the process. In addition, you need to consider exactly which of the myriad types of cloud offerings to use. Understanding the pros and cons of each approach can help to streamline the decision process.
Sidebar: SharePoint Cloud Vendors
This article discusses using Microsoft as your cloud vendor. There are numerous third-party options as well, including -- but not limited to -- the following providers:
