By Dan Naselius, CorasWorks COO
In my previous blog (Microsoft’s Moving the Cheese…Understanding the New SharePoint App Model) I covered what Microsoft is doing with SharePoint 2013 and Office 365, with some focus on how and when to use the new App Model. Presuming my message was clear, you should have a good baseline of the evolving and existing terms, and an understanding of the difference between traditional farm solutions and the new High and Low Trust App Model.
In this post, we’ll talk about the impact of SharePoint 2013 on your existing apps and what we think is the best way to proceed with 2013. There are a lot of options to consider, so this blog post is pretty long. If you’re just interested in my opinion and want to skip all the detail, jump to the end of the post to see what I’m recommending.
What about my existing SharePoint apps? What happens to them and what should I do with them?
The answers to these questions truly depend on your current SharePoint implementation, as well as your future plans and objectives. So we have to ask another question: What Does Your Current SharePoint Do?
This may seem like a really silly question. Of course the answer is it stores documents and allows collaboration, but what I really mean is what and how are you really USING SharePoint? Did you simply stand up SharePoint and move your file shares into Document Libraries? Or did you brand SharePoint? Did you purchase 3rd party software like CorasWorks, Nintex, Bamboo, or AvePoint? Did you write your own web parts and application pages, workflows, etc. and build out more sophisticated solutions? The reason this is important is that the decisions you need to make, and the strategy you need to take, hinges on these answers.
Remember that when we talk about your SharePoint apps, we’re talking about three distinct elements of the app that we have to deal with: 1) content, 2) sites/customization, and 3) farm-based solutions.
Vanilla is Boring, But Easy!
Let’s assume you simply use SharePoint as a document store and didn’t really change anything else. This makes for an easy migration to 2013. You can simply migrate the content using a backup/restore method or any of the migration tools on the market. Your content moves over seamlessly and you now have a “new” SharePoint 2013 environment with a new interface (which could be confusing to your users, so get ready for the calls as to why things have changed).
Sites/SharePoint Designer Customizations
But what if you invested deeper in SharePoint 2010 or 2007 and made some customizations? This brings up a new set of questions. If you simply branded your sites with SharePoint Designer and moved web parts around on different pages, you will be presented with a unique challenge. Do I move the customizations or just the content? If you changed your sites with SharePoint Designer, you will have “unghosted” the pages (i.e., broken them away from the native site definition), so when you migrate your sites they will still look like 2010, without the new 2013 functionality. This requires upgrading the site to the new site definition (which contains the 2013 feature set), and then either sticking with the new layout or re-customizing your site. Unfortunately, there is no automated way. Microsoft requires that you re-address any customizations you made through SharePoint Designer, and reapply them to the new layout. This scenario will require some work.
If you developed custom code in visual studio and deployed it through a WSP deployment, you have what we defined as a “Farm-based Solution” (as identified in my previous Blog). This is the same if you purchased product from any of the SharePoint ISV’s that installed through a similar method. The reason is that whether you built or purchased extended capabilities, you are installing into the Global Assembly Cache (GAC) and the solution is fully trusted.
Presuming you have an on-premise implementation, this is good news. You actually have many good choices for what to do with your current investment. Microsoft has made it straightforward to migrate your application to SharePoint 2013 (on-premise). You can continue maintaining your application, and you can phase-in new functionality with the current fully trusted model…or the new App Model. Therefore, you should be comfortable continuing to use and improve that application. I will discuss this further in a future blog.
Even if you built applications using SharePoint Designer, you are still okay. Sure you will have to deal with any SharePoint Designer customizations as discussed above, but the fundamental solution is still able to function as it did in 2010. Of course, this will require the developer to do some tweaking of the solution and develop an upgrade.
However, there are reasons why Microsoft would prefer you rebuild these solutions using the new App Model. The big reason is that installing and running on front-end web servers can create instability if the component runs amuck (“fully trusted” does have limits). In addition, if you need to fix something, deploying and retracting solutions is time consuming and things can go wrong in the installation, possibly causing even more issues. Finally, fully trusted applications/solutions end up competing for resources on the web server, and can create trouble for the SharePoint Admin (so you can imagine that SharePoint Admins would love to stop installing on these servers).
Being able to have your existing solutions running in the new model initially looks like a good goal. In my opinion, it is just not realistic. Trying to recreate everything in the new App Model will require a lot of time and money and will not likely add much business value to your users. In addition, the new App Model only allows Client Side Object Model (CSOM) based solutions that may be too limiting for your needs. The best approach, in my opinion, is migrate your current fully trusted (i.e., farm-based) solutions to SharePoint 2013 and phase in the new App Model for new functionality and features.
There is one other alternative. Microsoft does support Provider Hosted Apps where the logic runs on a separate App Server. I am not crazy about this as it is another big investment without much real business justification.
The Hybrid Strategy—The Only Logical Solution
Sometimes common sense prevails, and I think the Hybrid strategy is common sense. If you’ve been investing and growing your SharePoint environment over the past decade you have way too much invested to simply throw it away. Over time you can look at moving more and more into the new App Model, but even then you should look at how much it would cost and at least consider the farm solution approach. This won’t make your SharePoint Admin do back flips, and you will probably hear from Microsoft and others that you really should be using the new approaches, but you’re running a business. Plus, there will be a whole learning curve for the entire market (ISV’s included) so it will take some time before the best options appear. If you jump on the bleeding edge you are likely to end up pretty nicked up. I believe using the various options available to you to ensure you solve your business needs while letting the ecosystem mature is a real solid business and technical strategy. In the interim, you can take advantage of the new things that are coming out and start leveraging the approach for items that are straightforward to solve using CSOM.
So what does this mean to my upgrade?
Just do a normal upgrade from 2010 to 2013, like you did from 2007 in the last cycle. You simply assume the things you ran in 2010 will be carried forward (thankfully, Microsoft has made that possible). You will need to contact any vendors you have installed because they will all have new versions that will minimize migration and implementation issues. If you wrote or acquired custom code you also might need the developer/vendor to look at anything that isn’t working properly. Then, of course, you will need to deal with any customizations.
At CorasWorks, we typically re-apply the customizations through a 2013-based Master Page that looks and feels like the current 2010 master page except for the 2013 improvements. This makes the update fairly straightforward, and the work can done by less sophisticated resources or programmatically by migration tools or even PowerShell. Once you have your servers upgraded and are back in production, you will be in a good position to decide how to best meet future requirements using either the farm-based or App Model. You now have more options than ever before and can take full advantage of 2013! You can even connect your on-premises farm to Office 365 and leverage the cloud directly for the logical workloads.
What about Office365 only?
Unfortunately the farm-based solutions cannot be moved to Office 365. So, if you are moving from an on-premises environment to Office 365 (aka SharePoint Online) you will only be able to move content. That means any customizations or business solutions will have to be completely rebuilt. While this might provide for an exciting time for your developers to use shiny new technology, it will be costly in terms of time and money, and has the potential to introduce new bugs and problems.
My recommendation is that Office 365 should be considered only for companies who mostly used SharePoint as a file share and not much else. It gives you a clean break from the past and allows you to accomplish the same thing with better options and without the Admin overhead. For companies that have invested in SharePoint-based solutions and have a lot of money and time to invest, moving directly to Office 365 may make sense. I just can’t see how. In my view, only a hybrid solution makes sense for that scenario.
In my opinion there hasn’t been enough written about these important topics around migration so I hope you find this valuable. I also look forward to hearing others’ thoughts and how people are moving forward. I’ll continue to share what we are learning about SharePoint 2013. In the next blog article I’ll talk a bit about what we at CorasWorks are doing to support our customers on 2013.
Until next time,