Legacy Software Modernization: AS400, VB6 and .NET Framework

Legacy software is not simply old software: it is software that still works, still supports important processes, and that nobody can safely change any more. In manufacturing and logistics SMEs in Emilia-Romagna it almost always takes the same shape: a business system on AS400/iSeries that has been running for twenty years, a shop-floor program written in Visual Basic 6, an application on an outdated .NET Framework version that only runs on one server nobody dares switch off.

The symptoms that make the intervention urgent are always the same: only one person can touch the code, the system does not talk to anything that was added later — e-commerce, field sales apps, customer portals — the operating system and database versions are out of support, and every small change takes weeks. At that point the cost of doing nothing stops being theoretical: it is paid in manual work, in lost commercial opportunities and in downtime risk.

Modernization, however, is not the same thing as rewriting. Rewriting everything is the most expensive and riskiest option, and it is often unnecessary: in many cases the existing system is solid within its own scope and the real problem is that it stays isolated. That is why the first step is always to understand what you are dealing with, rather than deciding the destination in advance. Our software development method starts from observing the real processes, and on a legacy project that matters even more, because part of the business rules are written nowhere except in the code.

strategy

API wrapping

Wrapping means exposing the legacy system's functions through modern APIs, leaving the system exactly where it is. The business system keeps working the way it always has, but stops being an island: from that moment a field sales app, an e-commerce or a customer portal can read stock levels and write orders without anyone retyping anything. It is the fastest and least invasive intervention, and it makes sense when the system is stable and covers its scope well: the problem to solve is isolation, not application logic. The limit has to be stated plainly: wrapping does not reduce the underlying technical debt, and it does not remove the risk of having a single person able to maintain that code. It solves the integration problem, which is often what blocks the business right now, and buys time to plan the rest calmly.

strategy

Strangler fig

The strangler fig is the strategy we propose most often on systems already in production. The idea is to replace the legacy one module at a time rather than in one go: you pick a function, rewrite it on a modern stack, put it live alongside the old one and move the traffic across only once it has proven itself. Repeating the cycle, the old system's scope narrows progressively until it runs out. The advantage is not technical but about risk: every step is small, measurable and reversible, and value arrives from the first module rather than at the end of a long project. In exchange it demands discipline — for a period two systems coexist and must be kept in sync — and a careful choice of module order, which we decide together with the company, starting where the operational pain is greatest.

strategy

Full rewrite

A rewrite rebuilds the application from scratch on current technology. It is the route that gives the widest room to manoeuvre — a rethought data model, no inherited constraints, technical debt reset to zero — but it concentrates all the risk into a single switch: until the new system is complete it produces no value, and the comparison with the old one happens all at once. That is why we propose it when the incremental alternatives genuinely do not hold: when the underlying technology is no longer supported or hostable, when the data model blocks any evolution, or when the processes the software supports have changed so much that replicating them would make no sense. In those cases rewriting is the honest choice, and it has to be tackled with a designed and reconciled data migration, not one improvised at the end.

None of the three strategies is chosen upfront. The path is always the same, and the decision comes at the end of the second phase, when there is concrete evidence to base it on:

1. Application portfolio assessment: we read the code and the database, map the existing integrations and watch how people actually use the system. This distinguishes live modules from the ones nobody has opened in years, and surfaces the business rules that exist only in the code.
2. Strategy selection, module by module: the decision is not a single one for the whole system. On the same business system it is common to expose the master-data side through APIs, incrementally rewrite the order cycle, and leave an accounting module that works well completely untouched.
3. Securing the data foundation: before moving any function, the data is analysed, normalized where needed and given repeatable migration procedures, rehearsed on real copies until the totals reconcile.
4. Incremental migration on a dual track: the new functions go live alongside the old ones and the two systems stay aligned through connectors, so every step is reversible at the single-module level.
5. Onboarding and decommissioning: users move to the new system gradually, with on-the-job training; the legacy is switched off only once its remaining scope is empty, not before.

What drives the cost of a project like this, and how a quote is put together, is covered on the custom software cost page. Once modernized, the system enters the evolutionary software maintenance path, because technical debt builds back up if nobody keeps it in check.

What determines whether an incremental modernization succeeds is not the rewriting: it is the link between old and new while they coexist. We build connectors and middleware towards AS400/iSeries, SAP and the business systems already in use, so that master data, stock and orders stay aligned throughout the transition, with no double data entry and no mismatch between stock and orders. The work builds on custom web APIs and on the same software testing and QA practices we apply on greenfield projects.

Where the business system does need replacing, the destination is a custom ERP business system modelled on how the company actually operates, supported where needed by a custom CRM and by business process digitalization for the flows that today live outside the system, between Excel and email.