LANSA and the million-dollar price tag

A price label seems an unlikely place to find a software strategy. It is small, cheap and usually beneath notice. In Hillman’s historical customer story, however, a mass price change cost roughly $1 million. The hardware supplier printed labels for products a store might carry; about 80 percent went into recycling. The computer had plenty of product data. It lacked a sufficiently accurate picture of the shelf.

The labels knew too little

Hillman used handheld scans and a LANSA-based repository to record each store’s display and its order. Labels could then arrive in an envelope, arranged for the actual job. Its 2008 project cost $245,000 initially, including $200,000 for scanning and setup, $15,000 for handheld software and $30,000 for other software and consulting. Hillman reported more than $850,000 saved per price change, and over $600,000 after that first outlay.

The interesting question is what changed. A task designed around a generic assortment became a task organized around a real store. The expensive assumption lived between the database and the person applying the labels. That is a useful place to begin looking for a modernization project.

The software remembers

LANSA makes the tools that let development teams build and adapt enterprise applications. Its specialty is IBM i, the platform descended from the AS/400, though its product range also reaches Windows and cloud environments. The customers are businesses with orders, inventory, contracts and transactions to manage. Their software often has a considerable memory.

A pricing rule, for example, may encode an agreement that predates the current IT team. An insurance application may contain underwriting decisions refined over years. Replacing the application means understanding which of those decisions still matter. An unattractive screen can be easy to recognize; an indispensable exception buried in the logic can be considerably harder.

Peter Draney and Lyndsey Cattermole founded LANSA in Australia in 1987 to develop tools for IBM’s System/38. Its origins therefore predate the AS/400 itself. The company’s fourth-generation language, RDML, stands for Rapid Development and Maintenance Language. Today’s low-code vocabulary would have been unfamiliar then, but reducing the work required to build business software was already the proposition.

Idera acquired LANSA in December 2018. LANSA now describes a remote-first culture with international staff and localized support. Continuity runs through its offering: preserve useful business knowledge while changing how applications are built, connected and used.

Three ways to move forward

The product names make more sense when you ask what needs changing. aXes works at the screen: it web-enables IBM i 5250 applications without rewriting their underlying source. RAMP combines existing screens and new LANSA components, allowing gradual replacement. Visual LANSA is the development environment for building the new application or component.

Visual LANSA uses the proprietary RDML/RDMLX language across the frontend, backend and middleware. A central repository holds application definitions and shared business rules. Visual design tools and reusable components reduce repetitive coding. For an IT team, the attraction is managing more of an application in one environment, with fewer boundaries between the people responsible for its different parts.

The surrounding products handle other jobs. Integrator connects applications and data. Composer transforms and transports information and orchestrates trading-partner processes, including EDI. Open for .NET connects Microsoft applications to IBM i resources and repository rules. Commerce Edition addresses B2B storefronts, while LANSA BI supplies standalone or embedded analytics. They address different bottlenecks; a screen refacing tool should not be mistaken for a complete redesign of the underlying business.

A railway, an insurer and a wine order

Hupac’s public case brief describes a 30-year-old transport system facing growing demands. A six-person development team used aXes, Visual LANSA and Integrator to add capabilities, including web booking and train monitoring. LANSA’s case reports 40 percent less development time and 50 percent lower maintenance costs. Those are results attached to that customer, rather than a forecast for the next railway.

Allied Beverage Group offers a different motive. Its LANSA-based portal, developed with business partner Strategic Business Systems, connected customers and sales representatives to ordering, account information and product content. CIO Rafael Ramos explained the priority:

“Our initial motivation was not online ordering, it was about delivering timely and accurate information to our customers.”

Rafael Ramos / Allied Beverage Group / historical customer case

That distinction matters. A storefront can look modern while customers still call to find an invoice. Allied wanted the website to make service better. The technical work followed the customer’s need for accurate information.

In Merchants Insurance’s historical case, agents had previously used rating diskettes and sent quotes for staff to re-enter. Quotes could differ from those produced by the core WINS system. LANSA’s web extension gave authorized agents access to the same data and logic. Merchants reported that issuing and mailing a policy took about one day, down from several days to two weeks. Access to the existing system removed a particularly awkward duplication.

The bill has more than one line

LANSA earns money through commercial software licenses, subscriptions, maintenance and support, and professional services. Its partner network also builds and implements applications. That makes it both a tool vendor and a source of implementation expertise. The product purchase is one part of the relationship; decisions about integration, deployment and maintenance remain part of the work.

A buyer should ask for a project estimate that includes developer training, runtime requirements, infrastructure and support. Hillman’s historical outlay illustrates why a software-only comparison can miss much of the bill: collecting the information needed for the application was a substantial expense. A low-code tool cannot supply facts the business has never recorded.

The choice of platform also shapes future maintenance. LANSA’s single-language approach gives a team one environment to learn and manage. It also commits that team to proprietary tooling and skills. Whether that exchange is attractive depends on the applications, the people maintaining them and the cost of the alternatives.

Those alternatives include enterprise low-code platforms such as Mendix and OutSystems, specialist IBM i modernization products, custom development and packaged-system replacement. LANSA’s clearest position is where new applications must coexist with established enterprise operations. Evaluating it means testing that connection against your own requirements, rather than comparing attractive demonstration screens.

New tools, familiar obligations

The current lineup extends the same argument into APIs and AI. LAiR, short for Legacy AI Refactoring, analyzes legacy LANSA code and transforms reusable logic into documented REST APIs. LANSA offers expert guidance and a 21-day pilot intended to document the application, develop a roadmap, estimate investment and validate the refactoring pipeline.

LANSA BI 9.16.1.1 adds natural-language queries, AI-assisted explanations and recommended charts. Its April 2026 update describes provider choice, tenant-level configuration and token-usage auditing. The vendor says its insight feature sends summarized findings rather than detailed dataset records; query features may send metadata and the user’s question. The sensible evaluation includes which information leaves the system and who controls that exchange.

Other updates are less theatrical. Open V5.3 supports .NET 10. Visual LANSA 16 adds API and interface capabilities, including WebView2 and Azure-compatible licensing. A May 2026 article describes an AWS Scalable License subscription with an AMI and a CloudFormation deployment stack. These changes concern getting applications connected, deployed and maintained, which is where much of enterprise development’s work resides.

Start with the awkward handoff

A useful evaluation begins with one workflow: a customer order, a policy quote or a price change. Identify the information people need, the rule that decides the outcome and the point where someone copies, waits or telephones. Then prototype that transaction against the real system. Measure what improves, including the work required to keep it running.

The approach depends on the old rules deserving to survive. If those rules are wrong, their browser version will still be wrong. If the business needs a fundamentally different process, refacing its screens may have limited value. A team that cannot maintain the chosen tools will also need a credible support or partner arrangement.

Merchants provides a useful restraint: its wireless PDA experiment worked, but the company saw too little business benefit to put it into production. A functioning demo was insufficient. LANSA’s strongest customer stories invite the same discipline today. Follow the transaction far enough to discover what becomes easier for the person doing it. Sometimes the answer comes in an envelope.