As more organizations make plans to adopt SharePoint 2013, planning for the migration of 2010 solutions to the 2013 app model is becoming increasingly important. While many SharePoint 2010 solutions will run just fine in 2013, developers really should take the opportunity to rework solutions during the migration process to get the most out of SharePoint 2013 and get away from the full-trust model. In this post, I’ll provide a brief checklist of things to consider when migrating solutions. Answering these questions will help you have create a pathway for a successful migration.
Does the current solution utilize the server-side object model (SSOM), client-side object model (CSOM), or is it a no-code customization?
Obviously, solutions that utilize SSOM are going to need a significant rewrite to work in the new app model while CSOM code should be easier to incorporate into a new app. No-code customizations are a mixed bag that depends on exactly what you are doing. Workflows, for example, should be recreated using the new 2013 workflow model, but Business Connectivity Services (BCS) models should migrate without changes.
Does the current solution require full trust?
SharePoint 2010 solutions were deployed to the Global Assembly Cache (GAC) almost by default even if the code did not require full trust. If your solution does not require full trust, then migration to the new app model will be easier. If you do need full trust, those pieces should be reviewed to come up with a different approach or be segregated into a trusted web service.
Does the current solution use APIs or technologies that have changed significantly or are obsolete?
Beyond the obvious REST and CSOM changes, many of the workloads in SharePoint 2013 have changed completely from their 2010 counterparts. If this affects your solution, then you’ll have to rewrite that portion. Things to consider are:
· Completely new search engine makes previous solutions obsolete
· Completely new workflow model makes previous solutions obsolete
· ListData.svc is obsolete and replace by the new REST endpoint
· ASMX web services are obsolete
Is the target SharePoint 2013 environment on-premises, in the cloud, or a hybrid?
SharePoint 2013 offers more sophisticated options for deployment than SharePoint 2010. The target environment will dictate the capabilities available to your solution and how it is deployed. So you should fully understand the strengths and limitations of the target environment.
Additionally, you now have new options for development such as signing up for an O365 developer account and using Napa as a development tool.
What hosting model and design pattern should you use?
There is a lot to consider when trying to determine the best combination of hosting model and design pattern to use. I have already written about that in a previous post, which you can find in the post "App Designs in SharePoint 2013".
Do your skills need an upgrade?