SAP has purchased Coghead’s intellectual property assets…SAP did not assume any of Coghead’s customer relationships or obligations and, at this point in time, SAP does not have plans to continue offering the Coghead service commercially…Infoweek:
"Customers can take the XML out that describes their application, but the reality is that only runs on Coghead, so customers will need to rewrite their app with something different,"Hoff:
“It's a friendly reminder that "whens you rolls da dice, you takes your chances." Prudent and pragmatic risk assessment and relevant business decisions still have to be made when you decide to place your bets on a startup. Just because you move to the Cloud doesn't mean you stop employing pragmatic common sense. I hope these customers have a Plan B."Rich Miller:
"Now, what this DOES emphasize is the importance of standards (de facto or de jure) by which interoperability or portability can be assured. Remember... the fear of "cloud vendor lock-in" doesn't only apply to that scenario in which the vendor has captured the customer and is "extorting" unreasonable fees. Lock-in also applies to being hand-cuffed to a boat anchor with no ship to prevent it (and the customer) from sinking into the depths. It argues for minimum sufficient means by which a customer can be assured of a migration path... not necessarily a cost-free, frictionless move from one platform to another, but an assurance of salvagability at a cost that's significantly less than a 100% do-over."(emphasis is mine)
Janke:
You've bet the farm, your career, your bosses career on a technology, vendor or cloud provider. Assume the technology, vendor or cloud provider fails. What is your exit strategy? There is a clear case here for standards. The closer you are to something that is standardized and/or multi-vendor, the better off you'll be when things go bad.
I've had one really bad experience with a propriety technology (document management) that went bad. The vendor (DEC) sold off the application as they were gasping for air in the early 90's. The company that they sold it to disappeared. The documents (that now had no paper backups) existed only in the depths of a proprietary format, accessible only from hardware and software that was no longer available, built by a company that no longer existed. And the retirement incomes of thousands of faculty depended on those documents. That sucked. Finding a former employee of DEC who new enough about the software to write a custom program to convert thousands of proprietary formatted documents into a format readable by something non-proprietary was difficult. Paying that person, who was very aware of the difficultly of our situation and probably rather bitter about the whole layoff/unemployment thing, was expensive.
I'm in a relatively stable organization and I tend to stick around long enough to clean up any messes that I make, so for me, having at least a rough idea of an exit strategy makes jumping in with both feet much easier. If there is a failure, at least we have an idea how to salvage the project or technology at a cost less than '100% do-over'.
My guess is that if I were a in startup, where failure means you shut down the startup and pop up another, or if career-wise I were a jumper (new job every few years), I'd have a different attitude. In that case, “Damn the torpedoes! Four bells. Captain Drayton, go ahead! Jouett, full speed”
In this particular case, the abandoned customers might have gotten lucky. The competitors to the failed PaaS worked day and night to build a migration tool that lets you convert to their platform.
That’s really cool. Would you bet on that though?
See also: The Cloud - Provider Failure Modes
