devopsy.kinsta.cloud

Tag: modernization

Modernization Is Not Migration

Modernization used to mean something simpler: Move the workloads, update the tooling, declare the project done. In practice, that approach meant engineers manually migrating hundreds of DataStage jobs one at a time — a process that was slow, error-prone and impossible to scale as platforms grew. The traditional model worked when volumes were low. It broke entirely when weekly release windows started carrying 500 jobs and the only way through was brute-force manual effort.

What changed the equation was not just cloud infrastructure, but a fundamentally different operating model. When a CI/CD-based promotion mechanism replaces manual steps — reducing what once required hours of coordinated effort down to a single parameterized execution — hundreds of jobs could migrate consistently, with less human involvement and a verifiable audit trail. That shift exposed a harder truth: The technology was never the bottleneck; the operating model was.

That distinction matters more than most modernization programs acknowledge. In regulated financial environments, a single poorly governed release, an undetected performance bottleneck or a monitoring gap that cannot identify which of hundreds of running jobs is consuming abnormal resources can cascade into compliance failures, SLA breaches and production incidents that take hours to diagnose. Migration moves workloads. Modernization changes how those workloads are released, observed and recovered. Organizations that confuse the two end up paying cloud prices for legacy-era operational risk.

The Release Bottleneck: Scale Exposes What Manual Processes Cannot Sustain

The scale problem became undeniable on Thursday release windows. With roughly 500 DataStage jobs queued for migration each week, a single Jenkins server connected to a Windows host via known_hosts authentication would spend close to two hours sequentially placing files from commit IDs into DataStage directories, then waiting on compilation and promotion to complete. The process was not broken. It was simply not built for the volume it was being asked to carry.

The fix was horizontal scaling applied to the migration layer itself. Three dedicated Windows migration servers — MIG servers hosted on OSV — were introduced to split the job queue and run promotion concurrently across all three nodes. Jenkins triggers the build, establishes the known_hosts connection and Git commands distribute the committed file changes across the MIG servers in parallel. Each server handles its share of the queue independently. Bulk migration dropped from two hours to 45 minutes. The same Thursday release window that previously consumed an entire afternoon now closes before the first standup of the day.

The architectural lesson is transferable. What looked like a tooling problem was a throughput problem, and the solution was treating the migration layer the same way any bottlenecked data pipeline gets treated: Parallelize it. Governed CI/CD pipelines with commit-level traceability, parameterized environment targets and approval gates tied to security groups and change records are not overhead. They are what make a high-volume, audit-ready release possible at enterprise scale.

The Observability Gap: Prevention Without Detection is Incomplete

The symptom was a network breakdown on OSV servers under load. The cause, once we could see it, was partition skew — DataStage jobs with uneven data distribution hammering specific nodes while others sat idle, driving CPU utilization past sustainable thresholds with no way to identify the responsible job until the platform was already in distress. With thousands of jobs running concurrently, the existing monitoring told us the cluster was under pressure. It could not tell us where to look.

This is one of the most underestimated failure modes in enterprise cloud modernization. When data traverses a network for distributed processing, uneven partitioning concentrates compute demand on a subset of nodes. Jobs that were not properly partitioned surge CPU instantly. Infrastructure monitors like Dynatrace surface the result — CPU utilization exceeding 90% — without surfacing the identity of the job causing it. The gap between the alert and the answer is where incidents live.

The solution is to build a second observability layer beneath the infrastructure monitor — one designed around job identity rather than cluster state. In one financial data platform implementation, a DB2 pipeline table was constructed to capture operational metadata directly from the DB2 server at the job level: Job name, volume of data processed, number of CPUs consumed, percentage of CPU utilization and execution timestamp. This metadata is ingested on a scheduled cadence into a BigQuery stats table, where it becomes queryable alongside the rest of the platform’s operational data.

On top of that stats layer, Looker reports run on an hourly schedule and apply a threshold rule: Any job with CPU utilization above 90% is flagged in red and triggers an automated notification routed directly to the responsible production support team and the L6 engineering escalation group. The alert is no longer ‘the cluster is hot’. It is ‘job X on node Y consumed Z CPUs at 02:23 p.m., processed N records and has now exceeded the threshold three cycles in a row’. That is the difference between a signal that opens a bridge call and one that closes an incident in minutes.

This architecture — infrastructure monitor surfacing the symptom, job-level telemetry pipeline identifying the cause, scheduled reporting enforcing the threshold and automated routing engaging the right team — is what targeted observability looks like in a regulated production environment. It turns performance management from an operations burden, reliant on institutional memory and manual log trawling, into a data-driven engineering discipline. The platform can now explain its own behavior under stress. That is what operational maturity requires.

Modern Regulated Data Architecture: Design for Operations, Not Just Delivery

In regulated financial data platforms, architecture should be evaluated not only by how data moves, but by how reliably the platform can be operated. A layered ingestion model may move data from upstream financial systems into cloud storage and processing tiers, with transformation logic in intermediate layers and curated exports sent to downstream reporting and compliance systems. But architecture alone does not create operational confidence.

What distinguishes a resilient platform is the operational layer around it: Automated promotion across environments, governed release controls, telemetry pipelines that capture workload behavior at regular intervals, cloud cost thresholds tied to workload patterns, schema management discipline and clearly documented recovery paths for production incidents.

Without these investments, cloud migration often produces familiar post-go-live problems: Unexplained cost spikes, slower incident response and audit trails that appear acceptable for delivery but fail under regulatory scrutiny. Architecture decisions matter. Operational discipline matters just as much.

Conclusion

Modernization worked only if the platform became easier to change, easier to understand and safer to run under pressure. That is not a philosophical position — it is a measurable one. The clearest proof is not an architecture diagram but a before-and-after comparison any leader can read: The same migration task that previously required manual coordination across multiple engineers now executes with a single trigger, no human intervention and a full audit trail. When execution moved from VM-based infrastructure to OSV servers, compute costs dropped by 40%. When the migration layer was parallelized across three nodes, Thursday release windows shrank from two hours to 45 minutes. When job-level telemetry was built on top of infrastructure monitoring, incident response stopped depending on who happened to know which job was misbehaving.

These are not modernization claims; they are modernization receipts. The organizations that will lead the next phase of cloud data platform maturity are the ones that can show their work — not just describe their architecture, but produce the cost curves, the time comparisons and the incident response metrics that prove the operating model actually changed. Cloud platforms are not modern because they run on managed infrastructure. They are modern when the numbers say so.

June 26, 2026
Autonomous AWS Agent Automates Modernization of Codebases

Amazon Web Services (AWS) today made available a preview of an artificial intelligence (AI) agent that has been trained to continuously modernize codebases.

Announced at the AWS New York Summit, the AI agent is being embedded into AWS Transform, the application modernization service AWS launched last year.

Sriram Devanathan, director of AWS Transform, said the autonomous AI agent added to the service will, unlike existing agents, asynchronously execute tasks such as remediating code or analyzing technical debt.

AWS Transform automatically scans your code repositories against configurable baselines and generates findings in hours. Policies for detecting end-of-life dependencies, deprecated frameworks, and other common sources of technical debt are already embedded. If a DevOps team has deprecated an internal library or prefers a particular logging pattern, it can be codified as a policy that runs continuously across code repositories. Once an issue is detected, AI agents will autonomously generate pull requests to remediate any affected repositories automatically.

DevSecOps teams can also extend those policies to their own specific remediation patterns, including approved libraries, internal coding standards, or custom technical debt policies they have internally developed. AWS Transform also integrates with the AWS Security Agent to detect and remediate security vulnerabilities at the source-code level, so security findings flow into the same prioritized list and pull-request workflow alongside other analysis of technical debt.

More than 4.5 billion lines of code have already been analyzed and modernized via the AWS Transform service, said Devanathan. In the wake of recent reasoning advances made by frontier models such as Mythos from Anthropic, the level of interest in modernizing codebases to eliminate vulnerabilities has increased sharply in the last few weeks, he added.

Organizations have already been using the AWS Transform service to automate everything from upgrading codebases from one version of Java to another to rewriting legacy code in an entirely different language, noted Devanathan. In the agentic AI era, those efforts will span much more complex initiatives that previously would have required a year or more for a small army of application developers and software engineers to complete.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said the constraint moves from generating fixes to confirming that autonomous pull requests preserve business behavior at scale. The authority granted these agents stays bounded by how well teams can verify that continuous remediation does not quietly change what the application does, he added.

It’s not clear to what degree organizations are modernizing existing applications versus replacing them with software that is becoming simpler to build in the agentic AI era. Regardless of approach, the amount of technical debt that many DevOps teams should address is massive.

Historically, the issue is that every minute spent resolving those issues is one less minute that has been available to develop a new application or add features to an existing one. However, in the agentic AI era, it’s clear the fundamental equations used to determine whether it is cost effective to modernize an application now need to be reevaluated.

June 17, 2026
What a ‘Good Plan’ Really Means for AI Coding Agents
AI coding agents have made it trivial to get from an idea to a working prototype. Generating boilerplate, wiring up services or sketching out a feature is no longer the hard part. The difficulty shows up later, when that code  has to  survive contact with a real system and real users. 

At that point, failures rarely come from the agent’s ability to write code. They come from something more basic. Nobody was fully aligned on what was being built, what ‘done’ actually meant or how the work was supposed to unfold. The agent fills in the gaps — it always does. The result is familiar: Overwritten tests, skipped edge cases and features that technically work but  don’t  solve the problem they were meant to address. 

As AI-assisted development matures, teams start noticing a pattern. Better prompts help, but only up to a point. The difference between code that ships and code that gets reverted is usually the quality of the plan behind it. Prototypes tolerate ambiguity, but production systems don’t. 

From working with agentic systems in real environments, four traits keep showing up in plans that actually hold. 

Objectives Need a Finish Line 

Humans are comfortable with loose goals. ‘Add authentication’ sounds fine in a meeting. An AI agent hears something else entirely. It has permission to decide what authentication means when  it’s  complete and how much effort is enough. 

When success isn’t clearly defined, agents optimise for signals that look like completion. A clean diff. A confident explanation. Something that compiles. Those signals are cheap to satisfy and easy to mistake for correctness. 

Compare the two: 
- Add authentication 
- Implement JWT authentication with 15-minute access tokens, refresh-token rotation and middleware that returns 401 responses for expired or invalid tokens 
The difference  isn’t  verbosity;  it’s  testability. 

A simple check helps here. If you can’t imagine how a reviewer or a test would clearly answer ‘yes’ or ‘no’ to whether the objective was met, the objective isn’t ready. Vague goals  don’t  just confuse agents; they invite shortcuts. 

Structure Isn’t Enough — Tasks Have to be Runnable 

Breaking work into smaller pieces is nothing new. Most teams already do this, often with tidy hierarchies of initiatives, epics and tasks. This structure helps people reason about scope, but it  doesn’t  guarantee that an agent can actually do the work. 

A task like ‘improve the authentication system’ fits neatly into a plan and still leaves every important decision unresolved: Which files change? Which behaviour is expected to change? What assumptions are safe to make? 

When those details are missing, agents either stop and ask questions endlessly or move forward on guesses. Neither  scale. 

Tasks that work are boringly specific. They spell out  what’s  in scope, what depends on what, which parts of the codebase are involved and how success will be judged. That’s not ceremony; that’s what turns intent into something executable. 

Validation  Can’t  be an Afterthought 

Language models are  very good  at sounding sure of themselves. They are much worse at knowing whether something actually works. Anyone who has watched an agent confidently declare success on code that doesn’t run has seen this firsthand. 

In single-step tasks, that’s  annoying. In multi-agent systems, it’s  dangerous. One unchecked assumption becomes input to the next step, and errors spread quietly until the system behaves unpredictably. 

The fix  isn’t  perfect verification; it’s  discipline. Each step needs  a clear way  to prove it worked before anything downstream relies on it. If you can’t say how you’ll check the result, you shouldn’t automate the step. 

Validation gates feel slow until you see what happens without them. 

Plans Have to Change Without Resetting Everything 

No plan survives implementation unchanged. Constraints surface. Priorities shift. Something that looked simple turns out not to be. What matters is what happens next. 

Some teams lock plans down and force execution anyway. Others abandon the plan entirely and fall back to ad hoc prompting. Both approaches throw away useful context. One is rigid and the other has amnesia. 

Good plans evolve. They keep  what’s  been learned and adjust what needs to change. Replanning shouldn’t mean starting over. It should mean refining the map as the terrain becomes clearer. 

Why This Becomes Critical at Scale 

AI agents execute quickly — that’s their strength. It’s also why weak planning hurts so much. 

When execution is fast, mistakes compound faster, too. Context gets lost. Small misunderstandings turn into structural problems. The system  doesn’t  fail loudly; it drifts. 

Speed alone  isn’t  the metric that matters anymore. The bottleneck has moved. It’s  no longer typing or even generation — it’s  clarity. 

Planning is the Interface Now 

In human teams, planning aligns people before work begins. In agentic systems, planning plays a similar role, but  it’s  closer to an interface than a meeting artifact. It’s how intent becomes something machines can follow without improvising. 

Some tools are beginning to treat planning, validation and replanning as first-class engineering concerns rather than an informal setup. Artemis is one of the examples. But the point  isn’t  any specific platform — it’s  the shift itself. 

When execution is cheap, direction is everything. 

The teams that get this right won’t just move faster, they’ll ship systems that still make sense a few months later, and that’s still the hard part. 
February 18, 2026
Modular & Shift-Left Observability for Modern DevOps Pipelines
In today’s fast-paced software development environment, observability has become a cornerstone of successful DevOps practices. However, observability is no longer just a background monitoring feature added after installation; It evolves into a core modular component that should be integrated early in the DevOps process, a practice known as shift-left observability. This approach enables teams to build more flexible, cost-effective, and compatible systems from the ground up, especially in complex, distributed, and stateless cloud environments.

What Does Shift Observability Mean?

Shift-left observability means that observability issues should be addressed early in the development phase, rather than waiting until the application goes live. This includes integrating telemetry (logs, metrics, traces), instrumentation and monitoring generation capabilities into code and process phases such as build, test, and continuous integration. This gives developers real-time insight into how their code behaves not only in production, but also during deployment and testing.

The Power of Modularity in Observability

Treating observability as a modular component means designing it as a set of independent, reusable building blocks that can be connected or updated independently through service phases and pipelines. This module is compatible with microservices and cloud principles, so teams can scale, upgrade, and customize monitoring tools without affecting other parts of the stack. Modules can include tool libraries, alert rules, data collectors, and visual dashboards designed to work seamlessly together.

Advantages of modular and left-handed observability in DevOps processes
1. Increase developer productivity and provide faster feedback
By engaging in early monitoring, developers receive immediate feedback on code quality, performance, and potential issues during the testing phase. Additionally, this prevents costly late-stage debugging and accelerates development cycles.
1. Proactive detection of production and pre-production issues
Left-shift observability detects bottlenecks, failed integrations, and scalability issues long before production begins. Teams can use synthetic monitoring and automated telemetry to address vulnerabilities proactively.
1. Support for stateless infrastructure and dynamic environments**
Modern cloud-native applications often run in containers and serverless functions that often spin up and down. Guess what? Modular observability components can be dynamically attached to these short-lived instances, ensuring continuous monitoring without manual reconfiguration.
1. Cost efficiency through targeted data collection
Standard observability allows teams to define what data to collect and retain at each stage of the process. This prevents data overload and reduces storage costs by focusing only on metrics that are relevant to the current stage of development or deployment.
1. Improve compliance and security
Integrating observability and compliance rules helps detect configuration discrepancies, unauthorized changes, or policy violations early in the process. Automated supervisory checks can continuously enforce governance policies, reducing audit risk.
1. Simplified processes and flexible tool chain
The modular architecture is in line with DevOps best practices, allowing for the integration and independent development of the best monitoring tools. This flexibility prevents vendor lock-in and simplifies upgrades.

Some of the best observability tools include Grafana, Middleware and Honeycomb.

Implementation of Standard Shift-Left Observability

– Start early with hardware libraries: Encourage developers to include standard telemetry libraries in their code during initial development.

– Embed observability into CI/CD processes: Integrate telemetry validation and monitoring steps into automated tests and build phases.

– Leverage the microservices architecture: Create observables as independent, reusable modules that can be deployed with the microservices in question.

– Configuration Management Automation: Use infrastructure as code to enable monitoring settings, alerts, and dashboards to meet compliance requirements.

– Open Standards Adoption: Use OpenTelemetry and other tools to ensure interoperability and open standards for easy integration.

– Continuously evolving monitoring capability modules: Modules are regularly updated to add new capabilities, improve data efficiency and adapt to changing environments.

Conclusion

The possibility of standard and left observation is not just a technical development; it’s a cultural and architectural shift, a shift that enables DevOps teams to build more reliable, scalable, and secure software. By building observability early and making it a standard, integral part of the DevOps process, organizations can gain deeper insights, reduce downtime, manage costs more efficiently, and maintain compliance in complex distributed ecosystems. It’s an investment in a vision that pays off over the software delivery lifecycle.

This approach is crucial for modern cloud-based organizations striving to remain nimble and innovative in an increasingly competitive market.
November 24, 2025
Explanation First, Then Code Conversion: A Practical Guide to Mainframe Optimization
Before you even think about code conversion, take a closer look at what you have—and let generative AI (GenAI) help you explain it. Here’s how to modernize your mainframe smarter, not just faster.

The Real Challenge: Understanding Decades-Old Practices and Code

If you’ve worked with mainframes for any length of time, you’ve seen it before: someone in the boardroom gets excited about “digital transformation,” reads a story about AI rewriting COBOL overnight, and suddenly there’s an urgent call to “move everything to the cloud.” But here’s the thing—mainframes aren’t relics, and the problem isn’t the platform. It’s the technical debt we’ve accumulated and the assumptions we make when we talk about modernization.

Mainframes are, in fact, among the most modern, reliable, and secure platforms in existence. The real challenge lies in the decades-old practices, spaghetti code, and institutional knowledge gaps that have built up over time. And that’s what makes the dilemma of COBOL-to-Java conversion so tricky: what should move, what should stay, and what’s the smartest path forward?

Let’s walk through a more balanced—and practical—approach to mainframe modernization, one starting with understanding and values explanation over blind translation, harnessing the power of GenAI to make the journey faster and safer for everyone involved.

Why Mainframes Are Still Mission-Critical

Despite what the “legacy” label might suggest, mainframes remain the gold standard for reliability, security, and transaction volume. Banks, insurance companies, healthcare providers, and governments depend on them every single day. They process billions of transactions, scale on demand, and deliver “five-nines” uptime that most cloud platforms can only dream of.

But let’s be honest: the way many mainframe applications have evolved—layer upon layer of updates, urgent patches, and undocumented quick fixes—has made them harder to manage. The problem isn’t COBOL, the language is fine and easy to learn and work with; the problem is what we’ve done with the COBOL, its original architecture and the technical debt created by years of business-driven expediency.

The Code Conversion Dilemma: Move, Modernize or Leave Alone?

When it comes to mainframe modernization, there’s a natural temptation to see “COBOL-to-Java” as the one-way ticket to a brighter future. After all, Java skills are plentiful, Java tools are modern, and the cloud-native world loves Java. But that doesn’t mean every mainframe application should—or even can—be converted wholesale.

Some applications thrive on the mainframe. They’re stable, rarely change, and benefit from the platform’s unique strengths. If they’re meeting business needs and running reliably, trying to move them off the mainframe may introduce more risk than reward.

On the flip side, some workloads absolutely need to change fast, integrate with modern APIs, or scale horizontally. Here, code conversion or migration can unlock flexibility and accelerate digital transformation. The trick is knowing which is which—and having the discipline to act with intention, not impulse.

Don’t Start with Translation—Start with Understanding

Here’s where too many projects go off the rails: jumping straight to code conversion without first understanding what the code actually does. Mainframe systems often resemble a decades-long game of telephone—patched by generations of developers, with business logic buried under mountains of procedural code. Sometimes, the original authors have long since retired, and the documentation is cryptic (if it exists at all).

Before You Touch a Line of Code, You Need a Map.

That starts with inventorying your applications and their dependencies. What modules do you have? How do they interact? Which business processes do they support? And—crucially—which parts of the codebase are actually still in use?

Visualization tools can help, letting you “x-ray” your environment to see data flows, dependencies, and forgotten dead code. But even with great tooling, you’ll need to extract and document the business logic—the real “why” behind every routine and module.

Code Explanation vs. Code Translation: Why It Matters

Let’s make a key distinction:
- Code Explanation is about making legacy code understandable—turning cryptic COBOL into plain English so current and future teams know exactly what’s happening and why.
- Code Translation is about rewriting that code into a modern language—COBOL to Java, for example.
While translation grabs headlines, explanation is where the real magic happens. It’s about knowledge transfer: bridging the gap between decades of lost documentation and the future of your IT workforce. Without a clear explanation, translation risks turning one tangled mess into another—just in a different language.

Documentation and visualization are vital here. Good explanation—whether created by human experts, AI-powered tools, or both—enables:
- Faster onboarding of new developers
- Fewer bugs and less risk during conversion
- Easier future enhancements and troubleshooting
Refactor Before You Rewrite

Here’s a pro tip that can save months (and sanity):
Don’t just translate COBOL to Java line by line. If you do, you’ll wind up with Java that’s just as convoluted as your old COBOL—only now it’s harder to debug because your Java team didn’t write it.

Instead, treat this as a once-in-a-generation chance to refactor before the conversion. Clean up logic, modularize code, eliminate dead weight, and clarify intent before you begin translation. You’ll thank yourself later when your new Java application is actually maintainable.

Generative AI: Accelerating (But Not Replacing) Human Expertise

Generative AI is changing the game, especially in code explanation and (to a degree) translation. Stories like Morgan Stanley’s headline-grabbing AI-powered modernization show the promise—and the reality—of what’s possible.

But here’s the big lesson: AI can’t replace the need for human expertise and business context. It is a tool that can automate some tasks to save time. Even the best AI can get you to a “working” translation, but human developers must validate, refactor, and optimize the results for efficiency, security, and compliance.

Where GenAI shines:
- Automated code explanation: AI models can rapidly generate plain-language descriptions for modules, making lost business logic visible again.
- Code visualization: AI-powered tools can map dependencies, call graphs, and data flows, giving teams an actionable blueprint.
- Accelerated translation (with guardrails): AI can handle the bulk translation, but it’s up to the team to review, refactor, and ensure the result is “Java as a Java developer would write it.”
Crucially, GenAI brings flexibility. Some teams may use custom-trained models to reflect their unique codebase and business logic; others may rely on curated public LLMs or on-prem solutions for compliance. The smartest organizations use a mix—always keeping humans in the loop.

Finding the Balance: What Stays, What Goes?

The “all or nothing” mindset—either move everything off the mainframe or keep it all as-is—just doesn’t hold up. The most successful organizations assess each workload on its own merit:
- Stays on mainframe: Ultra-high reliability, security, or compliance needs; rare updates; existing skills available.
- Moves to modern platform: Needs rapid iteration, cloud integration, or agility; technical debt is high; Java or modern language skills are abundant.
Remember: the goal isn’t to chase trends, but to optimize for your organization’s real-world needs.

A Checklist for Smarter Modernization

Based on what works for leading enterprises (and what’s tripped up even the best teams), here’s a practical checklist for mainframe code conversion success:
1. Inventory all applications and their dependencies—don’t leave room for surprises.
2. Visualize code and data flows; identify dead code to retire.
3. Extract and document business logic in plain English—use GenAI to help, but validate with experts.
4. Refactor for clarity and maintainability before any translation begins.
5. Assess security, compliance, and audit requirements for both source and target environments.
6. Pilot automated translation on low-risk modules; learn and adjust before tackling mission-critical systems.
7. Test rigorously: unit, regression, and performance tests are non-negotiable.
8. Train your teams on new tools and languages—make the developers comfortable with them so they are part of their daily work.
9. Tune for long-term maintainability and performance in the new environment.
10. Govern the entire process, from policy to documentation updates.
11. Engage business stakeholders early and often—business context is essential for prioritization.
12. Iterate and improve—modernization isn’t a “one and done” project.
The Human Factor: Still the Secret Ingredient

No matter how advanced your tools, human expertise and business insight are irreplaceable. AI can speed up understanding and translation, but only people can validate, contextualize, and steer modernization in the right direction. Involve your domain experts, engage the business, and treat modernization as a team sport.

Explanation First, Then Transformation

Mainframe modernization isn’t about abandoning a “legacy”—it’s about transforming your organization’s most critical assets for the future. Start with explanation and understanding. Use GenAI to illuminate what’s hidden, bridge knowledge gaps, and accelerate the journey. But keep your eyes on the real goal: delivering business value, reducing risk, and empowering the next generation of technologists.

Don’t let buzzwords or bandwagons rush you into a code conversion project. With the right preparation—and a healthy dose of human judgment—you’ll find the balance that works for your business, now and for years to come.

Want to share your modernization story or compare notes? Let’s keep the conversation going. Mainframe isn’t just part of the past—it’s a vital platform for the future, and we get to shape what comes next.
June 27, 2025
Survey Surfaces Depth of Mainframe Application Migration Challenges

A global survey of 309 decision-makers responsible for modernizing mainframe applications finds that while 69% of respondents said the initiatives are either very or extremely important for enabling their organizations to achieve their business objectives, only 18% of the budget allocated for these projects is being used to specifically modernize or rewrite those applications.

Conducted by Forrester Consulting on behalf of Rocket Software, more than half of respondents (51%) report their organization has, following multiple failures, attempted at least six rewrite projects.

The survey also notes that only 17% are focused on transforming applications on the mainframe by implementing and exploiting the most modern features available on the platform.

Just over a quarter (27%), however, are removing applications from the mainframe in favor of hosting them using cloud platforms and/or another distributed computing environment. Well over half (56%) are integrating mainframe applications with applications that have either moved to the cloud or were originally developed and deployed in the cloud, the survey finds.

Phil Buckellew, president of the Infrastructure Modernization Business Unit for Rocket Software, said there is more focus on integration rather than rewriting or migrating mainframe applications, simply because of their size and complexity. Many of those applications were also developed by individuals who are no longer with that organization and documentation available is often limited, he added.

Nearly three-quarters of respondents (74%) did note they are methodically planning to use AI to accelerate their modernization efforts. Additionally, 67% said their strategy includes a lot of experimentation and learning as it goes, with 66% reporting AI has already made them more efficient.

However, 35% also said ungoverned AI has led to significant loss of revenue and/or delayed initiatives.

In general, the survey finds half of respondents (50%) said mainframe modernization efforts are being led by IT teams, but 42% also said the strategy was being driven by those at the C-level in their organization. Nearly half (49%) said there is also a need for greater alignment between the business and IT.

The single biggest mainframe application modernization issue organizations encounter is, not surprisingly, security and risk concerns (41%), followed by a lack of talent/skills (38%). Additionally, 34% were challenged by complex integration strategies, while around 31% were burdened by inadequate software tools/platforms. A total of 30% also cited ungoverned use of new technology such as artificial intelligence (AI).

On the plus side, 45% are upskilling and training employees, while 41% are investing in new technologies to drive innovation. A total of 40% are also investing in various partnerships to achieve that goal.

Those partnerships are crucial because most IT organizations don’t have a lot of experience modernizing mainframe applications, noted Buckellew. Capabilities sought from partners include code and data modernization (83%), DevOps expertise (79%), open-source compliance (78%), knowledge of agile application development and low-code tools (75%), structured and unstructured data management (74%), vulnerability management (71%) and AI and automation (70%).

Modernization initiatives will differ substantially from one organization to another and it’s not precisely clear how AI might accelerate them but the one certain thing is more organizations than ever will be once again revisiting their mainframe application strategy in the months ahead.

October 4, 2024
Four Ways to Modernize Your Enterprise Monoliths

In a perfect world, every application would run like Netflix–by which I mean every application would be cloud-native, microservices-based, containerized and, in all other senses of the word, modern. Unfortunately, not every application can be transformed in these ways. Some of the most important enterprise applications–like those powered by SAP or Oracle–don’t lend themselves to architectural transformations simply because the vendors don’t support that strategy. As much as organizations might wish that they could re-architect legacy apps from the ground up, the reality is that they just can’t.

Fortunately, though, all hope is not lost if you have an enterprise app that you can’t containerize or “microservices-ize.” Even if you can’t “break down your monolith”–to quote the standard advice you’ll find if you read articles about how to modernize legacy apps–there are a variety of practical steps you can take to make legacy, monolithic applications look and feel (in most respects) like modern, cloud-native apps.

Here are four ways to make your enterprise monolithic apps more cloud-friendly, even if they’re not technically cloud-native.

Use Cloud Automation to Modernize Legacy Application Management

Most enterprise apps are compatible with the cloud in the sense that you can host them on cloud-based virtual machine (VM) instances using services like Amazon EC2.

By taking advantage of cloud hosting for enterprise apps, organizations can also leverage cloud automation tools, such as autoscaling policies and rules that automatically start or stop VMs. In this way, it becomes possible to deploy enterprise apps in a highly scalable, automated way. You get something that resembles Kubernetes-based orchestration, except your apps don’t actually run in containers on top of Kubernetes. They’re just monoliths that benefit from cloud automation tools.

Deploy Load Balancers to Optimize Performance

Load balancers, which automatically manage network traffic flowing to and from applications, are another critical tool that organizations can easily leverage when they migrate legacy applications to the cloud.

Although configuring load balancers for enterprise apps hosted in the cloud is not a strict requirement, doing so can substantially improve application performance and reliability because load balancers help to ensure that requests are directed at application instances best able to handle them. They prevent situations where one instance of your application is overwhelmed with traffic while another sits idle.

Again, this is something that platforms like Kubernetes also do for microservices apps. But, as I’ve explained, you don’t actually need your app to run as microservices to take advantage of load balancing. You can do it with monolithic legacy apps, too.

Adopt an Everything-as-Code Strategy

When your app lives in the cloud and is managed by cloud automation tools, it becomes possible to manage most aspects of application operations via code. Specifically, you can:

● Use infrastructure-as-code (IaC) tools to automate infrastructure provisioning and setup.
● Automate application configuration management using code rather than applying configuration changes manually.
● Codify operational processes, such as application updates and backups, instead of relying on manual operations.

Practices like these, which enable a strategy known as everything-as-code, significantly reduce the amount of time and manual effort that engineers spend managing applications. They also provide consistency and minimize the risk of errors due to human oversight. And there’s no reason why you can’t leverage these practices for legacy apps as well as modern ones.

Integrate Legacy Apps With Modern Toolchains

If your enterprise app is hosted on-premises, you probably manage it using tools and processes designed solely for it. But when you move an enterprise app to the cloud, it becomes possible to manage the application using the same integrated toolchain you deploy for other applications and processes.

You can, for example, take advantage of cloud-based monitoring tools to continuously collect data about application performance and generate automated alerts when something is wrong. Likewise, you can regularly create image-based backups of your application.

This toolchain-based operational strategy is another way to streamline enterprise application management, even in situations where you can’t rewrite or containerize the application itself.

Conclusion: Getting More From Legacy Apps

Just because you have a legacy enterprise app that you can’t transform into microservices doesn’t mean you have to settle for legacy management and operational practices. Modern automation tools combined with modern operational strategies like everything-as-code make it possible to achieve an enterprise application management experience that closely parallels that of fully modern, cloud-native apps, regardless of which architecture your app actually uses.

June 15, 2023
More Java Apps Are Migrating to the Cloud

A survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, found that, as part of modernization efforts, the pace at which Java applications are moving to the cloud is now accelerating.

The survey found more than one-third (36%) of Java applications are already deployed in the public cloud. More than half of respondents (56%) are also already deploying some of their Java applications into Kubernetes or serverless environments. Nearly two-thirds (63%) said they planned to move more Java applications to the cloud over the next 24 months, the survey also found.

Kim Weins, vice president of product and marketing at Vaadin, said the survey makes it clear that enterprise IT organizations are still highly committed to Java. Still, there is a clear shift underway in terms of where those applications are being deployed. More than a third of respondents (35%) said they have Java applications deployed on Amazon Web Services (AWS), while 22% have deployed them on the Microsoft Azure Cloud. Another 11% are running them on the Google cloud platform.

This shift, however, will take time. Almost half (47%) of Java applications still need modernization. As a result, 63% of respondents planned to increase their investments in modernizing existing Java applications.

Maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%), the survey found.

The top three challenges in developing Java applications are building an intuitive and simple user interface (81%), upgrading the tech stack (81%) and ensuring app security (78%).

There is also a shift underway in terms of the frameworks used to build and modernize applications using a more cloud-native approach. A full 70% of respondents use Spring today, but 50% also noted they are planning to increase their use of Spring Boot. Other Java frameworks used include Vaadin Flow, Quarkus, Hilla and React. While derivatives of Spring are the dominant framework, it appeared more organizations are at least evaluating other options, noted Weins.

Most organizations are also integrating Java applications with modern tools for logging (72%), observability (61%) and single sign-on (53%), the survey found.

The shift to Java 17 is also well underway, with nearly three-quarters of respondents (73%) using or planning to use it over the next year. More than a quarter (26%) are already on Java 17 or a later release. Another 21% are currently upgrading, while 26% plan to update in the next 12 months.

Overall, the survey found Java is being widely used for both internal (64%) and customer-facing (62%) applications. Java is most often used to build full-stack Java apps (70%) and backends (69%), the survey found

Finally, the survey found more than a third of respondents (38%) expected that finding and retaining developers would be a significant challenge in 2023.

There are, of course, no shortage of options when it comes to deploying Java applications. Most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a venerable programming language that itself has been modernized.

February 15, 2023
Busting 5 Common Database Modernization Myths
Modernizing databases is one of the best ways to improve database and application performance. However, many companies are hesitant to make major changes, even if they could lead to better outcomes. Why? Because there are prevailing myths about how database modernization projects fail to deliver on expectations. Five myths, in particular, seem to hold leaders back from pursuing modernization opportunities. We cover each of these myths in detail below:

Myth One: There is little performance benefit to modernizing databases in the cloud

Myth Two: Cloud databases won’t reduce my IT costs

Myth Three: I’m better off leaving my data on-premises for security and availability reasons

Myth Four: There’s not much I can do in cloud databases that I can’t do on-premises

Myth Five: Commercial databases aren’t compatible with cloud databases

Fortunately, we’ve debunked these database modernization myths and can speak to the incredible benefits of modernizing databases on the cloud. We’ll use Amazon Web Services (AWS) cloud, specifically, as an example here, as it is a commonly used option for boosting database performance and innovation.

Myth: There is Little Performance Benefit to Modernization of Databases in the Cloud

Modern cloud computing technology has advanced tremendously in recent history. With this advancement comes loftier expectations around database performance. And the truth is commercial databases are falling behind.

Commercial databases are less scalable overall. They can struggle with latency issues, especially when supporting modern applications. Plus, finding enough processing power can be a challenge. Companies are still dealing with chip and RAM shortages related to ongoing supply chain disruption.

Cloud providers, on the other hand, haven’t suffered as much. They buy components in bulk and have an overwhelming amount of equipment, infrastructure and memory for running cloud databases. Who benefits from this accessibility? Companies that have traded their on-premises infrastructure and commercial databases for the cloud.

One of the best features of cloud databases is their on-demand scalability. Organizations can easily scale with customer needs. In contrast, on-premises or private cloud solutions bind engineering teams to their hardware. These constraints don’t exist for cloud users.

Companies on the cloud can choose from a wide variety of plug-and-play solutions to optimize performance across decoupled services (AKA microservices). These microservices can each have their own database engines that scale as needed.
Myth: Cloud Databases Won’t Reduce my IT Costs

The second myth that holds companies back is the belief that IT costs won’t come down in the cloud. Theoretically, on-premises and cloud databases could be equally costly, but this is unlikely in real-world scenarios when you consider all factors.

With on-premises databases, companies pay in full whether they are buying direct or through a private cloud. They also typically have to buy licenses with fixed pricing. Even if organizations don’t use the maximum resources available to them, they are still on the hook for the full cost. AWS doesn’t operate this way.

On AWS, organizations only pay for resources consumed if they choose to go the on-demand route. IT teams can otherwise select from different savings plans if they are willing to make minimum volume commitments. Compared to fixed-price contracts, these approaches ensure that costs scale more closely with processing power. This level of elasticity is essential for modern companies that want to deploy modern applications.

Myth: I’m Better Off Leaving my Data On-Premises for Security and Availability

Outside of performance and pricing concerns, some still think that commercial databases are better from a security and availability standpoint. Yet, the cloud wins out here, as well. Cloud databases minimize manual work related to:

Encrypting data at rest

Encrypting data in transit

Defining port allowances

Preparing for compliance audits

This is crucial because manual work opens the door for human errors. On-premises databases put these tasks on IT’s shoulders and make administrators responsible for ensuring data integrity. There is no room for mistakes, which is scary when managing complex applications. The good news is that cloud databases alleviate this pressure.

For instance, Amazon Aurora maintains six copies of data across three availability zones. The solution boasts 99.99%+ durability with <30-second instance failover. Similarly, Amazon DynamoDB guarantees a reliability of up to 99.999%. AWS’ managed databases also offer 256-bit encryption with SSL certifications and rotating access keys.
Moreover, the cloud provider offers an identity and access management (IAM) solution that simplifies authentication and role assignments for users and resources. AWS also lets users set up security groups, which take away much of the complexity associated with protecting cloud-based infrastructure.

Myth: There’s Not Much I Can Do in Cloud Databases That I Can’t Do On-Premises

The fourth myth that keeps leaders from modernizing databases is the idea that they aren’t missing out on much by staying on-premises. But the truth is that commercial databases fall short in significant ways when trying to elevate legacy applications. Most are monolithic by design, which is antithetical to the agile nature of the cloud.

Organizations that want to deliver modern applications must have modern back-end infrastructure. Today, this means leveraging microservices–and having different databases for different application functions. Taking this approach allows organizations to scale distinct parts of their applications separately according to demand.

Myth: Commercial Databases Aren’t Compatible With Cloud Databases

The final myth that slows database modernization progress is the notion that popular commercial databases, like Oracle and SQL server, aren’t compatible with cloud databases. This isn’t true. Amazon RDS, for example, lets users run their Oracle and Microsoft SQL server workloads in a fully managed database service. Amazon Aurora is also fully compatible with MySQL and PostgreSQL databases.

For the most part, cloud databases allow companies to continue using familiar code, drivers, applications and tools without having to do much refactoring. And should leaders decide to migrate away from commercial solutions altogether, there are import and export tools that help accelerate the process.

Conclusion

To summarize, much of the conventional wisdom around keeping commercial databases is outdated. The cloud offers a much more compelling and exciting path. Cloud-native solutions enable companies to take database performance to the next level without any added complexity.
August 18, 2022
How to Modernize Data Integration

In times of uncertainty, accurate real-time data becomes essential to informed decision-making. When the pandemic ends and businesses begin to reopen, this will be truer than ever. While there is no precedent for COVID-19’s impact on the economy, what is clear is that the enterprise is clamoring for more analytics than ever. Data engineering is at the heart of operationalizing the delivery of that data, wherever it originates and wherever it’s needed.

To operationalize data flows, engineers must be able to collaborate with different personas, reuse peer assets, support data pipelines in production and, as platforms and business requirements change, evolve quickly and with confidence. The focus of data engineering can no longer be limited to ease-of-use and developer productivity. In today’s fast-changing world, we need to enable modern engineers to embrace DataOps. In doing so, they will be able to guarantee continuous data for fast, confident decisions by and for the business.

Current Options Are Too Simple or Too Complex

Current approaches follow either a “grab-and-go” mentality that focuses on simplifying ad-hoc access for first-time analysis, or lurches towards specialized coding for anything complex. Both of these approaches lead to ongoing and recurring headaches. Significant effort is required to debug data pipelines, rerun them and rework them every time a change happens. Today’s data engineers end up spending 80% of their time just keeping the lights on, leaving very little time for new value-added work.

Using Intelligent and Responsive Data Pipelines

Data engineers face mounting pressures and challenges, from an ever-increasing project backlog to an accelerating pace of upstream changes to the emergence of cloud data platforms driving re-platforming projects. To tackle these issues, engineers need a solution that allows them to operationalize their work by abstracting the “what” of the data—the business meaning and the logic—away from the “how” of the data—the technical implementation details that the business doesn’t care about. To achieve this, businesses need to think about data pipelines as dynamic, intelligent sources that can (and should) be capable of real-time adjustments.

There are three ways that data pipelines can be considered smart or dynamic: they are easy to start and easy to extend; they are resilient to changes that occur over time and they are portable, supporting hybrid and multi-cloud environments.

Companies that have focused on removing the “how” by developing intelligent and responsive systems free up their engineers to stay focused on the “what” – what are the outputs? Are the analytics providing the right ROI or information? They also make it easy to get started building pipelines through intent-driven design, removing tedious tasks for engineers and empowering ETL developers to self-service. This includes the repetitive task of managing data drift, whether it’s a schema change, a database version upgrade or a file format change. Smart pipelines handle such changes with minimal to no intervention required.

Demand Continuous Data for the Business, Now

COVID-19 has segmented businesses into have-lots, haves and have-nots. The have-lots have experienced unimaginable growth and, consequently, are generating incredible amounts of data. They have had to deliver better engagement with their constituents, optimize their product offerings and stop bad actors, fraudsters and cybercriminals from exploiting the unexpected surge in demand for their business. If they have risen to the challenge, you can bet that they have modernized their data practice and can deliver continuous data to all consumers.

The haves and have-nots have generally been in survival mode, operating under short-term mindsets to reduce cost, consolidate as much as possible and wring out any waste. Depending on each individual situation, that may have meant staying on legacy platforms and postponing modernization efforts. Some have enjoyed cost savings by reducing consumption and negotiating with their vendors. Others have made a tactical move to the cloud, but simply as a path to lower costs of their data platforms. Only a select few have done the right thing and made the complementary investments in data engineering to reap the full benefits of their shift to cloud.

As this pandemic comes to an end, the prospects for the haves and the have-nots will start to look more promising. If you have been focused solely on keeping the lights on and managing costs, you may have been mortgaging your future. This needs to end. Don’t wait. By modernizing your ETL to create more dynamic, real-time data pipelines now, your engineers can operationalize their work, deliver a new level of innovation and self-service to the business and demonstrate their true worth as data heroes.

April 28, 2021