For those organizations making the tough decision on when and how to move to SharePoint 2016, and who are not yet spending a single waking moment on planning for SharePoint 2019, don’t worry – you have a little bit of time. No matter what “flavor” of SharePoint you support, it is important that you think about what has been built to date, what 3rd party solutions you have in place, how many workflows and forms you’ve built, and whether you test and try to move all of these things – or to simply start from scratch, move your content, and extend your environment from there.
Are you thinking about planning a migration project? Check out Rencore’s migration best practice checklist.
SharePoint’s rich history has shown us that, if anything, CIOs and their SharePoint administrators have many options for how they design their platforms and build out environments to best meet the needs of the business. As Tony Byrne from the analyst group Real Story Group describes, we can “extend SharePoint, supplement it, or complement it.” All of these possibilities give CIOs and their SharePoint administrators options and flexibility in how they design their platforms, allowing them to focus on the unique needs of their business.
Assessing what you have in place today
Many organizations are struggling with their strategies for moving forward. My advice? Don’t move forward until you understand your business needs, what the various platform options can (and cannot) provide. All versions are not equal, and what it will cost (hardware, software, people, ongoing management, risk) to get there. I often refer to this kind of decision as “Project Management 101,” because it is pretty much the same analysis and risk assessment you should give to any project.
A common question that I hear from customers is “When is the right time to configure, and when should I customize SharePoint?” Well, there really aren’t any best practices, per se. What is a best practice for one organization may not be the best path forward for others.
As a guest author here on the Rencore site, they may not entirely agree with my definition, but I define “configure” as taking an out of the box component (list, library, web part) and modifying its various settings and attributes, including adding things like columns, fields, metadata, and so forth. All of it is done within the supported “framework” of SharePoint, and should be, by definition, supported by Microsoft and scalable/upgradable to the next version.
On the other hand, I define “customize” as modifying SharePoint beyond the settings and attributes. Even if these customizations are built within Microsoft’s prescribed framework, these customizations could make the site difficult or impossible to scale/upgrade, and have been known to cause support issues with Microsoft. I’m not trying to make the customization path sound overly negative – many customizations are well-built and do not cause problems inside of SharePoint.
More importantly, customizations are necessary to help your organization meet its operational vision for SharePoint, and to deliver a platform that meets business requirements. But SharePoint development does not equal .Net development, and I cannot emphasize enough the strategy of first understanding what is possible out of the box, before customizing. If your business requirements cannot be achieved through configuration changes, the next question is often “can we build or buy the solution we need?”
There is plenty of online documentation around specific configurations and customizations, as well as guidance for developing your own. There is much you can learn from Microsoft, as well as the partner and customer community. Prior to any system implementation or redesign, you need to seek to understand your environment goals and purpose:
- What works in the current design?
- What doesn’t work?
- What are the organizational “must have” requirements and priorities?
- What are the “nice to have” features?
- What is the goal of the project?
- What are the key use cases that drive how the environment is used?
Based on these points, you should model out the “to be” or future-state of the environment. How can you design your new environment if you don’t have a clear picture of what people do, and how they do it, within your current environment? Failure to understand the present leads to mistakes in the future.
Should I customize SharePoint?
At the end of the day, if the business value of customizing SharePoint exceeds the cost of support and future upgrades for that customization, then by all means customize and deliver the right business value to your customer or end users.
But if your strategy is to build a system that can be readily upgraded in a year or more, it probably makes sense to avoid customizations and try to leverage all of the features of the out-of-the-box experience.
As you begin to think about future SharePoint upgrades and moving into the cloud, remember to reach out to the expert community and partner ecosystem to learn from them, ask questions, and test out their solutions. When it comes to customizations, you should only move to the latest version when it makes sense for your business to do so and you fully understand the time and effort required to replace, rebuild, or transform your customizations.
If your organization benefits from a customized SharePoint platform, Rencore has the software tools to help govern, secure and migrate your customizations. Click the button below to find out more!
