Skip to main content
Settings
Color Mode
Theme Skin
Background

Appearance preferences are saved in this browser only.

Environment
Current Environment Production

Built with JEKYLL_ENV=production. Changes require deployment.

Theme & Build
Jekyll v3.10.0
Last Build Jul 12, 21:59
Page Location
Page Info
Layout article
Collection posts
Path _posts/erp/2026-01-31-erp-frankenstein.md
URL /news/erp/frankenstein-erp-legacy-fragmentation/
Date 2026-01-31
Breaking

Frankenstein's ERP: legacy fragmentation horror

The monster you already own

It is 2026. Your Enterprise Resource Planning (ERP) vendor just announced an AI agent that predicts supply-chain disruptions before they happen. Bravo. Meanwhile, back in the fluorescent-lit cubicles of your IT team, someone is alt-tabbing between six different user interfaces from four different decades just to ship a pallet.

This is Frankenstein’s ERP: a stitched-together creature of modern browser tabs, multiple 2000s-era thick clients, and a character-based warehouse module that was probably coded during the Clinton administration. Vendors love to ignore it on the keynote slide. Your warehouse cannot.

Why it matters now

The bill for this monster is real, and it is paid monthly. We routinely see mid-market manufacturers (roughly $200M-$500M in revenue) spending six figures a year on contractors just to keep the oldest pieces alive, plus a 28-35 person internal IT group whose actual job is “keep the green screens blinking.”

Two forces are squeezing these companies at once:

  • Vendor cloud pressure. QAD and Infor are herding legacy customers toward subscription clouds with the urgency of a shepherd holding a cattle prod. QAD’s Adaptive ERP is now “agentic,” Infor ships AI agents faster than marketing can name them, and the “fixed-fee” migrations still somehow cost more than a house.
  • Vanishing talent. The people who can actually edit the old code are retiring or already gone, and nobody graduating in 2026 is learning a 4GL from 1984.

Every day spent maintaining the creature is a day not spent on the modernization the business actually wants.

A guided tour of UI hell

Take a $400M manufacturer with plants in the US, Mexico, the UK, and India. Here is the daily dance a single user performs:

  1. Open the modern web UI for basic order entry (limited features, naturally).
  2. Switch to .NET thick client #1 for financials, because the web version still cannot run that one report.
  3. Fire up .NET thick client #2, the asset-management edition acquired in a 2008 buyout and never fully integrated.
  4. Launch .NET thick client #3 for advanced production scheduling, a different acquisition from a different era.
  5. For the grand finale, boot the character-user-interface (CHUI) warehouse addon in a terminal emulator to print labels, scan receipts, and pray the session does not drop mid-shift.

Six interfaces. Six different ways to hate your morning.

The CHUI module deserves its own spotlight. Built on Progress OpenEdge 4GL (a fourth-generation language so niche it is practically an endangered species), this green-screen relic runs the most mission-critical tasks on the floor: label printing, radio-frequency (RF) scanning, shipping, and receiving finished goods. One crash and the production line stops. It is the ERP equivalent of running your whole plant on a single 40-year-old steam valve while the vendor brags about its new electric turbine. The code is editable only through a fragile .NET-wrapped editor that crashes more often than the line it controls. This is not development. It is archaeology.

The offshore 4GL wizard

Need a bug fixed in the CHUI label routine? You had better hope your retainer with that one developer in India is still active. Progress 4GL expertise is concentrated halfway around the world, and the people who have it are guarded like nuclear codes.

A production receipt fails at 2 PM Colorado time. That is 1:30 AM in India. By the time the wizard wakes up, you have lost a shift, your inventory counts are wrong, and someone is hand-printing labels on a desktop printer like it is 1999. Lose that contractor to attrition and you are shopping in a talent market thinner than a quiet day in a warehouse.

The staffing museum

For a $400M global manufacturer running this portfolio, the “bare minimum” IT organization looks less like a department and more like a museum staff for a live production system:

Role category Headcount Unofficial job description
Leadership and governance 3-4 Professional apologizers for why nothing works together
Functional support 8-10 Translators fluent in six UI dialects and one ancient 4GL incantation
Technical maintenance 6-8 plus contractors Includes 2-3 offshore wizards who can edit the sacred 4GL scrolls
Infrastructure and endpoints 5-7 Keepers of terminal emulators, legacy printer queues, and Wi-Fi prayers
Service desk 6-8 First responders to “why does this only work in the old client?”
Total 28-35 A support group for technological trauma

The watch-outs (where escape attempts die)

Three things sink the “we’ll just migrate to the cloud” plan, and they are worth naming before you sign anything:

  • The custom 4GL is not optional. Half a million lines of business logic live in that warehouse code. “Lift and shift” does not apply to a language the new platform cannot run. Someone has to re-implement it, and re-implementation is where seven-figure consulting bills are born.
  • The feature gaps are deliberate, not accidental. Some functions only exist in the old thick clients because the acquired products were never fully merged into the core. Confirm in writing that the target platform replicates every report and workflow your floor depends on, not just the ones in the demo.
  • Cutover risk lands on the warehouse, not the boardroom. A failed financial close is painful. A failed receiving cutover stops trucks at the dock. Sequence the migration so the CHUI-dependent processes move last, with a tested fallback and a parallel-run window of at least a few weeks.

What we would actually do

The honest answer is not “rip everything out next quarter.” It is to stop treating the creature as one unmovable mass and start dismantling it in priority order.

  1. Inventory the monster (2-4 weeks). Catalog every interface, every custom 4GL routine, every integration, and who actually depends on it. You cannot migrate what you have not mapped, and most shops have never written this down.
  2. Rank by risk and pain. Score each component on business criticality, talent risk (how few people can support it), and contract cost. The CHUI warehouse module usually tops both lists.
  3. Pick the battles worth fighting. Some pieces get replaced, some get a modern wrapper, and some get left alone because the math says so. This is a vendor-neutral decision, not whatever your incumbent is selling this quarter.
  4. Phase the cutover. Move the lower-risk financial and order-entry pieces first to build the team’s confidence, then tackle the warehouse last with a real fallback plan.

This is the work where a finance-literate, vendor-neutral outside team earns its keep: we can read the 4GL and the general ledger, and we have no incentive to push you onto any single platform.

Next step

You do not have to keep stocking Red Bull for 3 AM calls or perfecting your “it’s a feature, not a bug” smile. The first move is a clear-eyed map of what you own and what it is costing you. See our [[ERP consulting]] for SMB and mid-market manufacturers, and we will help you decide which parts of the monster are worth saving.

For the morbidly curious who want to understand what they are actually maintaining, the Progress OpenEdge ABL reference documentation is the primary source on the language keeping your warehouse alive.

In all of this, you are not the villain. You are the punchline, at least until you decide to write a new joke.