Cloud Computing
Our Cloud Migration Story - Part 1
The lifeblood of our testing facility is a program we call LIS (Laboratory Information System). The application is a homegrown PHP/Ruby/MySQL system to recording food sensitivity and COVID-19 test results. The PHP, Ruby, and MySQL instances have inherent maintenance and server modernization challenges. Why constantly keep buying servers, finding space, and applying patches? After all, we are not in the server business.
Migration to the cloud seems like an ideal solution, so I reached out to Google to learn how to move our legacy systems to the cloud. Google responded with a request for me to "share a block diagram including relevant specs."
I have prepared migration plans before, so not a big deal. Luckily we have a tool called SpiceWorks that allows me to examine the devices on the network and create a blueprint of what servers to move and a migration strategy.
The goal is to incrementally migrate and modernize the legacy systems by slowly replacing specific applications with new and upgraded applications and services.
The new system should eventually replace all old system databases and development frameworks, allowing for incremental decommission.
Ideally, some façade intercepts requests going to the backend legacy system. The façade should route the requests either to the legacy database or the new database. Migrate to the new system gradually, and users can continue using the same interface, unaware that any migration has taken place.
I will keep you posted on our migration story with Google.
Migration to the cloud seems like an ideal solution, so I reached out to Google to learn how to move our legacy systems to the cloud. Google responded with a request for me to "share a block diagram including relevant specs."
I have prepared migration plans before, so not a big deal. Luckily we have a tool called SpiceWorks that allows me to examine the devices on the network and create a blueprint of what servers to move and a migration strategy.
The goal is to incrementally migrate and modernize the legacy systems by slowly replacing specific applications with new and upgraded applications and services.
The new system should eventually replace all old system databases and development frameworks, allowing for incremental decommission.
Ideally, some façade intercepts requests going to the backend legacy system. The façade should route the requests either to the legacy database or the new database. Migrate to the new system gradually, and users can continue using the same interface, unaware that any migration has taken place.
I will keep you posted on our migration story with Google.