Legacy modernization: Prioritizing the application portfolio

wooden-ducks-in-a-row

The majority of legacy systems in operation today are the result of years, often decades, of combined investment, development and customization. While to an outsider they may appear to be archaic in both design and operation, these systems continue to manage core business operations and provide significant competitive advantage. They may have been partially rewritten, migrated to new hardware and patched consistently over this time, but they have never been replaced. The costs and risks always seemed too high, or a worthy replacement was never there to be found.

For the organization that envisions 100-percent of its applications running in native cloud, legacy applications can present frustrating obstacles that throw caution and delays into an already complex migration mix. It’s one thing to want to be cloud-native, and quite another to tackle the step-by-step planning for such a huge transition. But plan you must, and that requires approaching legacy modernization on a case-by-case basis.

So, where do we start?

Legacy applications, by their age and nature, can be uncooperative, costly and a challenge to migrate, but they are still intelligent systems providing value and they must be transformed if you want them to continue to do so. Before you can enjoy all of the benefits that native-cloud has to offer, you will need to choose one of a number of migration methods. The bad news is that very often there will be no immediate clear-cut answer to how your migration journey should start. The good news is that a solution will come when you delve a little deeper into the characteristics of your workloads.

Prioritizing what gets migrated first in your application portfolio can help you to manage your legacy modernization in the most efficient and cost effective way.

Go consistent or go home

Consistency is everything when it comes to modernization, otherwise what’s the point? We’re talking consistent performance that is equal to or better than before, and which encompasses every aspect of functionality, performance and connectivity, including memory, CPU, storage, network latency (or lack thereof), access speeds and security. After all, what’s the modernization value in a migrated mission-critical app that is plagued with latency issues, or an app that fails to maintain the Fine Grained Access Controls that were so pertinent on its previous platform? Customization is another critical consideration – fail to migrate the application customizations you’ve specifically developed over time, and you lose a vast majority of its value to the enterprise.

Time for triage

Prioritizing what gets migrated first in your application portfolio can help you to manage your legacy modernization in the most efficient and cost effective way. By looking at the workload characteristics of each application, you will start to get a good idea of your critical and non-critical applications, what can be migrated and how that can be achieved. Typically, you’ll be faced with large-scale monolithic apps, apps that are tied to specific libraries, frameworks and languages, and the apps that are simply too risky or costly to be rewritten. In other words, a seemingly scary list at first, but a list that you can start working with.

Possibly the most important questions to ask when deciding what gets migrated first are, which apps are going to be easier to shift to the cloud while also taking instant advantage of the agility that cloud provides?

Possibly the most important questions to ask when deciding what gets migrated first are, which apps are going to be easier to shift to the cloud while also taking instant advantage of the agility that cloud provides? For example, a small app that is well written and which requires regular infrastructure changes or experienced frequent or seasonal spikes in traffic may be the best starting point.

Re-architect, retire or revisit?

The truth is that, no matter what you may hear or read elsewhere, the majority of legacy apps require a degree of modification before they can take full advantage of cloud capabilities. Rehosting might mean you migrate faster, but you’ll still be migrating over most of the app’s existing challenges. Re-architecting an application is usually driven by a need to address existing app challenges, write in new languages, modify the app to take advantage of newer technologies or create an API for the app. While more time-consuming, this approach can also be extremely beneficial in transforming the application further so that it can take full advantage of its new environment, offer new features to the application end-user, and the cost savings often seen when moving an app to the public cloud.

So, what do you do with those challenging applications that prove simply impossible to migrate? One way to address the problem is to get rid of them, or retire them. Simply speaking to the owner of an application can reveal it is no longer providing value, or can easily be replaced by a cloud-friendly alternative.

And then there are the applications that you simply aren’t sure about, and which may need to be placed on a “revisit” list. Perhaps you need to decide whether they still provide enough value to warrant migration to cloud, or perhaps you are waiting on a decision to be made by stakeholders. In these cases, waiting may seem logical. However, lift and shift as a proof of concept can help to unblock indecisive minds and reveal benefits that may not have been immediately obvious.

Lift and shift first?

The lift and shift approach — taking existing applications and migrating them to a new environment without redesigning the app — might be a good place to start your cloud migration. It can certainly be a great way to modernize non-critical legacy applications with minimal disruption, and can be a good choice when the line between migration and modernization appears blurred. In taking this approach, you can keep your migration plans moving, reduce pressure on development teams (at least for now) and take advantage of cloud’s enhanced scalability, security and agility.

Rehosting applications in this way can be completed using automated tools, allowing you to get started with the next stage in the migration process, start on redevelopment or move to the next application on the list. What’s more, once your development teams get their teeth into redevelopment of non-critical legacy apps, they will be primed with experience and ready for more business critical applications later down the line.

However, it is important to mention that a lift and shift approach also comes with a number of caveats and means your application may not be able to take advantage of other cloud features without redevelopment, and as a result may not give you the fastest ROI. Simply put, there is no one-size-fits-all, quick fix approach even with lift and shift. You still need to assess each application on a case by case basis and decide the best approach for each.

The SaaS alternative

For legacy applications that require massive re-architecting to work in a cloud environment, it may make sense to instead transition to a SaaS-based application — there is a SaaS application for almost everything we do in-house today, though sometimes comparable alternatives for application customizations are difficult to find. This may apply to apps that have complex on-premise database dependencies or a lot of custom coding, and where a traditional lift and shift approach isn’t the smartest or fastest route to modernization.

The journey to cloud can be a short, swift jump for some and a long and more complex path for others. The key to starting that journey lies in knowing what you have to deal with and the methods you can use to get you to your destination faster and with the least amount of risk.


Ravi-Chalpe-headshot1Ravi Chalpe is serving as an Oracle Practice Advisory Leader at DXC Technology.  He is currently responsible for developing Oracle Cloud services offerings around Oracle Cloud Infrastructure and Platform services. For the past 16 years with ES and DXC, he served many roles as Practice leader and supported many complex projects and initiatives. Prior to joining DXC, Ravi worked at Sun Microsystems and Bechtel Corporation as Technology Architect and Team Leader in support of Oracle Technology and ERP Applications.  Ravi spent eight years with Wipro InfoTech and Tata Elxsi Ltd., India in various roles from Software Engineer to Regional Manager.


Jim-Battenberg-headshotJim Battenberg is Senior Director, IaaS Product Marketing at Oracle, where his focus spans the entire IaaS portfolio of services. Jim’s time in “the cloud” dates back to the mid/late 90s when the shared hosting, dedicated hosting and ASP markets first began implementing the core concepts of virtualization. He developed and launched a suite of profitable hosting services from scratch and helped take Interliant (later purchased by Navisite) public. Prior to Oracle, Jim led the Platform Enablement team for the CenturyLink Cloud. Before that he led marketing, and created the first product marketing function for the Rackspace Cloud. He has also held senior product management and marketing leadership roles at enterprise hardware, software and hosting companies across startups and Fortune 500 firms.

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 )

w

Connecting to %s

%d bloggers like this: