For years, cloud vendors have been struggling to figure out how to migrate enterprise applications on a large scale.  While lift-and-shift and virtualization provide some value, a great number of applications require a refactoring. A daunting fact is –a typical large enterprise has hundreds to thousands of apps to refactor, many based on obsolete or aging technology.  When it comes to factory-like motion, cloud vendor migration programs have been over-promising and under-delivering for years.  If the goal is client apps running and remaining as committed workloads on their infrastructure, application rewriting must be simplified.

Cloud Migration Programs Continue to Struggle

Application and database re-hosting is now an inexpensive de-facto offering from all cloud vendors. Amazon Web Services Server Migration Service (AWS SMS) and Database Migration Service (DMS) are low-cost, self-service solutions to move workloads and data, respectively. Soon, AWS will offer a service to seamlessly deploy and manage VMware workloads across on-premises and AWS environments.

That’s fantastic, but what about applications that need refactoring – the apps that are still crucial to the business but need to be rewritten for a variety reasons? During refactoring, an app will likely be rearchitected to a better technology stack and possibly a more modern language. Also, an app will have its requirements updated to accommodate the current needs of the business.

Without technology, cloud partners have no tools other than applying best practices and familiar strategies when dealing with application refactoring at enterprise scale. Their involvement is very labor and time intensive, translating into high costs. To compound the situation for cloud migration programs, re-hosted apps to one cloud vendor can in turn be re-hosted to another cloud vendor. This lack of stickiness makes a re-hosted app less valuable to a cloud vendor, as compared to a rewritten app. From a client’s perspective, re-hosted apps do not take advantage of cloud-native services and APIs. With a rewritten app, the idea is to apply cloud-native functions where appropriate to gain the benefit of key services that are optimized for the cloud vendor’s environment. Cloud-native app refactoring is extremely valuable to a cloud vendor who covets the thought of an application being dependent on its platform. The likelihood of such an app being moved to another cloud vendor is very lowered.

Delivery Partners Have Little Incentive

The major cloud vendors have an endless list of System Integrator (SI) partners with expertise to help an enterprise on their cloud journey.  Factory migration is about speed, lower TCO, self-sufficiency and improved time to delivery, none of which are exactly in the best interest of a System Integrator.  Instead, in my experience, I have observed the following.

SI tactics have very little to do with accelerating migration

• Application Assessment –enterprise portfolio apps are placed into one of five categories:
  • Rehost – often referred to as “lift-and-shift”
  • Replatform – like rehost with a few configuration and security mods and tweaks
  • Repurchase – upgrade or switch to a different product altogether
  • Retire – get rid of immediately or phase out
  • Refactor (rewrite) – re-envision the architecture and design
  • Retain – do nothing or revisit later
• Transformational Frameworks – process, presentations, case studies, etc.
• Reference Architectures – provides a high-level view
• Workload Movement – lift-and-shift server-based agents for ready-to-move apps and data

SIs see migration as another multi-year T&M opportunity

• No IP or means of automation to refactor apps
• 1-for-1 app-centric view of rewriting
• Reuse for innovation is normally not an upfront goal
• Counter to the intent of Migration Acceleration Programs

Refactoring Momentum – Think Functions, Not Apps

We need to rethink what we are trying to accomplish with respect to factory-like migration of application refactoring.  It’s an immense undertaking and as with any large object, the only way to move it is to create momentum.

One method of creating – and maintaining – momentum is to instead of thinking about rewriting entire applications, think of rewriting functionality.  Since an application is a composite of functionality, if we can break it down into more manageable tasks, then repurpose some of the functionality, we will in fact be initiating the rewriting of the application.  Choose to design each function as reusable, stateless, secure, and highly available.  This can be accomplished using serverless functions (AWS Lambda for instance) or creating RESTful APIs.

In Conclusion

It is obvious the cloud vendors have a dilemma.  When it comes to enterprise application migration, the elephant in the room is still application refactors (rewrites) which often trample an otherwise decent story.  Without technology like Harbormaster to help bridge the gap between what an application is to what an application needs to be, the only solution will continue to be labor-intensive T&M heavy engagements: apps are either re-hosted (minimal stickiness and service consumption), remain untouched (no value to vendor), or approached as a multi-year effort (unattractive to client).