This post is going to be a rant but I will try to keep it pithy. Maybe I can set some expectations for current and prospective O365 customers. With some luck, maybe an MS employee (a real employee) will consider this information with some perspective.
I've been helping customers since the early days of BPOS and feel that O365 is a nice product conceptually. But the 0365 product is very complex compared to BPOS and anyone trying to use Sharepoint API's or third party tools need to be aware of the fact that MS is unable to effectively support any of it.
For starters, O365 uses claims authentication which is very poorly documented in the MS dev community. Some MVP's have gone to great lengths to assist, but MS really dropped the ball on this. What took about 2 lines of code to access Sharepoint APIs in BPOS (v3) requires dozens of lines of code in O365 (v2010). So the update on any integrated systems with O365 is going to be an effort that is not identified in the transition documentation that labors on client prep and needs much more instruction on integration impact.
The real kick in the head is how the transition of Sharepoint data is placed. The BPOS sites are not transitioned to the new sharepoint.com space. The original microsoftonline.com space is retained. On the surface, this seems fine. But somebody failed to tee up a server to provide SAML tokens for the claims authentication to the old BPOS site. So programmatic access to the transitioned Sharepoint data is simply impossible after the transition. If the customer has any 3rd party integration or uses any of the API's (client object modem, REST, SOAP, etc), the transitioned data ceases to be accessible. Two weeks ago MS transitioned our BPOS and we are still down. We have become quite reliant on our Sharepoint data so the outage is becoming excruciating.
As a responsible techy, I produced a code sample that demonstrates the issue, documented the issue in a service request, and sent it off.
Now things get weird. O365 support is painfully elementary. I guess 90% of their calls must be related to browser cookies and the like, because these teams have very little knowledge about Sharepoint's technical capabilities and design. Regardless, after suffering through the triage process for two days, they finally agree that the problem is something they should "look into". Keep in mind, I've tried to raise the urgency by explaining that we are completely down. But the support guy simply fires back the platitudes and remains non-committal toward any plan for resolution.
For some reason, there is no escalation process at O365 support that considers the customer's situation. I've been a MS partner, customer, user, and contractor for over 15 years. Until recently, each product support group had a coordinator role that could route issues while you stayed on the phone, in most cases. If the targeted individual was on the phone, I was queued to that individual and my case continued within a couple of hours. With O365, everything runs at a glacial pace. The initial support folks will keep you on the phone for hours while they simply read documentation and relay simplistic instructions regarding the operating system, browser, etc. But they don't escalate. Then they log something or other and get back to you a day or two later, with more simplistic instructions on similarly unrelated components on the client side. Keep in mind, my situation had nothing to do with the client side and my initial post clearly described it. But the initial support guy has no clue about technical features inside Sharepoint so he has to muddle through his procedures at the expense of the customer.
Finally, after three days of this back and forth, I lose my patience and demand escalation. A supervisor is involved and they agree. Now the torture really starts. Allow me to paraphrase a bit: The support guy asks if I can prepare some screen shots and asks when a good time would be for him to email the request for the screen shots. OK, first, my business systems are down, why are you asking me for a convenient time to send me an email. "I need this resolved now, please tell me what you need." My request seems foreign to him, but he agrees to discuss the contents of his email request. Keep in mind, I sent him the complete steps for reproducing the problems on his internal systems. Here's what he asked for: 1) a screen shot of the domains being used in the administration portal, 2) the number of O365 licenses I have, 3) the number of O365 licenses are assigned, 4) a screen shot of the site collections according to the administration portal.
OK, reality check. I'm on the phone with Microsoft, who has sold me the subscription for O365. The guy in support is able to determine what account I have and who the administrative contacts are on my account, but can't look up how many licenses I have? How said is that? And this information he asked for has nothing to do with the issue on the table. And we are on day three since I opened the case and the issue has never been provided to anyone at Microsoft that has a clue what I'm talking about. I'm jabbing paperclips into my eyes and ears and this guy is asking how many licenses I have.
I'm on day four of this particular case and I'm told that the issue has been sent to the correct department for review, but I've not yet had a conversation with anyone capable of testing the sample I sent them. So the moral of this story is that Microsoft has, once again, created a conundrum. They built an intriguing technology stack with O365 Sharepoint in that it provides some Sharepoint Server capabilities at a Sharepoint Foundation price point. But if I were to list all of the features in O365 Sharepoint, I would suggest that they are only equipped to support about 25% of them. Cloud computing for mission critical systems is mature enough to consider. But O365 is probably not a candidate at this point. If you rely on Sharepoint, the O365 team is simply not equipped to resolve any issues of significance. And the speed at which they progress through support issues is painful; they quickly diminish the benefit of having offshore labor.
O365 offers a "professional" support contract for $12,000 per year. But I'm simply not convinced that paying the additional money would get me commensurate results. Maybe I'm wrong, but there's no way to really know. So if you are an O365 candidate or customer, please beware of what the support capabilities are, because they are very very limited.
PS: Related to the offshore labor issue, I feel compelled to contrast this issue with a story. About five years ago, I had a Sharepoint v2 issue that was rather complex and had to do with the the new .Net 3.5 framework at the time. I called support and within one hour had been case escalated to a team in Texas that actually build part of the framework and were intimate with the section of functionality that was challenging me. Within two hours the case had been identified as a defect and two courses of action prepared. First, the defect was submitted to the product group for consideration in the next hotfix. Second, a spot of code was provided that can serve as an interim solution until said hotfix was delivered. With less than 3 hours of time from Microsoft personnel my case was handled to my satisfaction. In the situation I described in this blog, I've tallied at least 9 hours of time from Microsoft personnel in India and the case hasn't even been seen by people that understand the issue. The offshore labor might be cheaper by the hour, but it doesn't make much sense if the case takes five times longer to resolve. I believe some companies are figuring this out. But there is something to be said for having an expensive resource that can churn through cases quickly versus a cheap resource that cannot. And there definitely seems to be a greater sense of urgency, even if it is contrived, from people familiar with American culture. After all, Americans don't read user manuals, have short memories, short patience, and a tenacity for beating on every problem with their favorite hammer rather than looking for the correct tool. But we do seem to get the job done quicker than most.
But, alas, I digress.