The SharePoint Online Sandbox - I Like It

Speaking with SharePoint developers, I hear a lot of concern about the Sandbox, usually in reference to the upcoming Office 365. SharePoint Online in O365 will require that code be deployed to the Sandbox,  which means all manner of indignity for developers, like losing access to the file system and certain parts of the server API, but honestly, I'm not all that upset. After working in SharePoint for years and dealing with misbehaved solutions and sloppy code, I generally think the Sandbox is a good thing. Discipline in coding is generally a good thing.

What I don't understand are the developers who plan to avoid coding for the Sandbox and just wish it away. After all, this Cloud thing is a passing fad, and on-premises SharePoint deployments will always be the way to go.

I'm not so sure.

I'm beginning to view SharePoint Online and on-premises SharePoint 2010 as functionally equivalent for most use cases. There will always be businesses with specific data or functionality needs that will want to have some or all of their SharePoint farm in-house, but the big meaty middle of the market won't. They don't need the headache. And I see this meaty middle moving to the Cloud thing in big numbers.

One day, a client will tell you they're moving from on-premises to SharePoint Online. And when that day comes, the developer who didn't code for the Sandbox will have to recode. And that will be unpleasant.

So I'm going to build everything we do with the Sandbox in mind, unless it absolutely positively requires farm level functionality or is for a specific client that requires on-premises servers. Because I'd rather figure it out now than have to tell a client we have to rebuild from scratch later.

It's the SharePoint version of Java's old "Write Once, Run Anywhere" tag line, only this time it's actually true.