Summary
What is a pragmatic path to Java application modernization for the cloud? The answer lies at the crossroads of repeatability, automation, and near-term value.
In this post you will learn:
- Companies lack the resources or expertise to execute application modernization for the cloud
- Simplifying application modernization enables repeatability
- Automation has a multiplier effect on repeatability and time to value
Q: Why does Azul emphasize “simplifying” application modernization right now?
Partners are gravitating to opportunities with clear propensity and fast time to value because many customers lack the resources or the expertise to do this themselves:
- Anything with ITAM
- Security tool consolidation
- Vulnerability assessments
- Incident response
- Artificial intelligence
- How can I get AI running?
- What’s a good use case?
- What sorts of expertise do I need to build an AI learning model?
Application modernization is also consistently near the top of that list, provided there’s a compelling business case.
So when I think about Azul and our channel, we’re only really talking about three high-propensity swim lanes:
- Replacement of Oracle to Azul Platform Core.
- Compliant, secure Java infrastructure with Azul Intelligence Cloud.
- Identifying application workloads that can be modernized with Azul Platform Prime. At a minimum, this means re-hosting to a high-performance Java platform, Azul Platform Prime.
Let’s focus on application modernization.
Now, the second part, after this list of high-propensity opportunities to go after, is the ability to deliver a service. Most of our partners are involved with value-added delivery, so I think they see modernization as both a high-propensity theme and a great opportunity to provide a range of value-added services. Our goal is to give partners a play that’s easy to explain, quick to start, and delivers tangible value without dragging them into months of bespoke services work. This all saves time and money for customers.
Q: Where should partners start?
I frame modernization around the well-known four R’s:
- Re-architect,
- Re-platform
- Re-host
- Re-factor (or re-design)
Then zoom in on re-hosting or re-platforming as the primary focus. That’s where we can prove value fast with minimal disruption. We begin by understanding the nature of the application, where it runs today, and the potential performance gain from moving it somewhere else and running it on Azul Platform Prime. That performance gain translates very directly into cost and capacity benefits – fewer cores, fewer pods, better autoscaling – so you can quantify the impact early and keep stakeholders aligned. What’s better than a strong ROI?
Q: What does a “simplified” application modernization path look like?
It’s a focused approach built for repeatability. We target common Java frameworks – Kafka, Spring, Cassandra, Spark, Elastic/Solr, Tomcat, Lucene, Hadoop – because that’s where partners see the most repeat use cases. Depending on the workload and the move, we typically see performance improvements in the 10–50% range when running on Platform Prime. The partner motion is:
- Identify the legacy workload
- Position re-hosting
- Run a short pilot to validate performance gains from Platform Prime
- Scale that same pattern across similar apps. The more they do it, the more “memory muscle” they build and the quicker each subsequent motion becomes.
Q: How does Azul de-risk the performance promise?
Establish a baseline, pilot, and measure. We never “assume” the gain. We prove it. The first step is capturing current performance and cost metrics for the Java service in scope. Then we run a contained pilot in the target environment to validate the uplift. Once the numbers are in hand, the business case sells itself and the rollout becomes a straightforward execution plan rather than a leap of faith.
Q: Where does automation fit into this?
Automation is the multiplier. There are usually a lot of small, tedious steps to get an application into a given compute framework. With the right tooling, we can compress that into a simple sequence – namespace, configuration, upload, deploy – and then move immediately into optimization.
I’m particularly interested in new automated deployment technologies like Payara and Smart Migrator that aim to handle the bulk of those steps. We recently announced a strategic partnership with Payara to jointly power high-performance Java deployments and codeless migrations with Azul Platform Prime plus Payara Qube. Qube is automated deployment technology which can take a packaged application and auto-deploy it into a particular cloud environment, doing 90% of the tasks. You just find the namespace, upload, and deploy, and then monitor and optimize. It’s very efficient. This is directly in line with our goal to provide partners with package solutions that they can provide high-value services around without having to become deep Java experts to deliver value.
Q: How does this align with the hyperscalers – especially AWS?
Very naturally. AWS has its Migration Acceleration Program (MAP) within the Amazon Partner Network, and the framework lines up well with this motion. If we can standardize on the Java frameworks where we have high propensity and layer in credible automation, we can meet Amazon’s set of criteria that then unlocks significant funding that can go to the partner as profit to accelerate the movement of that application into Amazon. That makes the customer’s path clearer and helps the partner turn a repeatable modernization pattern into a funded, outcomes-driven program instead of a one-off project.
Q: Final takeaway for partners considering this path
The ingredients are already on the table: a clear re-hosting first motion, a short pilot to prove performance and cost outcomes, and automation to remove friction. When you package those pieces into a playbook and run it against the right Java workloads, modernization stops being an open-ended “project” and becomes an efficient, evidence-based program you can scale.
