Migrating SharePoint 2010 On-Premise apps to SharePoint 2010 online

This is the final segment of a four-part guest blog post by Jeremy Thake, enterprise architect and Microsoft SharePoint MVP at Avepoint — previous blogs are all live linked.

As discussed in the previous article, the promotion of SharePoint solutions from one environment to another can prove complex. To add to this complexity, when organisations decide to move from SharePoint 2010 on-premise to SharePoint 2010 online, any full trust solution packages used in the advanced tier cannot be deployed into the multi-tenant environment.

To migrate these solution packages, they need to be manually converted to a sandbox solution in Visual Studio 2010. This is as simple as changing the property in the Solution property pane, but don’t be fooled by building your solution and it compiling. It will only fail once it is deployed and executed at runtime. There is an additional CodePlex project with FXCop rules that will do this at compile time for you, as well.


In some circumstances, developers can get lucky and find that they have only used functionality within the limits of sandboxed solutions. In other cases, where they have used APIs outside of these limits or are consuming too much CPU time, developers will need to start looking at approaches to work around this. I have also worked with customers that have de-scoped functionality to get around the limitations.

There are a few key approaches to handling solutions that require functionality that is blocked when using sandboxed solutions:

• Client side code – Script blocks built within the ASPX pages can call out to external web services, which cannot be done by sandboxed managed code. The SharePoint client object model is a sub set of the server side API, consumed by JavaScript, and allows for very similar actions as what can be done via server side API.

• Azure Service Bus – For functions requiring complex calculations that would reach the limits of the resources measured in the sandboxed solution, organisations are moving these calculations to the Azure Service Bus.

• SQL Azure – In some cases, where on-premise solutions accessed SQL databases inaccessible by SharePoint 2010 online, organizations are also moving their data into the Azure cloud.

• Azure Web Application – In some cases, the user interface (UI) layer and business logic are completely pulled into an Azure application. Often, the data layer is left inside SharePoint lists and libraries. The UI of the application is then added to SharePoint 2010 as an IFRAME.

The other issue with migrations, often with large amounts of data, is the time it takes to actually do the full migration. Sometimes the initial move of all the content into SharePoint 2010 Online does not occur within the outage window available.

Organisations find themselves doing an initial migration of the bulk of the content, but then take a full outage of the production solution to do an incremental migration of the changes from when the bulk was done to present and then switch to SharePoint 2010 online solution. In this instance, third-party products are the only real viable approach.