In my previous article, I started talking about Office 365 as the new Software as a Service platform built by Microsoft and I mentioned SharePoint as being one of the important offerings of the platform. Recently, in a discussion with one of our clients, the main topic of the discussion was the migration of the existing application (of course, built in SharePoint 2010 on-premises, by Evozon) to the new platform, in the cloud. For this purpose, we have performed an analysis to see how a SharePoint-centered application with a number of Nintex workflows would be migrated to Office 365.
I will present a number of points we have followed in our study, in the following sections. This may be a useful start for everyone trying to migrate their applications from on-premises to cloud.
The main driving idea to perform this migration is the cost reduction. To look again at the on-premises SharePoint 2010 platform, we see a number of cost related factors that influence the decision to migrate:
- 3 on-premises SharePoint platforms to be maintained: Development, Integration of Staging and Production.
- Over 60 SharePoint applications, build over time by different development teams following various development standards
- The cost of maintaining these applications
- The cost of hardware and software licenses
- The cost of backing-up these farms
- The cost of maintaining these farms updated and fully patched
Which of these costs are still relevant to the cloud environment? First of all, a company, be it small business or large enterprise, can find the right mix of technologies they would like to use. As an example, from the discussion with our client, they noticed one important aspect: they are required to maintain their Office licenses, they need an email system. Office 365 offers them both, Office and email, but so much more. As such, even they have seen the advantage of having the office licenses then a fully Microsoft managed email system, they realized that products like SharePoint Online, Skype for Business and OneDrive for Business will be an almost free addition to what they require. The SharePoint environment is maintained at present by an important team of SharePoint Administrators, working in shifts to cover the globe 24 by 7. And, there is not just one environment for Production, there are three, each with its specific purpose.
With the cloud environment, Microsoft provides the maintenance of the SharePoint environments, the maintenance of the email system, plus Skype and OneDrive, in the cost of the licenses. These environments will be regularly patched, always at the latest versions, backed up by the Microsoft support team. Our client does not need to take into account these activities anymore and this is a very compelling argument to migrate their SharePoint applications.
However, migrating an application built for on-premises SharePoint Server 2010 is not always a straight forward job.
The advantages to migrate to cloud and the principles that will drive the transformation of applications from the on-premises model (or Full Trust Code) to the cloud model (or SharePoint Add-Ins model) are presented in the image below.
For an IT Professional, the Office 365 platform is scalable and allows an agile and faster deployment, where the release process still remains controlled by the client.
For a developer, they will benefit from a number of new Open APIs and will be able to realize applications where responsive UI is critically important, accessible cross-device, with Social networking elements and using a secure platform.
To jump now into the actual migration, let’s see some elements in analyzing whether an application can be migrated to the cloud, or not, and if possible to migrate, let’s see if only Office 365 can be considered sufficient or we also need to include elements of the Azure platform.
Current environment, challenges
The first activity is to analyze the current environment and identify all the possible challenges you may have during the migration process. Some of the challenges that our team faced were:
- Application was developed as full trust solution. This was basically the only development model that was acceptable for our client. In their environment, SharePoint Designer was not permitted to be used, as well as sandbox solutions which were prohibited. However, deploying full trust code in their environment was a very long deployment process which had to be very well documented and a very strict workflow had to be followed, which in normal situation would mean that a solution would go through Development, Staging and Production is approximately one month if the solution was bug free.
- Another challenge was that the deployment had to be scheduled well in advance, as deployments to Production can only be performed during specific maintenance windows
- The Outsourcing team must provide deployment guides for each deployment, very well and also very exact documenting the deployments
Recommending Architecture for the cloud
When recommending a future architecture, you need to take into consideration all the options you have as well as the new development standards for cloud applications. Office 365, comes with a new concept, already mentioned in the previous article, or Office Add-ins and SharePoint Add-ins. A thorough analysis of the existing application must be performed to understand its suitability to be converted to a SharePoint Add-in and/or if Microsoft Azure is required.
But, first, what this SP App / SP Add-in model is? As mentioned before in my previous article, a SharePoint Add-in will not have any elements that would require full-trust. This (FTC) is not possible in the cloud environment as this will contain a huge number of tenants using the same servers. In this environment a full trust code used by one tenant could potentially affect other tenants working on the same infrastructure. Below is a comparison between FTC and SP Add-in I found on the Office 365 Patterns and Practices.
Full Trust Solutions vs SP App model / SP Add-in model
As you can see, a SharePoint Add-In will not run on the server, all operations will be executed outside the server (or on the client computer – browser).
Just by following the image above, the first conclusion is: No Full Trust code is possible on the Office 365 platform. However, there is another problem: not all application components can be converted to a SharePoint Add-in equivalent. Later in the article I will explain what this actually means for our solution.
For obvious reasons, I am not going to present anything from the solution we developed but will try to offer you a number of hints on what to look for when performing a similar analysis.
An important part is to split the application in manageable parts. Sometime, a migration, or a conversion of an application written for on-premises, may actually have to be re-written for Office 365 or cloud in general. You cannot expect that there are tools that will analyze your application and will write the compatible code for you. Most probably you will have to re-design the application, which sometimes, can actually be a good opportunity to look at aspects you initially missed to observe, then you observed but being already on the full development process, it is hard to convince the client that a feature could actually be optimized when the feature is already used by thousands of users.
So, take this phase as a good opportunity to perform a good retrospective of the application. Also, make sure, you start understanding the limitations of the new platform where you want to migrate the application to. Office 365 comes with a number of limitations that on-premises may not exist, or if still exist, some of them could be configurable.
Limitation of the SharePoint Online platform
In this section, let’s look at some of the limitations of the SharePoint Online platform, part of the Enterprise Office 365 licensing.
- SP Online eliminates the concept of web applications. A tenant will only have access to a number of site collections and these internal or private sites will be the top level sites for a tenant.
- Missing managed paths. Not having web applications, we will not have managed paths. However, there is a pre-configured path to use, such as /sites/.
- All additional site collections will be created under /sites/ area.
- There is no public facing site anymore
- Lists and library limits: the 5000 items throttling limit is now enforced and is not configurable. Even though the default value for on-premises was still 5000 items, this could be modified by a SharePoint Administrator to a higher value, if required
- Page limits: you can add up to 25 web parts to a single wiki or web page
- Development limitations: Missing full trust solutions. Solutions cannot be deployed at farm level; this level is not accessible anymore to clients / tenants. Maximum privilege level is Site Collection level. This means:
- No access to physical assets / files unless living in the site collection itself
- Whole development and access to the lists and libraries must be performed through the API
- Whole development should be performed client-side if the desire is to locate the app on SharePoint Online
- If server site is still required, then deploy the app as provider hosted in Windows Azure.
- There are no timer jobs in Office 365
- There are no event receivers in SharePoint Online
- Site collection hard limit for database content is 100GB
- Missing Central Administrator. Instead, you are provided with a SharePoint Admin Center at tenant level.
If your application also uses Nintex workflows, it is very important to understand that Nintex provides now a cloud version Nintex Online, or Nintex 365. However, even though there are a number of tools that pretend to convert Nintex Workflows to the cloud version, you need to understand that there are some limitations. In our experience, probably 60% of our complex workflows could be directly converted, having a one-to-one equivalence between on-premises and cloud versions. For an additional 25%, we could have a partial conversion or partial supportability and some adaptations would be necessary. However, 15% of the Nintex actions could not be found on the cloud version and a full workaround must be found.
Nintex provides a number of compatibility (or supportability) lists of actions that could be used to analyze the workflows and help estimate the work required to create workarounds for missing actions.
Please note that on the cloud version, you will also miss the Inline Functions and the User Defined Actions.
Having all these limitations taken into account, we can now focus on providing some directions on the migration process.
First, let’s look at content migration. You have a number of Lists and Libraries with their content data to be migrated. In most cases, I would be looking at third party solutions that would perform this operation for you, such as Sharegate or Metalogix. These tools will probably solve most of your issues. But be prepared, some migrations may be just too complex for these tools to resolve, so be prepared to use Powershell to construct your own migration scripts.
When migrating the application, as already mentioned, you may have to build partially or completely the application from scratch, because some parts just cannot be transferred as is. For this, the best option you have is to understand how to create an equivalence for your application’s functionality in the cloud.
The best source of information for this part is to use the Office 365 Patterns and Practices, provided by Microsoft, where you will find various scenarios or patterns you can use and when can you simply use a SharePoint hosted SP Add-in or when to use a Provider hosted SP Add-in.
As mentioned before, SharePoint timer jobs and Event Receivers do not have a direct equivalence in SharePoint Online. These will be deployed in SharePoint 2010 and 2013 on-premises as full trust solutions.
How will you then recreate this functionality in the cloud? … This in a future article, but if curious and you really need this now, please have a look at Office 365 Developer Patterns and Practices.