Advice from Pivotal About Migrating Legacy Applications

For many businesses, legacy app migrations are becoming an increasingly important issue when they examine their technology portfolios. Companies have the desire to move these applications, which are vital to their operations, off their existing infrastructure and to the cloud to ensure the applications can continue to provide value in the modern world.

But this is often easier said than done. Legacy apps have become one of the enduring points of pain, as the cost and difficulty in managing them within a large portfolio of applications leads to companies needing to prune and rationalize them on regular basis.

This has long been a very difficult problem for IT and is one of the ways that the more professional organizations distinguish themselves from those that are merely making do. But the whole prospect of how to exploit the cloud has added pressure on how to migrate a portfolio of legacy applications. The opportunities the cloud presents for increasing automation, enabling rapid innovation, and reducing operational costs are tantalizing. The cloud can also help solve operational problems with existing apps.

Yet, to achieve this, companies must figure out which strategies to follow to make their cloud migration smooth. This strategy includes in which order applications must be migrated and that’s the root of the problem of legacy app migration.

I’ve written about this before and there are a number of products on the market that help companies manage this migration.

At Early Adopter Research, my technology research company, are working on a research mission to explore legacy application migration and the sustainable competitive advantage companies can achieve by enacting a plan to strategically manage their portfolio of legacy applications and migrate them in the right way.

There are so many different ways of doing this, though, that it’s a fascinating problem each company will have to figure out and optimize for its own needs. And, every single cloud vendor has many customers involved in this activity – each approaching it in their own way.

Recently, I’ve had the chance to speak with the team from Pivotal about this very issue. Pivotal offers a cloud-based platform for companies to run their applications. Originally, Pivotal thought that the majority of their clients and subsequent work streams would be focused on creating and supporting net new applications on their platform architecture. Instead, they’ve been surprised at how many of their clients are interested in using the Pivotal platform to manage their legacy application migration.

“Legacy app migration can be a challenge, but once you begin the process, you start to see things happen in production a little bit after that, on a timeline of weeks rather than what used to be months and years, and then you get that energy sort of folded back in. So in the same way you’re building knowledge, you get the power of that energy building up too, and the migration becomes less discouraging.”

Chuck D’Antonio, Pivotal

Their experience working with these clients provides instructive guidance on how to effectively migrate legacy apps and the benefits of doing so.

Problems With Migrating Legacy Applications

Legacy app migration projects often lead to refactoring and to discussions of the relative merits of monolithic vs. micro-service architectures. To do a good job, I think it is important not to hat monolithic architectures. Remember, they were created when they were by smart people who recognized them as the the best option available at the time to support mission critical applications.

Pivotal’s John Ferguson agrees that we must understand the value in monolithic architectures:

“The monolith really represents those decades of learnings around how the business works, how the markets work, the types of things that they need to offer. You shouldn’t get rid of those learnings altogether.”

John Ferguson, Pivotal

But now, companies depend on the apps built within the monolithic architecture that now is outdated and keeps them from being able to meet today’s data demands. With more data being generated and consumed by applications than ever before, companies need their applications to be scalable and more highly automated.

“Companies were using monolithic architecture because it was a good solution to the problem at that time. But maybe it got them diverged a little bit from that sort of semantic cleanness that they might have had in their original design.  And so you’re untangling a lot of that as you go now with migrating apps.”

You now need your apps to be able to participate in an agile process of evolution and innovation. Monolithic architectures tend to be highly interconnected. While this can lead to fiendishly clever optimizations, it also means that you pretty much have to understand the whole program to change any part of it. That limits flexibility.

For Pivotal, to make it possible to evolve monolithic applications, innovate, and allow their capabilities to be used by other applications, the monolith must be broken apart into simpler component parts. It’s a decomposition process that leads to progress. Companies have to find out how to reduce monolithic architectures where it makes sense.

“We call it strangling the monolith.”

John Ferguson, Pivotal

Why Strangling the Monolith Doesn’t Have to Mean Changing Everything All At Once

There are lots of benefits that can be gained from migrating one or two legacy applications, or even portions of those applications, to a cloud platform. This lowers the burden and difficulty of migration because you’re getting benefits immediately, without having to do the heavy lift of moving everything at once.

You can improve your legacy app situation gradually and over time by looking at your application portfolio, deciding which applications are the crucial ones that you want to make sure you can evolve, figuring out what’s the right strategy for migrating each application, and then migrating them in portions. This controlled decomposition can be done without creating a mess.

There are three main strategies to achieving this type of decomposition and migration of legacy apps:

1. Lift and Shift
2. Incremental refactoring
3. Heavy duty refactoring

I cover each of these below. In Pivotal’s experience, they’ve seen 25% of their customers use lift and shift, 50% use incremental refactoring, and 25% heavy duty refactoring.

Lift and Shift

The lift and shift strategy is in many ways the simplest and easiest way to approach legacy app migration, but also the one that provides the least value over the long term. With lift and shift, you’re moving with as little effort as possible an application from on premise to a cloud environment. The app stays the same as much as possible and is changes only to accommodate the new computing platform. Sometimes this is easy and sometimes it requires more refactoring and integration work. In any event, generally the results of this approach are positive because you have the application running in a new environment that is far more friendly to automation and if you do decide to do any further development on it, you have a better starting point for managing the application and using new services to automate deployment and operation. On the other hand, you really haven’t make the application more powerful or made its services available to other apps, or made it easier to innovate.

Incremental Refactoring

Incremental refactoring means that you are in some sense going to break the application into services. When you’re doing monolithic decomposition, you’re thinking of the semantics of the application, and you’re thinking about how all the elements of the application are grouped together. With incremental refactoring, you take one element of the application, whether that is one object or one service, and make that the place where you group all the technology and coding, so you can handle the policy and varying types of datasets. You’re then adjusting and migrating this part of the application so that the entire application can migrate over time. It’s sort of like object-oriented design, it’s just you’re doing it with the patient on the table.

“One of the main things with legacy app migration is taking that knowledge you have about the system and the process it supports, and getting as much of knowledge in one place at a time, so you find the right places to break the system up. You find those seams and you break those services based on where those seams naturally occur. I like the seam metaphor a lot, because it really is what it is. The seams are naturally there. You just need to take all that knowledge that you’ve built up to bear, and then tear the system apart at the seams. Otherwise, legacy app migration can occur from a really technology-oriented perspective or from a perspective of how we think the system works without really knowing, and the migration ends up divorced from the business process, or the business process divorced from the system.  You need to kind of take all that together, you need to find those seams, tear at one of the seams to get a piece to work on, get that working and really rapidly running on the new platform, so that you can start to get that feedback loops and those learnings happening very quickly, of what this means to have that as an independent service.”

Chuck D’Antonio, Pivotal

So, in an incremental refactoring, often one part of the application is turned into a service so it can run better, or maybe two or three services are created. New orchestration logic ties everything together. This type of refactoring can take place with or without changing the UI.

Heavy-duty refactoring

The final, and by far the most rewarding approach to legacy app migration is heavy-duty refactoring. With this, you’re taking an application and decomposing it in a more radical way so that the entire application runs with a new User Interface (UI) and with a new bunch of services that were created and knit together to service it. This can be an important step forward when you want to jump start the innovation process with an app. You have to first decompose it into services, but once this is done, you can leverage it to help scalability, add new services to replace existing ones, and integrate a portfolio of services from other apps to make the migration truly success. It’s a high effort, high value approach when you have an application that would really benefit the company by evolving more quickly.

The Forces Accelerating Legacy App Migration

Based on my conversations with Pivotal, the main reason they find their clients are using the Pivotal platform to manage legacy app migration is because application performance improves by doing so.

“We’ve found that the operational efficiencies of working with the abstraction levels of our platform are so great that the really big driver for our customers and actually for us, economically, too, is the migration of legacy apps, with some refactoring onto the platform.”

Rob Mee, CEO, Pivotal CEO

But it also seems that companies will go through stages with using their platform to handle the migration. According to Mee, there are three essential stages companies go through:

1. At first, they just want to gain operational efficiency and for their systems to become more resilient.
2. Then they recognize they can get their apps to run more reliably and with greater scalability.
3. This leads to greater agility in general.

Having a legacy application run on Pivotal avoids many of the problems that companies have using anachronistic architectures to support their legacy applications, like:

• Scaling
• Having to babysit and devote a lot of resources to the application to ensure it runs correctly
• Having to wait to see results once the migration occurs

This type of migration can lead to dramatic changes in a company’s culture, with people more invested in their work. Teams that have the context knowledge to make changes and are finally given the power to do so.

“We’ve seen that as people decompose these services, they become much more autonomous, meaning the teams themselves are really empowered to act. And I think that’s interesting, particularly in the enterprise world where they’re taking these large legacy systems and decomposing it, and when they do, the team structure, the organizational structure, is changing dramatically because it has to. The idea is that you’re empowering people to contribute to this ecosystem and then the ecosystem is growing. And even more important is getting that authority to the team to make the right services and to make the decisions about their services based on the demand for them.”

John Ferguson, Pivotal

D’Antonio agreed:

“I think as a byproduct of these decompositions, you’re reinvigorating your talent, you’re reskilling your talent, and making it more attractive potentially for people to come work with you, because now, they’re not coming to work on the giant ball of mud, they’re coming to work on new and interesting services.”

These downstream cultural benefits to legacy app migration are just as important as the technological ones. And once legacy app migration begins to occur on some apps, the entire process accelerates. As Ferguson told me, the point is to:

“Just get started.” Don’t worry about doing it all at once, just focus on doing something.”

According to Pivotal, the typical Fortune 500 customer they work with has thousands of apps. Some of their customers have already migrated more than 5,000 apps with Pivotal’s platform. But they began small and worked their way. The benefits accumulate over time and the entire process becomes easier with each migration.

Author: Dan Woods

My mission: Find technology for Early Adopters. Follow me on Twitter @danwoodsearly and on LinkedIn www.linkedin.com/in/danwoodsearly/. I am a CTO, writer, and consultant. For tech vendors, I help explain their technology. For users, I help find, select, and deploy new solutions that have explosive business value. I love to speak and share ideas.