One of the often touted virtues of Software as a Service delivered via the Cloud is always having the latest release of whatever you may be using. That does sound pretty cool… I mean, who wouldn’t want the latest and greatest? Not only are you getting all the cool new features, but you are also getting bug fixes, security updates, speed enhancements, and there’s one more… uh gimme a sec… oh yeah… all your stuff broken. If you ask any IT professional working for a mid to enterprise sized business what he fears most about cloud, a frequent answer is “upgrade control”.
Over the next few months your SharePoint starts humming and you can’t believe you ever ran your business without it. You start telling all your associates, clients, friends, your mom, your neighbors how smart you were to have made the move to SharePoint and how well you guided the deployment and they all look at you like you are the smartest person in the world.
You come into work one day and see a notice that Microsoft is about to launch one of the updates that they promised would now start arriving at a pretty good clip. You are giddy with anticipation about new features you can add to your mix so, as soon as you are able, you push the button to upgrade and Wham, your world comes to an end. Suddenly nothing works. Your employees are blasting you emails about their inability to work. Your developer says “I’ll look into it”. You start thinking “How could Microsoft have screwed me over so badly?”, SharePoint sucks, this is a disaster! Finally your developer gets back to you with great news, it can all be fixed and it will only take a few weeks and a 5 figure change-order.
“Wow, SharePoint really sucks.”
Could the above scenario really happen? It can, and it does. Does SharePoint really suck? Nope, it is still the incredible tool you thought it was last week. So what went wrong? Your developer grabbed the wrong toolbox.
“No way, my developer has been working on SharePoint projects forever, this is clearly Microsoft’s fault.” No, it isn’t, it is you and your developer’s fault for not understanding the nuances of the cloud. The biggest nuance being continuous updating. Back in the old days, last year, things were a lot different. Before SharePoint went online (and the same can be said for Dynamics CRM Online), if you wanted to utilize either of these technologies, you bought a server, or rented a hosted one, installed SharePoint or Dynamics CRM onto this server on-premise, deployed it, and it would sit there and run forever. When upgrades became available, it was pretty easy to say “If it ain’t broke, don’t fix it” and stand pat. You could scab on all the custom code you wanted. If you did consider an upgrade, after getting a price to rejigger all the custom code, you quickly rationalized that old, but reliable, was the better choice. And you could do that. You could literally drive that SharePoint car until the wheels fell off. Not so in the cloud.
Like it or not, you will be upgraded, and on a fairly regular basis. After spending all that money to fix everything last time, pushing that upgrade button is gonna feel like the President might as his finger hovers over the Armageddon button. “Is this gonna blow up my world again?” So you decide “I just won’t push it”. Unfortunately the upgrade is inevitable, Microsoft has just given you a little bit of ability to delay it for a short while so you can pay your developer a buttload of money to make sure everything will work when your forced upgrade happens.
You must respect the SharePoint
Screw it, I’ll just go on-premise and keep control
Moving in the opposite direction of the rest of the world, is also known as going backwards. There is a reason cloud is so popular, actually several. Not the least of which is cost.
This does not account for the initial costs of hardware, licenses and configuration just to get you to the point where SharePoint Online starts.
SharePoint Online may be the second most important product Microsoft has built for your business after Windows.
Properly deployed, SharePoint Online WILL revolutionize your business. You must thoroughly understand, and respect the SharePoint Online toolbox, and only reach for custom foreign code when you find yourself in a business critical “Can’t get there from here” position. Assume that any foreign code introduced will break on updates, and be prepared for the time and expense of tweaking or completely re-writing it. If you minimize, or eliminate foreign code, your life with SharePoint Online can be blissful. Ask your prospective developer about how they approach customizing SharePoint and if their knee-jerk response is to pull out their foreign code toolbox, run the other way.