Goodbye, SharePoint 2010 and thanks for everything

Goodbye, SharePoint 2010 and thanks for everything

Microsoft SharePoint Server 2010 and SharePoint Foundation 2010 mainstream support ends October 10, 2015. You can verify this on Microsoft’s Lifecycle page for SharePoint 2010. Weeks go by so fast nowadays, that I actually had to stop for a moment to reflect the fact that it’s been 5 years, and almost two releases since SharePoint 2010 was all the rage.

So what does this mean for a company that is still running SharePoint 2010 (Server or Foundation)? It’s not the end of the world, and your SharePoint 2010 farm will not stop on the 11th of October because of this. Microsoft is simply phasing out from mainstream support for SharePoint 2010, also in anticipation of SharePoint 2016 next year. As one might guess, starting October 10, one cannot request changes to product design and features for SharePoint 2010, and let’s face it, it would be pointless really. In addition, complimentary support through phone and online will cease but paid support will still be available. Knowledge base and other product-specific information will remain online, but content might be archived and frozen. A good example is this search result on Technet for SharePoint 2001 – there’s a lot of content available, which I’m quite surprised still exists. I still hope no-one reading this is not running SharePoint Portal Server 2001 anymore!

Even though mainstream support is ending very soon, SharePoint 2010 will keep receiving security updates as necessary. Non-security related updates or new features will not be shipped in the future, and might only be available if you purchase a Premium Support from Microsoft. I would imagine the paid option is for larger organizations, who absolutely need to support SharePoint 2010 internally for various reasons.

What should you do if you still run SharePoint 2010 in production?

Many organizations still seem to have SharePoint 2010 alive and in production. It could be a platform for a corporate intranet, a search solution, or even a platform for multiple lines of business tools. Considering SharePoint 2016 is being released during Q2/2016 (and the preview being out since late August), I’m anticipating several companies to just stick with SharePoint 2010 for now. When the time comes and SharePoint 2016 seems mature enough (the classic “wait for Service Pack 1” approach), you might migrate directly to SharePoint 2016, and skip SharePoint 2013.

Migration paths

It’s worth mentioning that a direct upgrade from SharePoint 2010 to SharePoint 2016 will probably not be possible with the traditional database attach-method. Thus, the obvious option is to first upgrade to SharePoint 2013 to buy some more time. This would be the best alternative for conservative deployments, where upgrades are done on a bi-yearly basis. It also provides more time to learn about SharePoint 2016 in the coming months, while also leaving behind a decaying platform. The downside here is that you’ll end up doing two migrations: First to SP2013, and later to SP2016. During each cycle, you need to fix a lot of issues, UI glitches, and customizations, and this is both time-consuming and expensive.

The alternative is to use third-party migration tools and in-house tooling and/or scripting to extract relevant content, structure, permissions, and other data from SharePoint 2010, and migrate it directly to SharePoint 2016 when it’s available. Several organizations I’ve spoken to are also testing migration to Office 365 and SharePoint Online. Taking this route, you could use the newly-released-for-preview SharePoint Online Migration API for bulk data uploads to the cloud. You’d still need work and tooling for everything else, such as web parts, site structure, UI changes, and other artifacts. Regardless, using the new migration API is a fairly easy way to move the bulk of the data with relatively few moving parts in the process.

The important thing is to start planning now, and not wait until SharePoint 2016 is out. That way you’ll have a reasonable window of time to figure out where to migrate (SP2013, SP2016, or SPO) how to migrate (tooling, database attach, custom solution) and at what cost.

But SharePoint 2010 runs so well!

Yes, and it’s surprisingly fast and agile considering today’s standards. The world keeps spinning, and solutions move forward. Even if you wouldn’t need a single new feature, you still need to move away from SharePoint 2010 – eventually. It might not be today but in the not-so-distant future. It might not always be a good practice upgrade to the next version, as many organizations are simply choosing to upgrade every tick, instead of every tock in the traditional tick-tock model (each tick is a major release, each tock is a minor release). While this varies a lot between different companies, I’d say it’s not necessarily a foolish approach in general.

Consider the following factors when deciding how and where to move from SharePoint 2010:

  • Current Office client version: If you’re still on Office 2010, it’s a good idea to keep parity by upgrading to Office 2016 together with SharePoint. It’s not required but helps a lot with those numerous smaller issues
  • Current Windows version: I hope no-one’s running Windows XP anymore, but upgrading from Windows 7 to Windows 10 is a popular route. Once again, this is not a requirement for SharePoint 2013, 2016 or SharePoint Online so you might need to work client OS upgrades at a different pace
  • Current customizations on SharePoint 2010: As is all too often, years have taken their toll and SharePoint 2010-based deployments are like a patchwork quilt: Full of holes, full of different pieces of work from different eras. You don’t need that in the future.
  • Current SQL Server setup and versions: If your SharePoint 2010 farm runs on older SQL Server, you’ll need to upgrade the version of SQL Server too – and depending on your licensing model, this might not be immensely cheap.

What about our custom solution X?

While the Office/SharePoint Add-in Model has been gaining a lot of traction in the past months, it’s still not something one might simply “get” in a matter of minutes. There’s a lot of great guidance available here, but the challenge often lies with the existing customizations. What’s relevant? What’s critical? Do we need to migrate everything as-is, and does it even work anymore? It’s a fact that full-trust code, with all its issues, is become a thing of the past, but we’re still standing on two platforms: one is the full-trust code with all its promises and happiness, and other is the promised land of add-in model. If you’re still on SharePoint 2010, it’s not about the destination but more about the journey.

If you’re upgrading to SharePoint 2016, there typically isn’t a huge amount of code and customizations you’d want to take with you from the old platform. Then there’s all that declarative content and functionality such as site columns, content types, and list definitions you might still need. Regardless, a thorough analysis is needed for source data to figure out what goes where in the new platform. A lift-and-shift approach where you’d just migrate everything but perform a version upgrade in-between is not going to work in the long run. You’ll just end up with a lot of legacy content, data, and customizations that are broken from the get-go. Why even upgrade, if you don’t want to fix the issues?

Can I run two SharePoint farms side by side?

Yes, it’s perfectly possible. It will be confusing for the users if they still can access the old portal and they’ll get a new portal with different content. A better approach, if you absolutely have to have a long overlap during the transformation, is to set the old SharePoint 2010 environment to read-only and crawl content with the new platform. This way users will still be able to find and access old content while continuing working within the new farm.

I’ve seen deployments where a legacy SharePoint is still referred to as the “old intranet”, while the new one is the “work in progress” platform. It kind of works, but it’s a hassle. You’ll still need to maintain and patch two different farms, of which one is now out of mainstream support and will for certain cause headaches down the road. Typically on a weekend.

If you can, avoid having to run the old farm for longer periods of time. This way you can concentrate on one platform, and not having to support multiple versions of SharePoint at the same time. Also, it’s a great idea NOT to share services or build integrations between SharePoint 2010 and the new farm. It adds unnecessary complexity and will probably break at the worst time possible.

Can’t we just freeze SharePoint 2010 and come back to this issue in a few years’ time?

Yes – yes, you can. But can you also freeze Windows client OS upgrades, Office suite upgrades, and SQL Server upgrades? What then when you need to upgrade any legacy customizations for new business requirements, and you end up with +10-year-old code within your SharePoint farm? It’s going to be fairly challenging to find people with know-how and interest to keep fixing old .NET code and SharePoint Designer 2007/2010 horror kludges. I realize it’s not as simple as just “go with the latest and greatest”, but that’s why it’s all the more important to make a good decision now and start planning ahead for the coming year or two.

It’s only 5 years when most SharePoint 2010 deployments were initially deployed, and now they are closing end-of-life. So many people have commented to me, over the years, that the pace of new releases and features is simply too fast. In a way, it is, but the release cadence of 2-3 years is fairly lax considering today’s standards with cloud-based services. It’s not about upgrading to the latest, but about not being stranded on a deserted and decaying platform. With Windows XP that was probably a fair decision for many organizations, but with SharePoint, there’s so much data that it’s imperative to stay awake and figure out a proper plan.

In closing

Don’t panic. You can do it! I’d love to hear your approaches over at Twitter.