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?

A company, whether small or large, can find the right mix of technologies to use. As an example, our client noticed one important aspect from our discussion: they must maintain their Office licenses because they require an email system. Office 365 offers them both, Office and email, but so much more.

Even though they saw the advantage of having Office licenses and a fully Microsoft-managed email system, they realized that products like SharePoint Online, Skype for Business, and OneDrive for Business would be an almost free addition to their needs. 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 straightforward job.

The image below presents the advantages of migrating to the 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).

Migrating an application sharepoint1

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. In normal situation this 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. Perform a thorough analysis of the existing application to understand its suitability for conversion into a SharePoint Add-in and/or determine if Microsoft Azure is necessary.

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

Migrating an application sharepoint2

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.

Solution analysis

For obvious reasons, I won’t present anything from the solution we developed. Instead, I’ll provide you with 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. You’ll likely need to re-design the application, which can sometimes be an opportunity to address aspects you initially overlooked. However, when you’re already deep into the development process, it can be challenging to persuade the client to optimize a feature that’s already in use 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
    • Branding in SharePoint Online must be limited to only JavaScript and CSS. It is not recommended to modify the default master page
  • 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 you used SSRS for reports, please note that SSRS is not available yet in Office 365. If you have used SSRS for an on-premises farm, you cannot use it in SharePoint Online. You will need to find alternate ways, possibly using Excel Services and Power BI. This is not exclusive, as some third-party providers may actually provide JavaScript libraries that could help rendering reports.

Nintex Workflow Migration Challenges

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 offers several compatibility (or supportability) lists of actions that you can use to analyze the workflows and 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.

Considering all these limitations, 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 ready 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. This is because some parts just cannot be transferred as is. The best option you have is to understand how to create an equivalence for your application’s functionality in the cloud.

Final thoughts

The best source of information for this part is to use the Office 365 Patterns and Practices, provided by Microsoft. There 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. If curious and you really need this now, please have a look at Office 365 Developer Patterns and Practices.

 

 

 

Article written by Marian Mihaiu