Strategies to Migrate into the Cloud

Formulating a strategy

Many companies consider to migrate either applications or full data center infrastructures into the Cloud. There are a number of strategies which describe on how to migrate a given on-premises infrastructure into the Cloud.

While those strategies may help to identify a best path for an upcoming migration it only may help to guide an individual business on their way to plan a migration strategy.

Overall a key factor for any given migration is to get a strategy defined as it will save time, money and provides a realistic scenario – as well as an adjustable one.

Know your installation

Typically it should be known what got installed, deployed – what is in use. However, depending to the companies size, the diversity on how applications and services get deployed and maintained it may become a need to look into opportunities to get discovered what’s out there.

Unless a repository exists (i.e. based on ITSM and ITIL mechanics) to get an overview on applications, installations created various additional options exist which can be utilized to get a repository created.

In case of AWS services and tool sets such like AWS SSM, AWS ADS can be a great help to either generate a full repository from scratch or get a given repository completed to get to a good 360° view.

The better the repository and understanding on a given infrastructure – the more likely a successful migration plan can be planned while reducing risks of unknown parameters.

Know your abilities

Though this would be a case-by-case topic. Depending on how a given company plans to migrate into the Cloud and certainly depending to an overall size and budget dependency (fully self-driven vs all supported by consultancy or something in-between) it may be helpful for teams who look into the Cloud first time to consider introduction level courses. Nothing large, complex but surely it’ll be helpful to get a baseline set.

Re-Host / Lift-and-Shift

Many companies consider the re-host – also known as lift-and-shift – strategy as their best option to get a given on-premises infrastructure migrated into the Public Cloud, such like AWS. Obviously in large infrastructure deployments – supported by an understanding of an above mentioned repository – this already can lead into a savings component.

Large parts during a re-hosting process can be automated which can help to simplify a migration process as well as it can help to speed up a delivery timeline. This option though would have to be looked into in a case-by-case situation.

Re-Platforming

Either as part of a lift-and-shift process or after a deployment into the Cloud a re-platform option might be considered. What does that mean? After a successful deployment and a review on budget spendings a change from individually maintained deployments such like RDBMS, Cache applications such like Redis or Memcache, Brokers such like RabbitMQ could be reviewed to be changed into Cloud based and maintained services.

For example a local, ec2 instance deployed RabbitMQ setup could be considered to be changed into a managed service deployed product such like AWS MQ. Or caches such like Redis or Memcache could be considered to be exchanged by AWS Elasticache

A re-platforming may lead into another level of further cost savings. Some thoughts are put together in an article in this blog. It’ll support interchangeability, operability as well as maintainability.

All-in-all the core architecture of a given application will not be touched or changed during a re-plattform process.

Re-Architecturing

This concept certainly is the most complex one as it will change the core architecture of a given application. A number of factors may require or lead into a need re-architecture a given environment or application.

Driven by patterns such like a need to be able to highly scale, support server less execution, meet certain performance levels could empower to utilize Cloud native services.

Example: an application with a decoupled processing uses RabbitMQ (or AWS MQ) to establish an EMB to handle message brokerage between components in an application to get those processed. An alternative could be a native Cloud service such like AWS SQS.

While the efforts to change tend to be the most complex and therefore re-architecture may be expensive otherwise this can be a very beneficial option to be considered it agility, performance, high availability at typically lower pricing could be the outcome. Though this comes with an invest and efforts initially.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: