What is ‘Lift and Shift”?
Beth Israel Deaconess Medical Center’s PeopleSoft “Lift and Shift”. In the past, we have discussed supply chain digitization and today we are going to look at a variation on that theme – “moving to the cloud” and specifically, we are going to look at one company’s journey to “lift and shift” their existing application to a cloud platform.
These days we hear a lot about moving to the cloud, but when it comes to moving an organization’s enterprise resource planning (ERP) system, it’s a rather nebulous phrase. What exactly does it mean to move to the cloud? There are, in fact, several options. You could move to a completely “cloud-based” application such as Oracle Cloud. In this case, you implement a new ERP system that is designed to operate exclusively in an internet environment. These applications operate as software as a service or SaaS.
Alternately, you could use a platform as a service (or PaaS) environment. Here you are basically re-implementing your system, but this time it is on a third-party’s server farm somewhere off-site. This third party provides the computational, storage and networking infrastructure along with operating systems, databases and other applications. They license the applications and effectively lease their use to you. This then means you will need to convert to their environmental design and configurations. In turn, the third-party will manage and maintain the hardware and software for you.
Finally, you can utilize a third-party to provide you infrastructure as a service or IaaS. In this case, this third-party provides you the hardware and networking functionality upon which you install the applications which you license and configure to meet your needs. In this environment, you can literally “lift” your existing on-premise applications and “shift” them to the new off-premise environment using either a public or virtual private cloud (VPC).
The following is an account of one company’s journey in doing a “lift and shift” of their PeopleSoft on-premise to PeopleSoft “in the cloud” using IaaS.
Lift and Shift at BIDMC
Beth Israel Deaconess Medical Center (BIDMC) is a world class teaching hospital of Harvard Medical School and part of Beth Israel Lahey Health. In addition to being a 719-bed hospital supporting 5,000 births, 35,000 inpatient, 703,000 outpatient, and 55,000 emergency cases each year, BIDMC consistently ranks as a national leader among independent hospitals in National Institutes of Health funding with a $250 Million research portfolio.
BIDMC’s journey began with establishing an IaaS agreement with Amazon Web Services (AWS) and initially moving a test environment there at the beginning of August 2018. Two months later, the remaining non-Production environments completed their lift and shift to AWS as well.
Then came the delay.
It took seven more months until the Inbound Production cXML server migrated to the VPC, and another two weeks to migrate the remainder of the Production environment. Why the delay? Well, there were a number of reasons, both technical and functional.
Functionally timing was the largest issue. Since the test environments completed their lift and shift at the beginning of the fourth quarter (Q4), there was little opportunity to complete Production migration until the business had completed 1099 and Year-end processing on the Financial and Supply Chain side of the house. And the Human Capital Management folks needed to complete W 2 processing, pension contribution, Open Enrollment, and New Employee Benefit Enrollments before they could allow Production to migrate.
From a technical perspective, there were two key causes of the delay. First was the requirement for redundancy on Direct Connect links for ERP connectivity within the AWS VPC. Direct Connect is a functionality in PeopleSoft eProcurement that allows a requestor of materials to connect directly with a supplier-maintained site, browse a catalog of goods approved for their use, and place a purchase requisition from that catalog. So, BIDMC activated Redundant Direct Connect in April 2019. And then there was a fiber cut incident near the AWS servers, causing another delay.
Additionally, there was an issue with nVision performance. nVision is a reporting tool that retrieves information from a PeopleSoft database and places it into a Microsoft Excel spreadsheet for analysis and/or reporting. When BIDMC moved nVision reporting to their VPC, response time of nVision reporting increased dramatically. In fact, the increase in latency was so dramatic that it was a showstopper. This had to be addressed before Production could migrate to the cloud.
These latency delays turned out to be caused by something called “input/output operations per second” or IOPS. The solution to managing BIDMC’s IOPS issues came down to moving to 3-tier IOPS and sizing their Elastic Compute Cloud (EC2). EC2 is a web service that provides secure, resizable compute capacity in the cloud.
The final technical delay was that during this period the Oracle Database was upgraded from version 12.1 to 12.2. Once these issues and activities were addressed, it was time to migrate.
As “go-lives” go, this transition was remarkably quick and uneventful. The team disabled user access to all servers associated with the lift and shift, then brought down the Oracle instances. Following this, they began the two-hour process of synching the on-premise server with the virtual private cloud servers of AWS. Once completed, the Oracle instances were brought back online and the BIDMC PeopleSoft Team performed a brush test (sometimes called a smoke test) to ensure that all data and functionality successfully made the migration. Once continuity was ensured, users were again allowed to access PeopleSoft.
Total downtime: approximately five hours!
But the work didn’t stop there. Once the system was up and running, the BIDMC team spent the first several weeks utilizing the flexibility of EC2 to trim and optimize their usage, saving money and enhancing performance.
Some key areas of optimization included:
- Scheduling Non-Production Instances. Non-Production instances typically represent at least 2/3 of your total cloud cost since you only maintain one Production environment but keep multiple test instances operational. Most businesses will need to keep Production running 24/7, but do not need that kind of coverage for the test environments. Therefore, BIDMC runs non-production environments from 7am to 7pm Monday through Friday. This resulted in up-time being reduced to 60 hours versus 168 and resulted in a reduction of EC2 costs by 64%.
- Optimize
Production EC2 Instances. By resizing the EC2 servers BIDMC was able to identify
and eliminate excess server capacity, reducing cost without compromising performance
or efficiency.
- August
Production HR Database EC2 Instance Change
- Change EC2 type from m5.12xlarge to m5.4xlarge
- 66% cost savings
- $26,350 annual savings
- August
Production FSCM Database EC2 Instance Change
- Change EC2 type from m5.4xlarge to m5.2xlarge
- 50% cost savings
- $6,587 annual savings
- August
Production HR Database EC2 Instance Change
Further, using EC2’s flexible scheduling, BIDMC was able to optimize performance throughout the daily operating cycle.
Conclusion
In the final analysis, BIDMC’s lift and shift of their existing PeopleSoft applications proved to be both cost effective and relatively smooth. The Medical Center realized initial cost savings in real estate, hardware and labor by eliminating their on-premises server farm. And by having a third-party manage their infrastructure those expenses represent ongoing cost avoidance.
After tuning and optimizing the EC2 servers, further cost savings were achieved. And performance?
While a few operations were slower, most were the same or better than when performed on-premises and overall performance showed a slight improvement.