Last week we met with a large cloud provider to discuss how their enterprise customers could use UpGuard to aid the migration of in-house systems over to their platform.
During our discussion I recounted how back in 2001 while I was at Colonial First State I took part in the migration of their production systems to the EDS datacenter. I was a technical lead looking after one of the dozens of applications that needed to be migrated.
I remembered standing in this huge datacenter, opposite a set of server racks which held what would shortly be our new production environment, nervously looking at the 10 page checklist I'd been asked to compile, it literally held hundreds of checks which I had to perform manually after each migration practice run.
Each run of the checklist took hours to complete, the entire time I was under constant pressure, I felt that I had to triple check each action I performed and at the end I was always left with these daunting questions:
Did I leave something out of the checklist?
Did I make any mistakes?
How long would it take me to track down these mistakes?
What would the impact be?
No matter how much sleep I lost over it, I never had a high level of confidence in what I had done. How could I? Humans make mistakes.
Migrating applications which have been in a stable setting for a long period of time over to a new datacenter is a daunting task. There is no room for failure. Actually, any mistakes equate to a failed migration, perfection is the only outcome allowed.
The more critical and/or complex the applications and systems the higher the potential for failure.
How UpGuard can help
With UpGuard technology teams can work together to document the configuration details around an application and easily generate an automated set of tests. These tests can then be run against a server to confirm that the application is configured correctly.
Many hours of manual checks can be replaced by an automated test suite that runs in just a few minutes and at the end a report is generated which tells you how well or how badly configured your server is.
How would I have done things differently back in 2001 if I’d had UpGuard?
Using UpGuard for the datacenter migration the process would have been something like this...
1) Use UpGuard to create a test package and add the application development, support and operations teams to the package.
2) Collaborate with the various teams to capture all the relevant configuration knowledge within UpGuard and then convert these checks into a set of automated tests
3) Work with the operations team to fine tune the test suite by running it against the production environment, fixing any issues with the test suite and iterating until all the tests pass.
4) Armed with a test suite to check the production configuration baseline we could commence work on the soon-to-be production environment.
5) Deploy the application to the target server and run the automated test suite. Repeat until all tests are passing.
So how is this better?
The 10 page checklist I had in 2001 woud now be an automated test suite.
The test suite would be compiled with the help of the people that knew the application the best.
Each run of the test suite would take just a few minutes, not hours, to execute.
If there were errors in the deployment process I would know right away. I could fix the issue and rerun the tests.
If I have tests that represent a production baseline and they all pass then I know the migration was successful.
I would sleep well knowing that I have a repeatable process that runs hundreds or thousands of tests to measure the quality of the migration in minutes.
A great side effect is that post the datacenter migration the operations team would end up with a comprehensive set of tests that they can run before and after changes or as part of their monitoring setup to keep an eye on the configuration.