Application Modernization: What to Do in the Initial Process (Part 1)

3 min read

Steps to determine which of your applications need modernization and where they should be placed.

You probably have hundreds or thousands of applications where solutions are built and deployed running in on-premises data centers. Some run on virtualized technologies. Due to constant improvements in technology, you need to determine which of those applications need modernization.

Three categories of applications

  • Hypercritical: A considerable amount of applications — let’s say 20% — are hypercritical. You absolutely need to keep those applications running for your business to succeed. In the long term, up to 5 to 10 years, you want to invest in modernizing the logic or the scalability of those applications.
  • Lower priority: Some applications that need to be migrated but have a lower priority for your operations than the hypercritical ones.
  • Non-essential: As you only modernize what is going to play an essential part in your organization’s future, some applications you ignore and sunset. This process occurs as part the evolution of modernization. Your users never notice when old, outdated applications are gone.

Choosing where to change hypercritical applications in the cloud

You want to update hypercritical applications with the latest capabilities specifically in the following areas:

  • Hyperscale cloud
  • Regulatory cloud for compliance with industry or government mandates (or both)
  • The ability to do hybrid multicloud
  • The ability to evolve those solutions as they progress

You need to break down your applications that demand updating most urgently into architectures that are common. This process means finding which applications are most present in your application programming interfaces (APIs) or user interfaces or web pages. Most applications needing modernization work with certain business application integration points, as well. Elements of these applications communicate with backend systems or use persistence.

Look for and focus on migrating applications sharing one or two common patterns. IBM and Red Hat can provide you with specific tools to use to help you introspect those applications for the key elements for how they migrate. From there, you can take a fast journey to move those applications away from being locked in their original technology.

Modernizing the developer experience

Whether you’re moving an application from a virtualized environment, an application server, or an outdated platform, that application should aim to fulfill modern software engineering and software delivery lifecycle needs. This goal means you should improve and modernize the application along with the developer experience and the ability to deliver the application.

In particular, modern cloud native developers need to be laying the foundation of DevSecOps into the migration of their activities. This way, these developers give their applications far more usability and speed of recovery as they move their features and functions out into a production environment.

Modernizing your application infrastructure means, in essence, you’re performing the following three tasks:

  • Modernization of the developer culture
  • Modernization of the developer process
  • Utilization of more modern tools to achieve modernization

Application placement is key

When you’ve brought channels of applications into a modern cloud native environment — let’s say Red Hat OpenShift — and improved your developer processes, your next concern is placement. You must decide where are you going to manage and control the placement of these applications. This point is where a hybrid strategy is critical. A key core set of IBM clients use the public IBM Cloud because it’s an affordable and fast cloud native environment to do development.

Build a new modernized container for your modernized application and do a security scan and vulnerability scan as part of your placement plan. You have the following choices for placement:

  • Place the application into another OpenShift environment on another hyperscale cloud.
  • Put this workload into a regulatory cloud. You can take advantage of compliance requirements and, if using IBM Cloud Hyper Protect Services, easily build secure cloud applications using a portfolio of cloud services.
  • Place the application into an on-premises structure, perhaps to a distributed cloud offering like IBM Cloud Satellite. IBM Cloud Satellite brings IBM Cloud services like the managed Red Hat OpenShift for IBM Cloud service to the infrastructure of your choice.

When determining placement, you should review what applications you need to maintain code on for your business and what applications should run at scale in the future. Some of these applications should be in the cloud, while others you may want on-premises. Make this decision by using the same horizontal and vertical scaling techniques that you deliver to a modern application.

Part two of this blog post offers tips on how to determine what applications you have that need modernization.

Learn more about IBM Cloud Satellite and join the ongoing beta.

See the following video for an introduction to IBM Cloud Satellite:

Be the first to hear about news, product updates, and innovation from IBM Cloud