Know what you know and know what you don’t know – never confuse the two

So, you decided to jump to SharePoint Online. You have realized that although SharePoint On-Premises is an amazing product with great functionality, the level of integration for tools and products with SharePoint Online is really a step up.

Microsoft Flow, PowerApps, Azure Functions, they’re all there for you to use, and they integrate brilliantly. Sizing your farm? Not something that should keep you busy. Backups? The Same. Version updates? Not an issue anymore. All in all: moving to the cloud has never been more interesting than it is today.

I hear you say: but I have invested heavily and customized my on-premises farm, will that move over?

Check out our free whitepaper. It’s a best practice guide towards Customization Migration, Modernization and Transformation.

Try our free whitepaper

Will my customizations move over?

Yes and no. There are several things you must think about when moving to the cloud.

  1. Identities: you will have to move the on-premises Active Directory identities over to the cloud. There are several ways to do that, but this is not what I’m focusing on in this post. It’s nevertheless an important topic.
  2. The customizations: that’s what we will be talking about here.
  3. The data itself: You most likely have thousands of documents, list items, etc. possibly hidden away nicely in lots of site collections and subsites. I recommend you look into tooling to move those over. There are several 3rd party vendors out there that have products for that, including Microsoft themselves.

Complex Customizations

Now we address customizations. They are complex to move over for various reasons. Let’s dive into a few of those possible reasons that can affect you:

Hard-coded on-premises customizations

Many customizations were built at a time when SharePoint Online didn’t exist, or it existed, but it was completely out of scope. The customizations were designed and built to run basically on one platform: SharePoint On-Premises. The code runs as full-trust (event receivers, timerjobs, webparts), the artifacts make use of specific service applications or are based on soon to be deprecated technology, like InfoPath.

Typical mistakes that developers make is hardcoding URLs in the customizations “Seriously, the URL will -always- be http://intranet…”, or they do maintenance tasks using timerjobs. While the use of timerjobs in an on-premises environment is totally valid, they simply won’t work anymore in the cloud.

Outdated provisioning

There are basically 3 ways to provision customizations in an on-premises environment:

  1. Site Definitions
  2. Web Templates
  3. Manual / coded provisioning

Take site definitions: complex to build, complex to maintain (updating them requires you to restart your servers), complex to debug. While for a long time they were the only way to provision customizations to SharePoint, one can state today that the site definition technology is outdated. The challenges they bring outweigh in my opinion the possible functionality you gain.

Web Templates: conceptually nice but flawed in its use. What if the site definition that the web template was based upon is changing during a server upgrade? Your web template changes too, and you have no guarantee it still works. E.g. every update cycle will have to test your web template.

Manual / coded provisioning: complex to maintain but flexible in its use. If the API does not change, your provisioning code will work. However, if it’s based upon the Server-Side Object Model, you have a challenge, as you cannot run that code on SharePoint Online. If it’s based on the Client-Side Object Model, your Transformation task can be potentially easy: you point the ClientContext to a different URL.

What will I move over?

To answer this question, I will have to ask you another question first: do you know what has been customized on your farm? And if those customizations are being used? I’m guessing that your answer will be: “Well, sort of…”.

Do you know the location of every workflow in your farm? And if you do: do you know what they do? Are you aware of all the InfoPath forms in your farm? What about all the present event receivers – are you aware of them?

SPTransformator is a product from Rencore that can help you answer that question. It will run an inventory of your farm and subsequently it will analyze that inventory. It will show you all the workflows present in your farm, and it will even render them! E.g. you can look at the workflows without the need to launch SharePoint Designer and locate the workflow in a site.

Try SPTransfomator Now!

SPTransformator also analyzes InfoPath forms: Where they are located, and moreover, what they contain. We will discover InfoPath forms, and we will, just like the workflows, render them in SPTransformator. No need to install InfoPath designer. You will see the form, the fields and even custom code behind the form if present.

And last but not least: SPTransformator actually tells if an artifact is actually being used. For instance, it will tell you per content type how many items have been found using that content type and it will tell you where the content type is used (which webs) too.

Embrace your new toolset

The architecture of your customizations will change. Things that you take for granted on-premises are not available in SharePoint Online anymore or are present in other forms. Embrace your new toolset. Look at the possibilities: Microsoft Flow instead of Workflows. Microsoft PowerApps instead of InfoPath. Azure Functions instead of timerjobs. You will have so many other possibilities, and each of them so much more powerful than the on-premises counterparts that it will be not smart to simply ignore them and stick within the framework of just SharePoint. It’s there for you to use. Use it.

For instance, would you like to build up a list of tweets done with a certain tag? You can with Microsoft Flow. It can be triggered by a tweet, where the flow then adds an item to a SharePoint list. And all that can be achieved without writing a single line of code.

 How will I move over?

There is no such thing as a one-to-one transformation from On-Premises to the cloud.

Repeat after me: plan, plan, plan. Plan your transition. Plan your rewrite of customizations, plan your redesign of your architecture, plan your data movement. It will be quite some work. But it will pay back in the end. You will very likely break up your monolithic solutions into separate components, each making use of a tool, product or component in Office 365. This will make them more robust, more scalable, and more future proof.

In order for you to be able to plan, again, the question: Do you know what has been customized? Needs to be answered. Of course, you can take your time, and with a mouse and a web browser, click around on your farm. And hopefully you will find everything. But there is no guarantee you will. SPTransformator takes that boring, long running job out of your hands. It runs the inventory, it runs the analysis and presents you with an easy to use report and planning interface that can help you get up and running in hours!

Sound interesting? Download SPTransformator today!

Try for free

About the author

Erwin is a Microsoft MVP, Microsoft Certified Master, and Microsoft Certified Solutions Master and works at Rencore. He is the product manager for SPTransformator, helping customers to successfully migrate from on-premises solutions and traditional solution packages to the new add-in model for SharePoint. Erwin is a core member of the SharePoint Patterns and Practices team (https://dev.office.com/patterns-and-practices) helping developers worldwide with code samples, scenarios, solutions, and guidance to successfully implement customizations for SharePoint and SharePoint Online. Erwin is speaking regularly at SharePoint conferences around the world, like Ignite 2015, and is one of the organizers of SharePoint Saturday Stockholm, the largest SharePoint focused conference in Scandinavia.