DEV Community: Custralis

Modernising a legacy AS/400 (IBM i) system without rewriting it

Custralis — Sat, 11 Jul 2026 23:07:49 +0000

Many companies still run production, warehousing, orders and invoicing on a business system that has been going for twenty years or more on an AS/400. Today that platform is called IBM i (it went from AS/400 to iSeries, System i and finally IBM i), but the name almost everyone still uses is the first one. Faced with a system this old, the instinctive reaction is to think it should be scrapped and rebuilt. Almost always that is the wrong conclusion. The problem is rarely the machine, which remains reliable and fast. The problem is that the system lives isolated from the rest of the world, depends on an increasingly rare skill, and was often never designed to be exposed to the outside safely. These are three different problems, and none of them is solved by rewriting everything from scratch.

The AS/400 system works: the problem is elsewhere

An AS/400 that has been in production for years has an underrated virtue: it holds the company's business logic, refined by decades of real cases, exceptions and fixes. Rewriting it from zero means throwing that asset away and risking the reintroduction of bugs that were already solved. That is why the real risks are three others. The first is isolation: the system does not talk to the website, the app, the customer and supplier portals, the other applications. The second is skills: the language it is written in, RPG, is mastered by ever fewer people, many close to retirement. The third is security: born in an era when the system sat locked in a machine room, it is not necessarily ready to be reached by a modern network.

Why modernise the AS/400 instead of rewriting it

The most common proposal is also the riskiest: redo everything on a new platform, in one go. On paper it is seductive; in practice it is the kind of project that most often overruns time and budget, or fails outright. A system that keeps the company running cannot be switched off for months while its replacement is built, and rebuilding years of rules in a single migration means discovering too late all the details nobody remembered.

The mature alternative is not to replace, but to connect: leave the AS/400 doing what it does well and build around it, step by step, the modern layer it lacks. Each step delivers concrete value straight away and can be paused or corrected without ever having put the heart of the system at risk.

How to integrate the AS/400 with APIs over RPG and DB2

The first building block is to give the system a modern communication port. The RPG programs and the DB2 for i database that live on the AS/400 can be exposed, without modifying them, behind APIs: interfaces that speak today's language (web requests, JSON) and that other systems already know how to use. The system's database is fully queryable in SQL, and the platform runs Java as a first-class, fully supported runtime: this makes it possible to build a service layer that reads from and writes to the system through stable channels, without rewriting the logic inside it. These are the same standard tools used for any modern application: for example a Java framework such as Spring Boot for the service layer, which talks to DB2 naturally. From the outside the system becomes a service like any other; inside, it stays exactly as it was.

This is the pattern known in the literature as the "strangler fig": instead of replacing the system in one move, a modern shell is built around it that intercepts requests and absorbs one function at a time. Old and new coexist, and the handover happens gradually, as each single piece is ready and verified.

From the 5250 green screen to a modern web interface

With those APIs in place, the next step is the interface. The classic green-character screens (the 5250 terminal) work, but they put off younger users, make training slow and do not exist on a phone. On top of the service layer a web interface can be built, and where needed an app, with widespread component libraries (such as React) consuming the JSON produced by the APIs, and with the experience people expect today. The operator works on a modern screen; behind it, every action reaches the same old system. An honest caveat: redoing the interface does not mean photographing the old screens and pasting them onto a web page, a fragile shortcut that breaks at the first change. It means rebuilding the interaction on top of the APIs, where data and rules travel through stable channels.

Integrating the AS/400 data with other systems

An isolated system keeps its data locked inside itself. Often it is needed elsewhere: to feed another application, to exchange it with a supplier or customer portal, to produce up-to-date extracts. Because the DB2 for i database is queryable in SQL, that data can be made available to other systems in a controlled way, or copied continuously to another database when it needs to stay aligned. The delicate point is not technical, it is one of method: expose only what is needed, through dedicated reads, without handing whoever is outside the keys to the whole system.

Securing IBM i during modernisation

Here lies the point too many modernisation projects overlook, and which is in fact decisive. Exposing a system born to stay locked in a machine room to a modern network multiplies its attack surface. This is not a theoretical risk: real vulnerabilities are found on IBM i too, and an access configuration inherited from twenty years ago often grants more power than necessary. Modernising without securing means building a new house on an old lock.

Modernisation done well treats security as part of the project, not as a final touch-up. The API layer is not only a technical convenience, it is also the control point: it is there that it is decided who can do what, requests are validated, access is tracked and direct exposure of the system is avoided.

On the system itself the principle of least privilege applies: every technical account gets only the powers it needs, and the broadest authorities (those equivalent to the system's all-powerful administrator, historically the QSECOFR profile) stay restricted and watched. Recent versions of IBM i add modern tools, such as multi-factor authentication, that should be used. The rule is simple: every door opened to the outside must be designed to withstand whoever will misuse it, not only whoever will use it well.

Reducing dependence on RPG developers

The third problem, skills, is addressed without drama but without postponing it. Finding and keeping people who know RPG is increasingly hard and expensive, and tying the company's survival to a handful of people is a risk in itself. The same gradual approach offers a way out: as the service layer is built, the logic that changes most often can be moved, one piece at a time, towards widespread technologies for which skills are easy to find. It is not a race to dismantle the system, it is a controlled reduction of dependence: the stable core stays where it is, the parts that evolve migrate to where the labour market is wider.

Modernising the AS/400 one step at a time, with controlled risk

The thread tying it all together is the method: no total migration, but a sequence of bounded steps, each with a clear purpose and a verifiable result. It almost always starts with an initial analysis: understanding how the system is built, which data and programs really matter, where the security risks are, and which integration is worth starting from. From there the first block that delivers value right away is chosen (often a single integration, or one critical screen rebuilt), delivered at a defined scope and price, and only then is the next step decided. That way the investment stays under control, the system never stops, and at every stage there is something that works, not a promise.

In short

The AS/400 (IBM i) is usually not the problem: it is reliable and it holds the company's business logic.
The real risks are three: isolation from other systems, ever rarer RPG skills, and security designed for a closed world.
Rewriting everything in one go is the most expensive route and the most exposed to failure.
The mature path is to connect, not replace: APIs over programs and database, without touching their core.
On top of the APIs: a modern web interface in place of the green screen, and data integrated with other systems.
Security is designed alongside the rest, not bolted on at the end: least privilege, a single control point, strong authentication.
One step at a time, each with concrete value and bounded risk, starting from an initial analysis.

Frequently asked questions about AS/400 modernisation

How much does it cost to modernise an AS/400 system?

There is no single price: it depends on which integrations and interfaces are actually needed. That is exactly why it is worth starting from a low-cost initial analysis that defines the scope and priorities of the first block. The phased approach keeps costs and timelines predictable, because each step has a defined scope and price before it begins.

Does the AS400 have to be switched off during migration?

No. The idea is to build the modern layer alongside the system, which stays in production. Old and new coexist and functions move over one at a time, as each is ready and verified. There is no shutdown while a replacement is built.

Can the AS/400 be integrated with e-commerce and e-invoicing?

Yes. Once the system is exposed behind APIs, its data and functions become available to other systems: an online shop, a supplier or customer portal, document exchange (EDI) or electronic invoicing. Only what is needed is exposed, in a controlled way.

How can the shortage of RPG developers be addressed?

With the same gradual modernisation: as the service layer is built, the logic that changes most often can migrate towards widespread technologies for which skills are easy to find. The stable core stays on the AS/400, and dependence on a rare skill is reduced over time.

Is it better to modernise or rewrite from scratch?

In the vast majority of cases modernising is better. Rewriting everything in one go means throwing away decades of business logic and taking on the project most likely to fail. Connecting and replacing gradually delivers value straight away and keeps risk under control.

Connecting the past to the present, safely

Modernising an AS/400 system does not mean disowning what has worked for twenty years. It means connecting it to the present, safely, without stopping the company and without betting everything on a rewrite. The first step is not a big project, it is a question: where is it worth starting, and at what risk.

The simplest way to answer it is to start from an initial analysis: understanding which data and programs really matter, where the security risks are, and which integration is worth starting from. It is a first step at a defined scope and price, not a commitment to the whole project.

For the services these projects are delivered with: Legacy system integration and modernisation.

Originally published on custralis.com.

NIS2 e le PMI: chi è obbligato davvero, e la parte software che ti chiederà il cliente

Custralis — Sat, 11 Jul 2026 22:48:34 +0000

«NIS2» è diventata una di quelle sigle che generano più ansia che chiarezza. La prima cosa utile da sapere è anche la più rassicurante: la maggior parte delle PMI non è direttamente obbligata a NIS2. Il motivo per cui potrebbe riguardarti comunque è un altro, meno noto, e sta nella catena di fornitura. Questo articolo separa gli obblighi reali dal panico, e si concentra sulla parte che chi sviluppa software può affrontare davvero: il codice, gli accessi, i dati.

Cos'è NIS2, in breve

NIS2 è la direttiva europea sulla cybersicurezza (Direttiva UE 2022/2555), recepita in Italia dal D.Lgs. 138/2024, in vigore dal 16 ottobre 2024, con l'Agenzia per la Cybersicurezza Nazionale (ACN) come autorità di riferimento. Alza l'asticella della sicurezza informatica per una serie di settori considerati critici, e la rende una responsabilità esplicita, che coinvolge anche gli organi di vertice delle aziende obbligate.

Chi è obbligato davvero (e perché quasi tutte le piccole imprese non lo sono)

Qui sta il primo malinteso da sciogliere. Essere in uno dei diciotto settori indicati dalla normativa non basta a essere obbligati: conta anche la dimensione. In ambito rientrano, in linea di massima, le imprese medie e grandi di quei settori, non le piccole e le micro. Le piccole e micro imprese sono coinvolte solo in casi specifici, a prescindere dalla dimensione: per esempio chi fornisce un servizio essenziale in modo esclusivo, o chi gestisce infrastrutture come DNS, registri di domini o reti pubbliche di comunicazione. Per la stragrande maggioranza delle PMI, quindi, non c'è un obbligo diretto.

Chi rientra viene poi distinto in soggetti «essenziali», i più critici, sottoposti a una vigilanza preventiva, e soggetti «importanti», controllati soprattutto in caso di segnalazioni. I soggetti in ambito si registrano sulla piattaforma dell'ACN e hanno tempo per adeguarsi: per la prima ondata di soggetti individuati, il termine per le misure di base è fissato a ottobre 2026, con i meccanismi di notifica degli incidenti già operativi da inizio 2026. Una precisazione onesta: girano molte «soglie precise» di dipendenti e fatturato presentate come regola secca. La realtà è più sfumata, e la classificazione va verificata caso per caso, non liquidata con una cifra.

Il punto che riguarda la tua PMI: la catena di fornitura

Ecco il vero motivo per cui NIS2 può bussare alla tua porta anche se non sei obbligato. Tra i doveri dei soggetti in ambito c'è la sicurezza della catena di fornitura: devono gestire gli aspetti di sicurezza nel rapporto con i loro fornitori diretti. La legge non estende automaticamente l'obbligo ai fornitori, né alle PMI fuori ambito. Ma nella pratica genera un effetto a cascata: l'azienda obbligata, per mettersi in regola, chiede ai propri fornitori, cioè a te se sviluppi o mantieni il loro software, garanzie di sicurezza.

La distinzione è sostanziale e conviene tenerla chiara: non è un obbligo di legge su di te, è una richiesta contrattuale del tuo cliente. Nessuna autorità ti sanziona; ma se non sei pronto, rischi di perdere il contratto. È qui che NIS2, per una PMI fornitrice, smette di essere un tema astratto e diventa concreto.

Cosa ti chiederà il cliente, in concreto

Le richieste che arrivano ai fornitori di software tendono a somigliarsi, perché nascono dagli stessi requisiti. In genere ruotano attorno a pochi punti:

Clausole contrattuali sulla sicurezza: impegni scritti su come proteggi i dati e il servizio.
Notifica tempestiva degli incidenti: se qualcosa va storto, il cliente vuole saperlo in fretta.
Gestione delle vulnerabilità: come individui, correggi e comunichi le falle nel software.
Sicurezza delle dipendenze: le librerie di terze parti che usi non devono diventare un cavallo di Troia.
Controllo degli accessi e, dove serve, il diritto del cliente di verificare (audit).

Non tutte arrivano sempre, e l'intensità dipende da quanto sei critico per quel cliente. Ma conviene farsi trovare pronti, con risposte documentate, invece di rincorrere all'ultimo.

Le misure che contano sul software (e che spesso valgono anche per il GDPR)

La buona notizia è che la parte di NIS2 che riguarda chi sviluppa software è un sottoinsieme preciso e concreto, non un universo. E in gran parte coincide con quello che serve già per il GDPR. Le misure che fanno la differenza:

Sviluppo sicuro e gestione delle vulnerabilità: scrivere codice tenendo conto della sicurezza fin dall'inizio, e avere un modo ordinato per correggere e aggiornare quando emerge una falla.
Cifratura dei dati: proteggere le informazioni sia dove sono salvate sia mentre viaggiano in rete. È una delle poche misure nominate in modo esplicito, richiesta sia da NIS2 sia dall'art. 32 del GDPR.
Controllo degli accessi con privilegio minimo: ognuno accede solo a ciò che gli serve; per gli accessi più delicati (amministrativi, da remoto, alle applicazioni esposte) si aggiunge, dove opportuno, l'autenticazione a più fattori.
Sicurezza delle dipendenze: tenere sotto controllo le librerie esterne, aggiornarle, sapere cosa c'è davvero dentro il proprio software.

Il vantaggio pratico: molte di queste misure soddisfano contemporaneamente NIS2 e GDPR. La cifratura, per dire, è al tempo stesso un requisito di base di NIS2 e una misura «adeguata» citata testualmente dall'art. 32 del GDPR. Una scelta tecnica, due conformità.

Cosa non tratto qui, e quando serve un'altra figura

Per onestà, NIS2 è molto più ampia della parte software. Comprende ambiti che sono un altro mestiere e che non tratto: il monitoraggio continuo della sicurezza, la difesa della rete (firewall, sistemi di rilevamento), la gestione operativa degli incidenti, i test d'intrusione come servizio a sé. Per quelle aree servono figure e fornitori specializzati nella sicurezza gestita. Io mi occupo della fetta applicativa: il software scritto e mantenuto in modo sicuro, gli accessi, i dati, le dipendenze. Sapere dove finisce una competenza e ne comincia un'altra fa parte del lavoro fatto bene.

Prepararsi senza panico, sul lato software

Se sviluppi software e vuoi farti trovare pronto, o se hai già ricevuto un questionario di sicurezza da un cliente, il percorso non è un salto nel buio:

Capire dove stanno i dati: quali informazioni tratta il software, dove sono salvate, chi vi accede.
Rivedere codice e configurazione: correggere le debolezze note, chiudere gli accessi troppo larghi, mettere la cifratura dove manca.
Ordinare la gestione di vulnerabilità e dipendenze: sapere cosa si usa, aggiornarlo, avere un modo per reagire quando esce una falla.
Documentare le misure: metà del lavoro, davanti a un cliente o a un'autorità, è poter dimostrare cosa si è fatto. Le misure tecniche vanno scritte, non solo applicate.

È lo stesso approccio della sicurezza e della privacy by design: la protezione incorporata nel software, non aggiunta alla fine. Chi costruisce così arriva alle richieste di NIS2 con gran parte del lavoro già fatto.

Se l'azienda sei tu, non chi sviluppa

Fin qui il discorso è rivolto a chi il software lo scrive. Ma se l'azienda sei tu, e il software te lo fa qualcun altro, il messaggio è ancora più semplice: non devi diventare esperto di sicurezza. Ti serve un fornitore che il software lo costruisca già così, e che a una richiesta di sicurezza del tuo cliente sappia rispondere con misure documentate, non con un'alzata di spalle. Quando scegli chi ti sviluppa un sito, un gestionale o un'applicazione, chiedigli come gestisce accessi, cifratura, vulnerabilità e dipendenze: la risposta ti dice subito con chi hai a che fare.

Domande frequenti su NIS2 e PMI

La mia PMI è obbligata a NIS2?

Nella maggior parte dei casi no. L'obbligo diretto riguarda, in linea di massima, le imprese medie e grandi di determinati settori critici, salvo casi specifici in cui rientrano anche micro e piccole a prescindere dalla dimensione. Non esiste una soglia numerica unica: la classificazione va verificata caso per caso, e per la gran parte delle piccole imprese non c'è un obbligo diretto.

Il mio cliente mi chiede requisiti di sicurezza NIS2: sono obbligato?

Non per legge, se non sei tu il soggetto in ambito. È una richiesta contrattuale: il tuo cliente, che è obbligato, deve gestire la sicurezza dei suoi fornitori e la trasferisce a te. Non soddisfarla non comporta una sanzione, ma può costare il contratto.

NIS2 e GDPR sono la stessa cosa?

No. Il GDPR protegge i dati personali; NIS2 protegge la sicurezza dei servizi e delle infrastrutture, anche di dati non personali. Sono regimi diversi, ma diverse misure tecniche (la cifratura, il controllo degli accessi) valgono per entrambi: farle bene una volta serve a due scopi.

Quali sono le scadenze?

Per i soggetti obbligati della prima ondata il termine per le misure di base è ottobre 2026, con i meccanismi di notifica degli incidenti già operativi da inizio 2026. Il conteggio è individuale, calcolato dalla notifica: per soggetti individuati più tardi le scadenze si spostano di conseguenza.

Cosa posso fare, concretamente, sul software?

Sviluppo sicuro e gestione delle vulnerabilità, cifratura dei dati, accessi con privilegio minimo, controllo delle dipendenze e documentazione delle misure adottate. Sono le stesse basi che rendono un software difendibile davanti a un cliente, a un'autorità e a un attacco.

Farsi trovare pronti, sul pezzo che dipende da te

NIS2 non va né ignorata né vissuta come un'apocalisse. Per la maggior parte delle PMI non è un obbligo diretto, ma è una realtà che arriva dai clienti, e la parte che dipende da chi sviluppa software è concreta e delimitata. Farsi trovare con il software costruito e documentato in modo sicuro non serve solo a superare un questionario: è software migliore, che vale di più.

Il modo più semplice per capire a che punto sei è partire da un'analisi: dove stanno i dati, quali accessi e dipendenze contano, cosa manca rispetto a ciò che un cliente potrebbe chiederti. È un primo passo a scopo e prezzo definiti, non un impegno sull'intero percorso.

Per i servizi con cui questi interventi vengono realizzati: Sviluppo sicuro, sicurezza applicativa e GDPR.

Pubblicato originariamente su custralis.com.

Privacy by design: what it is and how to apply it

Custralis — Tue, 30 Jun 2026 21:50:55 +0000

"Privacy by design" is one of those phrases you read everywhere and rarely understand. It is often treated as a document to attach to a project, a box to tick before going live. In reality it is not a piece of paperwork: it is the way software is conceived and built from the very first line, so that it protects people's data without anyone having to remember to do so afterwards.

What the GDPR actually says

The principle is written plainly in Article 25 of the GDPR, which speaks of "data protection by design and by default". These are two distinct things. Protection by design concerns the choices made while the system is being built. Protection by default concerns how the system behaves the moment it is switched on, before anyone touches a single setting.

The law does not mandate a specific technology. It asks for an outcome: that data protection be built into the system, proportionate to the risks, and not bolted on afterwards as a patch. It is a difference of substance, not of form. A well-designed system does not have to chase compliance: it already has it inside.

It is not a document, it is an architecture

The most common mistake is to reduce privacy by design to a file. A report is written, filed, and the building goes on exactly as before. But a PDF protects no data. What protects data are the technical decisions: what information is collected, where it is stored, who can see it, how long it stays, what happens when it is no longer needed. These decisions are made at design time, and changing them later costs far more than getting them right at the start.

The principles, turned into concrete choices

Privacy by design becomes useful only when it stops being a slogan and turns into a series of choices. Translated into practice, the principles sound like this.

Minimisation. You collect only the data genuinely needed to deliver the service. A field you do not collect does not need protecting, cannot be lost in a breach, does not need keeping. The safest piece of data is the one that does not exist.
Protection by default. The initial settings are the most protective ones: no optional processing switched on by default, visibility kept to a minimum, consent asked for only where it is needed and never pre-ticked.
Storage limitation. Every piece of data has an expiry. You decide from the start when information must be deleted or anonymised, and you automate it, instead of hoarding forever.
Least access. Each person sees only what their task requires. An administrative role does not imply access to everything: permissions are granular and checked on every request.
Built-in security. Encryption of sensitive data, passwords never in clear text, logs that do not record full personal information. Security is not a module added at the end, it is part of how the system is written.
Transparency. Whoever uses the service can know which data is processed and why, in a readable form, not buried in twenty pages of terms.

Privacy by default: the contact form example

A simple case makes the point better than any definition: a contact form. The version built without thinking collects first name, last name, phone, company, and maybe adds an analytics tool that profiles whoever fills it in. The version designed with privacy by design asks only for what is needed to reply, protects the form from spam without tracking anyone, and keeps the request for as long as it takes to handle it, not forever.

# Data collected by the form: only the minimum needed to reply
email      # to get back to the person
message    # the request itself
# No mandatory name, no phone number, no profiling.

# Retention: the request does not stay forever
retention = 12 months  ->  then automatic deletion

Neither version breaks the law in any obvious way. But only the second builds protection into the system, instead of leaving it to the goodwill of whoever runs it. That is the difference Article 25 asks you to make.

Why it pays off, not just why it is required

Building this way is not a cost imposed by regulation. It is a better system, on every count that matters.

Less risk. Less data collected and kept means less damage when something goes wrong. A breach hurts less when there is little to steal.
More trust. A service that asks only for the essentials, and says so clearly, is one people trust more.
Lower costs. Building data protection in during development costs a fraction of what it costs to rework a system already in production to bring it into line.
Simpler compliance. When the right choices are already in the system, proving you respect the GDPR becomes a formality, not an emergency.

When a further step is needed: the DPIA

For processing that may carry a high risk to people, the GDPR requires an impact assessment, the DPIA. It is not mandatory for every project, but when it is needed it must be done before building, not after. That is exactly where privacy by design shows its worth: it lets you spot the risks while fixing them is cheap, on paper, rather than on a system already running.

Where to start

Privacy by design does not require exotic tools. It requires asking the right questions at the start of the project, and writing the answers into the code, not only into a document.

Map the data: what information enters the system, where it comes from and why it is needed.
Remove the superfluous: every field that does not serve a clear purpose has to go.
Set the deadlines: for each piece of data, decide how long it is kept and automate its deletion.
Close the access: minimum permissions, checked on every operation, not granted once and forgotten.
Document the choices: not instead of making them, but so you can prove them.

In the end, privacy by design is not a certificate to hang on the wall. It is a way of building: start from the question "do I really need this piece of data?" and let the answer drive the architecture. That is how custralis.com is built, and it is the approach behind every project: data protection not as a constraint to endure at the end, but as the starting point.

For how these principles become concrete technical choices, from the form to the CSP to the logs, in a real website:

Privacy and security by design, in practice: the choices behind a real website