Because Salesforce.com's Apex is Java-like, you may have "a fighting chance of porting it to another platform," says Ben Bloch, an independent technology consultant. It might be possible to reuse some logic, user interface, and other elements, but the developer would still have to redo a lot of work already conducted on the Salesforce platform, he says. This includes, he says, not only reconstructing the data required by the application but designing and implementing data and other models that describe the application and its data relationships.
Peter Coffee, Salesforce.com's director of platform research, downplays the porting effort. The Apex development language was designed to be similar enough to Java that it will require only an "insignificant portion of project cost" to translate the components written in Apex and using the company's Visualforce user interface builder to a new target platform, he says. What would take more work, he says, is writing new code to perform functions written to the Force.com API.
Another challenge is recovering the business logic and user workflow included within an application. In his latest development effort, Hekademia Consulting's Shockey is "making extensive use of QuickBase formula fields to create and update this process data, so that if we needed to export our data ... I will at least have the process information within my data model," he says. However, because the actual business logic is embedded within the field formulas of the database, "I would [still] likely lose that logic if we changed systems" again from QuickBase.
The use of open Web standards is, of course, the holy grail that would let any IT organization easily move an application from one cloud platform to another or to its own datacenter. One cloud platform shows how this could work: Because the SugarCRM open source CRM application is built on open standards such as the PHP scripting language and the MySQL open source database now owned by Sun Microsystems, moving an application is as easy as taking a snapshot of your data on the Sugar platform, along with any customizations or application add-ons, "wrapping it on a disk," and uploading it to the server of your choice, says Martin Schneider, SugarCRM's director of product marketing.
Whatever platform you choose, Shockey recommends that developers have a contingency plan for porting their applications, geared to the amount of advance notice the provider promises to give developers it if goes under. Before committing to a cloud development platform, Bloch recommends quizzing a provider not only about the strength of its business model and finances, but its processes for releasing new versions of its APIs and for providing technical and other support to developers.
Decide what you're willing to risk
Some customers -- especially those who have lost data to a defunct provider such as The Linkup -- swear they'll never trust the cloud again. For others, it's more a matter of balancing the benefits (low upfront cost and ease of deployment) with the risks (vendor lock-in).
Committing to a cloud platform is no more of a risk than writing to the Microsoft Windows API, say Steven Harper, the CEO of Plan2win, a developer of sales software. Assuring his apps would run on new versions of Windows "became very very cumbersome ... and very costly to support," he says. "There's almost an infinite number of configurations you can have on a personal computer, with the variety of operating systems" and related software such as Microsoft development frameworks that can drive up support costs, he says.
So he now writes applications for the Salesforce.com platform, and he doubts the company would ever abandon its developers. "There would be such negative publicity and blowback from the customers ... I just can't believe anybody would be that stupid," he says.
But providers do fail, no matter their intentions. At Hekademia Consulting, Shockey has made the best of the death of Coghead, using the porting process to consolidate more functions into fewer applications. He even added capabilities such as calendaring that weren't available in Coghead. What's more, he says, QuickBase is a bit cheaper than Coghead, and his customers are more comfortable dealing with giant Intuit than either Coghead or his own small company.
Unless and until data, application, and other cloud service standards become universal, there is no absolute guarantee you can work around the death or unavailability of your cloud provider. The best bet is to keep an eye on your vendor's balance sheet and to keep your local backups current.
"I still think the software-as-a-service model is where it's all going," says Shockey. "We've just got a bit of a shakeout of platforms right now."