/The flight plan

Rocket Garden, NASA, Cape Canaveral

Rocket Garden, Kennedy Space Center, Florida, Jul 2017

Migration of the applications can become very painful for the organizations. Any medium sized organization has anywhere between 500 – 1000 applications deployed, spanning over multiple departments. Assessing the applications as per our / Will it fly? guidelines is just one step of the process. Applications that were cutting edge at some point of time, might no longer be maintainable due to lack of the right resources. There might be very small applications that are used by a handful of people. And there might be applications like the company directory which have hooks from each and every application.

In fact, the bigger and widely used applications might have a cleaner migration path when compared to those pesky ones which are lying under the desk.  Creating a recommended application migration path becomes very important.

The standard application migration paths can be categorized as below. What we need to identify is the ‘best fit’, as inherently any migration path will have its own advantages, costs and pitfalls.

  1. Re-host: Is the application already in a container (e.g., Docker)? Or is it a standard Java application that is running on the standard Linux box? Applications like these can be migrated with minimal changes. The anticipated changes for such applications should be limited to simple configuration changes like interface changes, connector changes and URL changes in the configuration files. Applications like these might be hard to find in an organization that has not kept up with the changing technologies.
  2. Re-factor: This is the path that most of the applications might end up taking. This path is an effort only to make the application ‘cloud compatible’, by changing hard bindings to loosely coupled links. This would need code changes and rewriting of some of the interface components. There might be a possibility that the application is not yet raking in all the advantages of cloud.
  3. Re-architect: Cloud is different. It provides clear advantages to applications that get designed as cloud-native applications upfront. Components are loosely coupled, can scale up/down effortlessly, and are fault-tolerant. Two types of applications can take this path; an application that clearly needs the capabilities of cloud or the application needs significant changes to be migrated.
  4. Remove: Every organization will have gone through changes. Mergers, spin-offs, changes in direction in the company, a proposed consolidation of applications; all these lead to applications losing relevance or getting duplicated. The migration event should be used to retiring such applications.

The effort is to identify the best-fit. Review all the parameters before the application has been marked for any of the four paths, and be flexible in marking a different approach that is best-fit for your organization.

Drive to: /What goes well with your Cloud?

Leave a Reply

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