Don’t Over-Build for the Cloud

Pre-migration planning with Metalogix

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]

Christian Buckley

Christian is a Microsoft Regional Director and M365 Apps & Services MVP, and an award-winning product marketer and technology evangelist, based in Silicon Slopes (Lehi), Utah. He is the Director of North American Partner Management for leading ISV Rencore (, leads content strategy for TekkiGurus, and is an advisor for both revealit.TV and WellnessWits. He hosts the monthly #CollabTalk TweetJam, the weekly #CollabTalk Podcast, and the Microsoft 365 Ask-Me-Anything (#M365AMA) series.

3 Responses

  1. I don’t think we’re in disagreement here, Marc. I constantly advise people to “know their requirements” which means have purpose, understand the business results you are trying to achieve, establish clear measurements of success so that you know whether or not what you’ve built is meeting those requirements, and adjust your tools and systems and measurements as needed to fine tune.
    What we know is that simply “turning it on” and hoping end users figure it out does not work. Neither does attempting to replicate your last intranet platform with all of its integrations and complexity, but this time out in the cloud, and assume that this strategy will work. What what has shown to work again and again is a more thoughtful approach, piloting key workloads at first, then expanding as it makes sense. And I do believe people have caught onto the idea that using native capability and configuring the OOTB features before turning to development is the right approach.
    I do believe that most organizations over-build for the simple fact that they 1) do not understand their business requirements, and 2) they fail to understand how their end users work, and what they need to be more productive. So my argument is not so much about to build or not to build, but about having an understanding of what to build before attempting to build it.

  2. Sympmarc says:

    I’m not sure that I agree with the “reduce your requirements to fit within the out-of-the-box capabilities of SharePoint” statement. Requirements are requirements. But very often, the things people see as “requirements” are more like “nice to haves” or “impress my bosses”.
    To me the key is to be realistic in deciding what your requirements are in such a way that you try to implement exactly what is going to drive improved performance in your organization. (Reduced costs can be good, too, but there’s not a lot of blood left in those turnips these days.) Taking a long hard look at what really matters in your collaboration software may lead you to a cloud deployment more easily than you might think.
    Just like any “upgrade” to SharePoint, in considering the cloud we shouldn’t view the efforts as technical move. Instead, we should be right sizing our collaboration efforts to make the performance of the people in our organization soar. Aim for innovation and excellence, not prettier logos or font sizes. Lip gloss may make us prettier, but it don’t make us smart. If the cloud can support the collaborative strategies in your organization, then get your team moving on it.