I've browsed a lot of sites explaining the PowerShell command for Install-SPSolution concerning the Compatability Level setting like the command below.

Install-SPSolution -Identity CN.SiteNav.CTs.wsp -CompatibilityLevel {14,15} -GACDeployment -force

However, not many explain why you need to do this or in what circumstances this needs to be done for things to work correctly. I have done a full upgrade in test to verify SP2010 scoped features work in both SP2010 site collections and then those site collections upgraded to SP2013 format. I realize that all of the files, like images and aspx files all reference the 14 hive, unless you mark the solution to deploy to both hives. Then when you upgrade that site collection that feature uses whatever is in the 15 hive. I've found that I can just edit the 15 hive feature files manually and fix the missing "_layouts/15/..." and my images and aspx file references come back.

I guess my question is do I really need to deploy my SP2010 solutions in Compatability Level 14 and 15 or just in 14 as it seems to work in just 14 regardless if my site collection is running in SP2010 mode or in SP2013 mode. Any clarification on the when to do this and why would be very helpful.

I have a few weeks before my main upgrade and want to deploy my SP2010 solutions correctly. We will be running in SP2010 mode for a while since it will take our users some time to adjust to the new interface. After we have completed some end user training and modified the look and feel we'll be able to upgrade the experience to SP2013 format. I just don't want that to hinder us if we decide to modify our feature code in the future.


There are only a few instances where you get any real benefit from the CompatibilityLevel having both 14 and 15. If you have a solution where you are adding ghosted files to a site, you will get health analyzer warnings that the files don't exist in the 15 HIVE if you only deploy in 14 mode. Another instance is having site definitions for both 2010 and 2013 in the same 2010 solution.

We, at NewsGator, have a large number of 2010 solutions that we install to 2013. The only case we use the CompatibilityLevel is when we have ghosted files.

  • Thanks for the answer, I really appreciate it. It's been easy to find the hows but hard to find the whys concerning this topic. Most, if not all my features are just the normal list, event handlers, and custom actions for menu and buttons. To my knowledge I don't believe we have any ghosted files that are being added to the site. However there may be ghosted files from SharePoint Designer edits in the future from editing list views or list pages like view and edit. Would this be a problem if they became ghosted while in SP2010 mode, then upgraded to SP2013 mode?
    – Patrick
    Oct 30 '13 at 14:10
  • By ghosted, I meant that the file is still referenced on the file system and hasn't been edited in designer. If that file became unghosted in 2010 and you upgraded to 2013, you won't have any issues. It knows to get it from the 14 HIVE, its just going to warn you in the health analyzer. Oct 30 '13 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.