Don’t Over-Build for the Cloud

While attending the SharePoint Conference in Los Angeles a couple years back, a Microsoft executive leaving the main stage after his keynote presentation on the merits of the cloud was beleaguered by attendees with questions. One attendee could be overheard listing out the details of the breadth and scale of investments his company had made in SharePoint, and was frustrated that Microsoft would now advise them to re-architect again and move everything into the cloud. He asked the Microsoft exec what he tells customers in that situation, to which the exec replied, "Reduce your requirements."

Talking with customers, it’s not uncommon to hear this concern about moving to the cloud — the need to rebuild and re-architect solutions that were added to SharePoint on premises, but may not work as built in Office 365 and the new app model. If you think about it, much of the success of SharePoint has been because of its extensibility and adaptability, and the ability to shape it to meet a customer’s unique and specific business requirements.

However, many organizations — not all, but many — may be over-thinking their move to the cloud, and this Microsoft executive was spot-on in his advice. When presenting on SharePoint migration planning, I often connect this story to the common pitfalls of failing to properly understand current-state (how your end users are using the platform today) and future-state designs. Not properly understanding the current system (functional and operational gaps, business processes and workflows) will undoubtedly lead to over-building on your new environment. When looking at how your employees use the platform, you will likely come to the conclusion that many customizations painstakingly created to automate and simplify tasks in SharePoint to increase end user productivity may have become, in fact, outdated or unnecessary due to advances in the platform itself.

Every SharePoint migration begins as an extensive business analyst activity. What I mean by this is that prior to any system implementation or redesign, you need to seek to understand the 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 requirements, the analyst will then begin to 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.

Every customer is different, and your migration plans may be unique. Whether moving your production systems to the cloud in one fell swoop, whether it will happen gradually over time as you transition away from on premises customizations, or whether your plan is to update to SharePoint 2013 but remain completely on premises — migration is about transforming your existing system to meet operational needs. It’s as much about retooling current sites and content as it is about deploying new technology. Metalogix provides an excellent whitepaper that walks through the best practices of SharePoint migration cleanup and pre-migration activities that can help you better prepare, regardless of your intended infrastructure.

Don’t over-build your new environment. Wherever possible, reduce your requirements to fit within the out-of-the-box capabilities of SharePoint. Understand what you have to work with, have a vision for what it should look like, and work with your end users to build out the solutions that they will actually use.

[Article originally published on the Metalogix blog]