Smalltalk in 2026: modernising a critical system without rewriting it

Jun 9

4 min read

In a number of banks and insurers, the risk engine, the policy master or the pricing system still runs on Smalltalk. These systems are thirty years old, they work, and nobody wants to be the person who breaks them. The question is not whether to modernise them, but how to do it without stopping the business.

A 1972 language still carrying critical systems

Smalltalk was born at Xerox PARC in the early 1970s, driven by Alan Kay, Dan Ingalls and Adele Goldberg. Smalltalk-80, released from 1981, became the foundation of every commercial implementation that followed, and the ANSI standard ratified in 1998 remains the language's reference. It is a pure, reflective object environment where code can be changed while the system is running. That flexibility is why financial teams in the 1990s picked it for complex applications that had to evolve fast.

The best-known example is Kapital, JPMorgan's risk management and pricing system, built in the early 1990s on VisualWorks and the GemStone/S object database. According to a case study published in 2007 on the GemStone Soup blog, the bank estimated at the time that any other language would have required at least three times the resources. This is not a relic: in spring 2025, JPMorganChase was still advertising a "Software Engineer III, Smalltalk Developer" position for its Rates Risk and PnL team in Bengaluru, with production code in Smalltalk and Python listed as a preferred secondary skill. The message is clear: the system is alive, it keeps evolving, and the bank is looking for people who can make it talk to the rest of the world.

The same pattern shows up at OOCL, the Hong Kong container carrier, whose IRIS-2 system on GemStone/S and Cincom Smalltalk manages around 1.5 billion objects for 5,800 employees across 150 offices, and at European insurers whose policy core runs on Cincom ObjectStudio or VisualWorks, now at release 9.5.

The real cost is not the licence, it is standing still

The legacy debate is often framed badly. The cost of an old system is not its day-to-day upkeep, it is everything it prevents you from doing. A PwC and Ignatica study on insurance legacy systems, republished by Insurance Journal in April 2024, notes that maintaining existing systems absorbs on average 70% of IT budgets, and that developing and testing a new insurance product on those systems takes six to nine months and costs between 400,000 and 900,000 dollars, according to the Society of Actuaries.

The second cost is human. Companies lost on average 23% of their legacy workforce over five years and 63% of those positions remain unfilled, according to a 2018 Forrester Consulting survey quoted in the same study. Smalltalk developers exist, but they are rare, expensive and often close to retirement. Every departure takes away part of the business knowledge the code encodes without documenting it.

The third cost is the risk of failure. When a system can no longer be tested or deployed with confidence, every change becomes a gamble. The 2012 RBS outage, which froze 12 million accounts and cost 175 million pounds, was attributed by management to decades-old, poorly maintained systems. No bank wants to be next.

Three options, and only one is truly bad

Faced with a Smalltalk core, we see three paths.

Keep and encapsulate. The system remains the master of data and rules, but it is exposed behind clean APIs (REST, events, GraphQL). New channels, analytics tools and AI agents consume those APIs without touching the core. ObjectStudio ships CICS, MQ Series and APPC connectors precisely for this kind of integration. This is the lowest-risk option and the fastest to deliver.
Extract progressively. Domain by domain, you move the functions that change most (pricing, reporting, client portal) out of the core into modern services, in Java or on a low-code platform, while the legacy keeps carrying the in-force book. PwC describes this product-by-product approach: contracts migrate as transactions occur, and legacy records become dormant. This is the "strangler fig" pattern, and it is the one we recommend as soon as the business roadmap runs beyond two years.
Rewrite in one go. Replace everything in a single cutover. It looks attractive on paper and fails in practice, because nobody knows the full set of business rules buried in thirty years of code. Regression risk is maximal, the return on investment arrives last, and the organisation burns out before go-live.

One figure sums it up: according to a 2025 Saritasa survey of more than 500 IT professionals, 62% of organisations still depend on legacy software and 50% postpone modernisation because "the current system still works". The reasoning is understandable, but it only shifts the risk to the moment when nobody is left to intervene.

What AI changes in the equation

Two things have changed in the last two years. First, language models read Smalltalk very well. They do not replace a senior developer, but they make it possible to document classes that were never commented, to generate characterisation tests that freeze current behaviour before any change, and to propose translations of business rules into Java or into a specification an analyst can read. On a recent engagement, this assisted documentation step cut the time needed to understand a pricing module by a factor of three.

Second, AI agents need stable APIs to act. A Smalltalk core encapsulated behind well-defined services becomes a source of truth an underwriting assistant or a claims agent can rely on. Without that layer, AI stays confined to experiments at the edge.

What we take away

A Smalltalk system in production is not a problem to make disappear, it is an asset to protect and open up. The right sequence is almost always the same: freeze behaviour with tests, expose APIs, extract what moves, and never plan a single big-bang cutover. At 39 Advisory we support financial institutions on exactly this kind of trajectory, with teams who know both the legacy and the modern platforms.

If your core system is holding back your roadmap, let's talk: a two-week diagnostic is usually enough to choose between encapsulating and extracting.