Sharepoint 2007 integrating


  • Hello,

    we were discussing using sharepoint for our workflows and document management system. Then there was an objection from a member claiming that since Microsoft has implemented Sharepoint 2016, the code implementation somenone has made with Sharepoint 2007 is unusable and must be reimplemented.

    I tried to research this charge and found out that the server someone had in Sharepoint Server 2007 can be upgraded in Sharepoint Server 2013 and then in Sharepoint Server 2016. But I don't know if this also true regarding the source code someone has programmed in Sharepoint 2007 whether this source code also works with Sharepoint 2013 and more important with Sharepoint 2016 completely.

    So I wanted to ask the community, if there are problems upgrading from Sharepoint 2007 to Sharepoint 2016 in the source code and the Server? Is the statement claiming that the source code implemented for Sharepoint 2007 is unusable for Sharepoint 2016 even partially true?

    I would be really thankful for factual arguments, because this is an important issue for us deciding to use Sharepoint or not. 

    Thursday, November 9, 2017 11:02 AM

All replies

  • Hi,

    If you are referring to custom code written in .Net, then the code will break. There has been huge update from SharePoint 2007 to SharePoint 2016. The whole concept of SSP has been changed to Service Applications. Upgrade from SharePoint 2013 to SharePoint 2016 is minimal and bug free. But upgrade from SharePoint 2007 to SharePoint is huge. Additionally you have to upgrade the .Net framework and SharePoint API to make your .Net code work on latest version of SharePoint 2016.

    Process for upgrading SharePoint 2007 to SharePoint 2016:

    1. Upgrade from SharePoint 2007 to SharePoint 2010
    2. Upgrade from SharePoint 2010 to SharePoint 2013
    3. Upgrade from SharePoint 2013 to SharePoint 2016

    Please let me know if you have any additional questions.

    Please mark this as answers if this is helpful.


    Thursday, November 9, 2017 2:09 PM
  • Thanks for the reply. My main question is:

    What have the people done to overcome this big change from SSP to Service Applications when they did want to upgrade. We know that Sharepoint 2007 has reached its Out of Life status and is not supported by MS anymore?

    Does that mean that all the code that was implemented for Sharepoint 2007 out there had to be reimplemeted to fit Service Applications? Has anyone done this? How much effort was that? 

    Thursday, November 9, 2017 4:17 PM
  • Yes, all code need to be re-implemented, you can check below MS article "SharePoint 2007 migration options to consider"


    Prasad Tandel

    Thursday, November 9, 2017 4:50 PM
  • Hi MbProgstar- it really depends on what type of code and where/how it's used. You'll find that some will work, others won't. You'll probably run into some necessary code changes when you go from '10 to '13, but before and after that, there shouldn't be any issues. As far as workflows, they should migrate well. In my experience, necessary code tweaks have been minor, but we're also not code heavy in our environment.

    cameron rautmann

    Thursday, November 9, 2017 6:16 PM
  • Hi,

    I was involved in about more than 10 projects for upgrading SharePoint 2007 to SharePoint 2010/SharePoint 2013.

    The effort required to upgrade can be minimal to huge. Minimal if you don't have custom code, huge when you have custom code. The simplest way to upgrade would be to first work on the Out of box features and then work on custom code.

    Another suggestion, instead of keeping the custom code in .Net, you would should plan to rewrite the code in CSOM/SharePoint Framework. If down the line you plan to upgrade to SharePoint Online, then it would not be huge upgrade. Migrating the code to CSOM/SharePoint Framework will be substantial upgrade, but this will reduce effort for future upgrades.

    Please let me know if you have additional questions.


    Saturday, November 11, 2017 6:12 AM
  • Suggest that you test the upgrades and also employ compatibility modes in 2010, 2013 and 2016 to see if these will work for your custom solutions.  Setup temp 2010, 2013 and 2016 farms and test.
    Saturday, November 11, 2017 7:54 PM

  • I was involved in about more than 10 projects for upgrading SharePoint 2007 to SharePoint 2010/SharePoint 2013.

    The effort required to upgrade can be minimal to huge. Minimal if you don't have custom code, huge when you have custom code. The simplest way to upgrade would be to first work on the Out of box features and then work on custom code.

    Thanks for the info. I am wondering why Microsoft makes such kind of an update, where the custom code becomes unusable. So what do the big companies do when they have a lot of custom code? Writing the code again for the new version of Sharepoint? Thus, wouldn't it be a risk factor to invest in Sharepoint when you know that you need a lot of custom code for your company, but your current version of Sharepoint will reach its end of life in 10 years and a high risk exists that in the new version of SP your code is unusable?

    If we invest hundreds or thousands of hours to write custom code for SharePoint, can someone guarantee that we don't need to invest again hundreds or thousands of hours to rewrite them again after 5 or 10 years?

    • Edited by MbProgstar Monday, November 13, 2017 8:41 AM
    Monday, November 13, 2017 8:39 AM
  • SharePoint is meant to be used straight out of the box. It's really not designed for custom code or modifications with SharePoint Designer (one of the reasons why I'm sure Microsoft got rid of the what-you-see is-what-you-get function with it in '13).

    Regardless, many add customizations because it can be very helpful. However, if you go down that road, then you have to expect you'll need to update that code eventually. That's why we use very minimal customizations, unless the business value outweighs the maintenance.

    To sum up: you have to deal with the consequences. Yes, you rewrite the code when upgrading. And, yes, you'll probably have to rewrite it again if you make another upgrade.

    A big question to ask yourself while you're in transition is, "is this code necessary or just helpful/cool?" If it doesn't provide a clear business case to use it, get rid of it.

    cameron rautmann

    Monday, November 13, 2017 1:05 PM
  • My personal experience has been that SharePoint seems to be widely used as a development platform.  For example, the National Institute of Health uses various SharePoint instances for significant automation platform customizations.  Hospitals use SharePoint as a convenient platform that combines the features of an ECM with .NET customization for automated workflows.  I am currently working with a team of developers at another government organization to migrate a  SharePoint instance that uses a heavily customized site collection used for action task tracking and notification and that has a heavily customized  front end.  This customized site collection was previously upgraded from 2010 to 2013 without issue, even though it employed both farm scope and site collection scope custom solutions.  For other customers, I myself have developed various jQuery and jScript customizations to harvest, analyze and visualize SharePoint data in custom ways. I've also developed integration with third party applications such as ArcGIS, Tableau and others.  The best thing to do is to explore the migration through testing.  Deploy test farms and perform the migration of the customizations and monitor how they perform.  Also test compatibility modes.

    Monday, November 13, 2017 4:57 PM
  • Thanks @Stephan Bren for the answer. As you have told you have wide experience with sharepoint solution with customized code and have upgraded such a solution from 2010 to 2013. As stated before there have been a big upgrade from 2010 to 2013 using Service Applications instead of SSP. So how have solved that issue? Have u used SSP in your SP 2010 solution? If so, have implemented the whole code again? How much time have you had to invest to solve this issue? 

    How was is with the other upgrades? Have you ever had the case that because of wide customization code, you have to reimplement the whole code again?

    Tuesday, November 14, 2017 7:58 PM
  • My bad, I was not thinking of the old SSP model used by 2007 - it's been too long.  The customized 2010 site collection we had was upgraded to 2013, along with some farm and site collection scope solutions that it needed, then testing was performed, and we found that it continued to function normally.  We did not need to make any changes to either the site collection or the installed solution code.  Granted, these were not originally developed using the old 2007 model - they were developed on 2010, and so the change from 2010 to 2013 was not as significant as migrating from 2007 to 2010.  It's my understanding that the SA model is significantly different from the SSP model used in 2007.

    Let me ask our developers on staff what their thoughts are on this, and I will report back to this thread.  This is a good discussion topic to share with the community and I'm curious myself.

    Wednesday, November 15, 2017 4:34 AM
  • The word is from our senior SharePoint developer that some minor fixes need to be made to code originally developed for 2007 but being migrated to 2010, 2013, but that all server-side code should work.  In fact, server-side code is the same.  Some new things were added in going from 2007 to 2010, 2013, but everything else is mostly the same.  A major change was that PowerShell was introduced in 2010.  In 2007, one sometimes had to develop web parts for things that can now be done on the fly with PowerShell.
    Tuesday, November 28, 2017 2:21 PM