Microsoft SharePoint has been serving as a platform to collaborate for decades now. Over the years, the development paradigm has been shifting from server-side development to client-side development. The CSOM (Client Side Object Model) APIs have given the power to connect to SharePoint remotely. Also, CSOM gives the flexibility to develop the code as platform-independent.
When SharePoint was made available as part of Office 365 (soon after called SharePoint Online), we kept behind the server-side code and started developing solutions using JavaScript. JavaScript is a great language for front-end developers. For a developer, it helps to manipulate things in the browser. It may not be perfect but it works for most scenarios. The reason why we are using JavaScript is that we want it to build up some business logic on top of a web page that will occur after the delivery of the content to the browser.
However, over time, our classic SharePoint site started flooding with JavaScripts. Developers started using all possible options to add JavaScript to a SharePoint site as below.
- Refer to a JavaScript file in the master page
- Add web parts on a page (Script editor / Content editor)
- Custom action to insert the JavaScript on site
- JS Links on ListView web parts
This situation has created serious governance issues. The Modern SharePoint does not allow JavaScript to be injected on a page and it also does not have Script Editor web part available. All customizations to the modern SharePoint site have to be carried out by developing a SharePoint framework (SPFx) client-side web part or SharePoint Framework extensions. This certainly has brought the governance around the flow of JavaScript.
Now, we are gradually moving towards a Modern SharePoint which is entirely built using JavaScript and HTML. We already have developed our sites in Classic SharePoint and we have to gradually start moving from classic SharePoint to Modern SharePoint.
Modernizing the SharePoint site mainly involves the below activities.
- Maximizing the use of the modern list and library experience
- Connecting your site to Office 365 group
- Transforming your wiki and web part pages to modern pages
- Rebuilding your classic publishing portals to modern portals
Involve Everyone
Moving from classic SharePoint to modern SharePoint is a long journey. To make this journey smoother, we have to identify and educate the stakeholders.
Business Stakeholders
As we are going to develop SharePoint portals for customers, they are the key part of this journey. Help them understand the benefits of moving to modern SharePoint. Present them with the roadmap to get to the modern sites from classic sites. If feasible, setting up the replica of a smaller live production site in modern look and feel will help them visualize it better. Otherwise, set up a playground for them and help them explore the new features. This will help them to get adapted to the modern user interface.
SharePoint Developers
It is again a learning curve for SharePoint developers to get started with modern SharePoint, especially, the customization options using SharePoint framework development is a learning path.
SharePoint Administrators
Although the specialist SharePoint administrator role is fading away in Office 365, the role of an administrator here is to enable the modern experience on SharePoint sites.
Summary
SharePoint classic experience is not yet deprecated. Both the classic and modern experience co-exist. To start your journey from classic SharePoint to modern SharePoint, it is crucial to start identifying the stakeholders, educating them, and helping them adapt to the modern SharePoint.