Back in 2006, Richard Milone at CNX started what should have been a simple project. Their Atomic software was running manufacturing shop floors across the country, but it still had that old-school terminal interface. Time to modernize. He acquired and installed four or five different modernization tools from the leading vendors. They all promised the same thing: bring your green screens to the web with no coding required.
“The bottom line of all that analysis was we hated all of them,” Richard recalls. “Nearly twenty years later, if you look at those same vendors’ products today, they still look identical to what they were selling in 2006. There’s nothing modern about their modernization.”
The Screen Scraper Problem Nobody Talks About
Some of the tools CNX evaluated were screen scrapers. The pitch sounds perfect: your existing green screen applications instantly running in a web browser. No code changes. No risk. Just immediate modernization.
Here’s what they don’t tell you in the demo. Screen scrapers are translating what exists, not reimagining what’s possible. They take your 5250 data stream and convert it to HTML. Function keys become buttons. Fields become text boxes. You end up with exactly what you started with – a green screen that happens to run in Chrome.
Rob Swanson from CNX puts it bluntly: “You leave a guy to his own devices to start designing screens when his whole world has been 5250-based and you get screens that still look like green screens.” Their blood runs green; they can’t help it.
But even with screen scrapers doing the translation, you’re not solving the real problem. Your workflows are still designed for 1985. Users still navigate through six screens to complete simple tasks. New employees still need to learn what F3 means. You’ve preserved an interface paradigm that predates the internet.
Why Vendors Stopped Innovating in 2006
The modernization tools that looked outdated to CNX in 2007 are still being sold today with modest changes if any. These vendors solved the technical challenge of making green screens appear in browsers, then stopped. They never asked the important questions: How do users actually want to work? What would these applications look like if we designed them for modern workflows?
Some vendors offered client-server interfaces that required “some work involved to redo the workflow,” as Richard describes it. But that work turned into massive projects. You weren’t just updating interfaces, you were rebuilding everything. And for what? To end up with applications that still didn’t feel modern.
The truth is, most vendors picked the easier path. Building a screen scraper is a technical problem with a definable solution. Understanding business processes and reimagining workflows? That’s messy. That requires significant work to actually understand what the business does.
The Eureka Moment That Changed Everything
While evaluating all these disappointing tools, Richard discovered something different: ExtJS, a JavaScript framework that created truly interactive components. “Within five minutes of exploring this ExtJS, I just knew that every web-based application would work like this in the future,” he says. “I didn’t know if it would take two years, five years, or ten years.”
This was 2007. The browser wars had just ended. JavaScript engines weren’t even standardized across browsers. Picking a JavaScript framework was betting on the Wild West. But CNX saw something the modernization vendors missed: users expected real interactivity, not just HTML forms that looked like green screens.
Modern web applications need responsive design, autocomplete searches, sortable grids, and real-time updates. Screen scrapers can’t deliver any of this because they’re working with terminal output, not data. There’s no API to build on, just character positions on a screen.
The Learning Curve Nobody Expected
When CNX built Valence, they made an assumption that turned out to be “a little rosy,” as Rob puts it. They thought RPG programmers would share their enthusiasm for learning HTML5 and JavaScript. They’d built the platform, now developers could create modern interfaces.
Reality hit fast. “Most RPG programmers are ten feet deep in to-do lists and fighting fires all day long,” Rob explains. “Learning a new technology was not in the cards.”
This is the hidden cost of modernization that vendors don’t mention. Even with better tools, you’re asking backend developers who’ve spent twenty years perfecting business logic to suddenly become UI designers. It’s like asking a plumber to do electrical work. Sure, they both work on houses, but they’re completely different skill sets.
CNX adapted by building low-code tools that gave RPG developers guardrails. They could define what data to show and what actions to enable without writing JavaScript. The tool ensures visual consistency between applications. No more green screens in Chrome.
When “Instant Modernization” Becomes a Multi-Year Nightmare
The companies approaching CNX today often tried modernization before. They bought the tools with the easy demos. They ran pilot projects that seemed promising. Then reality hit.
Users complained the applications were actually slower. The browser back button broke everything. Mobile access technically worked but was unusable on a phone screen. After months of fighting with the “modernized” system, everyone wanted the green screens back.
There’s also the organizational scar tissue. When your team has lived through a failed modernization project, they’re not eager to try again. IT leadership loses credibility. Future projects face higher skepticism. The next vendor who shows up with a modernization pitch gets shown the door before they can open their laptop.
Meanwhile, competitors who picked better approaches are delivering actual modern experiences. They’re attracting younger workers who won’t tolerate learning function keys. They’re serving customers who expect applications to work like the consumer apps they use every day.
The Acquisition Conversation That Reveals Everything
Here’s how you know if a modernization vendor really understands the problem. Richard describes the typical acquisition conversation before CNX joined Izzi: “How many customers do you have? How long will they stay on maintenance?”
When Jen from Izzi approached CNX, the conversation was different. She talked about what they could do with Valence in the future. Maybe port it to IBM Z. Use it as the platform for additional acquisitions or use it to modernize other acquired products. It was about growth, not milking.
That’s the same difference between screen scrapers and real modernization. Screen scrapers are about preserving what exists. Real modernization is about enabling what’s possible. One approach leads to tools that look the same in 2025 as they did in 2006. The other leads to applications that actually work the way users expect, and unlock hidden productivity.
Your RPG code has accumulated decades of business logic refinements. It handles edge cases that nobody remembers until they break. That code is valuable. Your green screens are not. Choose modernization tools that understand this distinction. The failed projects all share the same flaw: they tried to preserve everything instead of improving anything.