Case Study: Bringing the IT Environment of an 18th Century Insurance Company into the 21st Century
Started by Benjamin Franklin in 1752, the Philadelphia Contributionship is the oldest successful property and casualty insurance company in America. Although we have modernized in many ways, some things are still the same; for example, our core product is still homeowner’s insurance. But, as I was quick to learn upon joining the company in 2010, technology had fallen a bit behind in the IT department.
The company was 260 years old, and continuity and survivability were becoming the primary objectives. The applications and data supported 400 insurance agencies with a network of over 2000 agents, and the data center was becoming very difficult to manage. We were very constrained in terms of square footage, so we were forced to maximize our physical footprint. All this led us to adopt virtualization: the opportunity to consolidate our environment so that we were no longer limited in the data center.
The benefits of virtualization were immediate. We experienced improved flexibility and manageability, as well as the ability to replicate the entire virtual server. With our environment virtualized, an improved disaster recovery plan was needed to insure future viability. Today our IT environment is 100% virtualized with almost 100 VMs spread across two data centers.
The Environment Today:
- 100 Virtual Machines
- 4 TB of data
- Very regulated in terms of maintenance and handling of data
Key applications need to be protected:
- Microsoft SharePoint
- Document Management
- File server environment
- Accounts Payable and Receivable
- General Ledger
- IT Ticketing
- Small IT team
BC/DR Before Zerto Virtual Replication
Our pre-existing DR plan was a patchwork collection of several methods designed to spread out our risk. We had a multi-step process in place that involved backing up to tape and then rebuilding the environment from scratch at a recovery site. We were also pre-staging virtual servers and replicating unstructured data to the remote datacenter. At best it would take 24 to 48 hours to be back up and running, too long for our business and our customers. Testing the recovery plan was a very long and difficult process, which required a very precise run book for each system being restored. Adding another layer of complexity was the fact that we were protecting heavily regulated data. As such, in terms of restoring the environment, it was very difficult to set the appropriate expectations to the business for recovery time. There was also no easy way to automate or script the steps needed to bring the servers back online, which made for a very manual process. Overall, the recovery time objectives (RTOs) and recovery point objectives (RPOs) were extremely high. It was very expensive to manage and maintain and was not meeting the needs of our business.