Blog

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

6 min read
6 min read

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.

Start planning cloud governance

Your cloud-first approach needs a cloud-first strategy. Microsoft cloud governance must mirror the modern needs of the business user it seeks to govern. It needs to be dynamic, automatic, and scalable to handle both platform growth and allow collaboration to flow without friction. Rencore Governance is the solution you need to make all of this happen.

Rencore Governance is a unique governance tool catering to businesses and enterprises of all sizes, has simple setup-and-go functionality, addresses a breadth of Microsoft services, and has extensive automation capabilities. Click the button below to learn more about our one-stop Microsoft cloud governance solution.

Try for free

Subscribe to our newsletter