The challenges and pro’s/con’s of moving Angelbeat’s internal infrastructure to the cloud provides some valuable insights to organizations of all sizes, who are undoubtedly grappling with similar issues. IT at Angelbeat is fairly robust, including onsite and remote/traveling workers, >250,000 contacts maintained on Exchange, customized CRM/event registration apps developed in 1999 (when Angelbeat was formed), a dedicated server/data center/storage room, plus a website that is obviously mission-critical. Here is a summary of what we did and didn’t do.
The website Angelbeat.com was originally hosted on internal servers but moved to a specialized web hosting firm in 2000. A great decision (if I do say so myself) as hosting can be complicated, is not our core expertise, and the site has never gone down for longer than 15 minutes. Later in 2013, event registration processing will be switched to a cloud-based service such as EventBrite or Cvent. Both entities have links/interfaces already created to social media platforms, plus their webpage displays are automatically rendered correctly across different browsers and hardware platforms. The next logical step.
Data backup was originally done via an attached drive physically connected to the servers. But this creates a single point (or location) of failure, should there be a fire or flood. About 7 years ago, all data files and contact records were also backed up to cloud-based backup firm, and this has worked great. Fortunately I have never needed to recover my information!
The biggest (and in the end unsurmountable) challenge was moving internally-hosted/managed exchange data to an external Microsoft exchange hosting firm. We could not find one that supported public folders, plus preliminary costs were much higher internal expenses. If I were starting Angelbeat today, then using salesforce.com or sugarcrm would be a no-brainer. But given this legacy application that is the core of Angelbeat’s business (just like Cobol applications running on mainframes), we still have our own data center/servers that run exchange. On a related note, remote workers use thin client/virtual desktops applications to securely access this information from any location.