Not Quite as the Crow Flies: Complications of Cloud Migration


pexels-photo-1089440 (1)

With the opportunities for flexibility and growth, it’s easy to have your head in the cloud(s), but bringing everything else with it? Not so simple. The process of cloud migration has to be taken thoughtfully and strategically or you’ll never get fully off the ground.

It’s not a data center

One of the biggest mistakes people make is thinking of the cloud as just another remote data center, so they don’t transform their applications as they migrate, they simply move them (also known as lifting and shifting rather than rearchitecting).

The cloud provides great advantages in performance and cost savings, but not if you don’t have the tools that are capable of the same flexibility and scalability that the cloud itself offers.


Resource Provisioning

To get the full benefit of the cloud’s potential for scale, you need to overcome two key challenges:

1)    Ensuring that your set up allows for the scale that’s needed

2)    Ensuring that your set up doesn’t allow working at an unnecessary scale

We’ve seen both of these issues in action, and they require the right automation tools to get under control.

In one case, our STS team trained Agency Application Development teams in modern cloud deployment and DevOps practices, which allowed them to provide their own infrastructure on demand for the first time. At first, it worked a little too well; the explosion of EC2 instances reached the maximum for the AWS accounts, requiring service tickets to raise limits and inevitable delays.

By using serverless Lamda Functions, a DynamoDB table, and simple email notifications, Product Owners were automatically notified about the need to increase limits, eliminating the interruptions they caused.

In another case, a combination of inability to map costs properly and instances unnecessarily running 24/7 was creating additional costs for the agency. We developed a system that tagged resource usages to track them to cost centers, and serverless Lambda functions allowed us to:

  •  “Turn off” improperly tagged resources
  •  Prevent the creation of cloud resources that did not contain valid tags
  • Tag non-production resources to auto start and stop based on given parameters

The new tagging system reduced unattributed or unmapped cloud costs from 9% of the total to less than 1%, and teams using the auto start and stop capability saved up to 67.26% of EC2 and RDS costs.

In these instances and countless others, you have to have a full understanding of resource provision, having full oversight into the capabilities and activities of both your new technology and your legacy technology. Start a conversation by booking a meeting with us today! 



If you're looking for best practices and case studies for quickly and securely executing large scale application migration projects, our free eBook, Proven Strategies for Legacy Application Migration, is the resource for you.