Designing a SharePoint 2013 Architecture

Moving or Upgrading to SharePoint 2013?

When discussing SharePoint 2013 migration, most will say: “It’s easy! Simply attach your existing database to your new farm.” But with this article, I want you to take time and think about it and analyze the options available to you, before going ahead with the move.

In some cases, taking an older SharePoint content database and attaching it to new SharePoint server could be a great scenario.

If you remember in my previous article, we mentioned that SharePoint 2013 can run a site collection in SharePoint 2010 mode as part of the migration process.

While it does make sense to eliminate your old environment after the migration, and to have everything moved to the new farm, there is one question you should ask yourself.

Will you move your Intranet from 2010 to 2013, or will you upgrade your Intranet from SharePoint 2010 to SharePoint 2013?

Designing Your SharePoint 2013 Architecture

When designing the architecture for SharePoint 2007 or 2010, it was always done with the available resources of the platform, but also with its limitations.

For example, you may have stored all your content within the same Site Collection, knowing it can be difficult to query outside of it. SharePoint’s available features will influence the way we build the architecture of our environment.

SharePoint 2013 brings along new features and functions that could change the way teams collaborate and share. So why would you simply copy the same environment built for 2007 or 2010, limitations and all?

Here are some of the features to keep in mind when building your new architecture.

Query Content from Everywhere

As mentioned above, in the earlier iterations of SharePoint, we had to plan our architecture while taking into consideration the boundaries of the platform.

If content was stored in different sites within a Site Collection, the Content Query Web Part would be the only way to query what we wanted to display on our page.

Of course, there was always the search option, but since it depended on a crawl schedule and it seemed complex for a power user to set up things like “managed properties”, we kind of ignored it.

So, we built our architecture based on this knowledge. If a customer were to ask me to create a Site Collection for Marketing and one for Research, I would have to look at the collaboration needs of the two teams before I could jump and say “Yes, we should do that.”

Luckily, with new versions comes new features. Thus, new architecture possibilities. SharePoint 2013 has introduced two things that impact our architecture planning when we are considering pulling information from outside our site.

First, the new Search experience with continuous crawl. This means that it is constantly searching your indexed content, throughout your entire SharePoint environment. If someone adds a document, it will be available through the search results.

Second, is the new Content Search Web Part. Which, like its predecessor the Content Query Web Part, will allow you to build a search query and display the results using a display template. The main difference is that you can easily, without having to master the XSLT language, aggregate content from multiple locations in a single, user-friendly, display template.

These changes mean that the barriers between Site Collections have fallen, and thus should no longer be taken into consideration when building an architecture. It could completely change the way you build your new SharePoint environment when planning a migration.

Cross-Site Publishing or XSP

The architectures built in SharePoint 2007 or 2010 for our extranets or public facing sites may be very different from what can be built in 2013.

With the new search breaking the barriers between Site Collections and Web Applications, users can write content in one place and have it surface somewhere else.

This means that if you have information that needs to be displayed in your extranet, it no longer has to be hosted within that Site.

The above graph is redesigned version of an image explaining XSP from the Microsoft blog – I find it to be a great visual explanation of the concept.

Gaining SharePoint Knowledge

Let’s face it. When you started building your SharePoint 2007 or 2010 architecture, you probably didn’t know about the Content Type Hub, Document Information Policies or how to use the Managed Metadata Column.

For most companies, it’s been a constant learning process as they went along with SharePoint. “I didn’t know I could do that!” is something I hear quite often during my sessions. You don’t have to be shy about it, it’s ok! It’s all part of the game.

Things are different now, there is a lot more SharePoint knowledge today than when it was first released in 2003. We know what Content Types are and the benefit it brings us to plan them properly.

Of course, this is just an example, but it shows us that we’re no longer starting from square one every time a new version is released.

Migrating to SharePoint 2013

Don’t just wrap your SharePoint 2010 with the covers of SharePoint 2013. Although many believe that not much has changed in this newest iteration, there’s enough to make a difference in your architecture.

My recommendation is to make a roadmap of your migration to SharePoint 2013 and to plan it accordingly. I will cover this in the next post in this series.

In conclusion, yes, you can use the database-attach upgrade to migrate from SharePoint 2010 to SharePoint 2013.

However, you should make sure that you are re-evaluating the architecture of your SharePoint portals, to ensure you are taking advantage of the new, or existing features that you might not be using. A migration is a great time to reorganize.

And thanks to the new SharePoint 2010 mode within SharePoint 2013, you will be able to attach your content database, then granularly migrate the content to your newly designed 2013 environment.