Legacy System Modernization
Leave your legacy system without stopping operations — and keep the code.
We did it on our own system. We show you yours in a measured sample.
We migrate systems module by module: each module is specified, rebuilt, verified against the current system and only then switched over. Your operation keeps running and the resulting code is yours from day one.
Entry points
Where do you want to leave from?
Leaving GeneXus or another proprietary low-code platform
You regain control of the code and stop depending on a proprietary environment and license.
Java or .NET systems with no written specification
Systems that work but that nobody can describe in full. We document them first, then migrate them.
What to retire, absorb or rebuild when an ERP arrives
When NetSuite, SAP or another ERP comes in, we decide with data which modules are retired, which the ERP absorbs and which are rebuilt.
Documenting a system to tender it, audit it or maintain it
A verifiable specification of the system as it is today, useful for a tender, an audit or maintenance.
Method
Seven phases, module by module
The seven phases repeat for every module, so the new system grows while the old one keeps operating.
Discover
Inventory of the real system: objects, data, integrations and rules.
Specify
Current behavior is written down as a verifiable specification.
Migrate data
Data moves to the new schema with its identifiers preserved.
Build
The module is implemented against the specification.
Interface
The user interface is rebuilt on top of already-verified operations.
Verify
The new module is compared against the current one and differences are documented.
Switch over
Operation moves to the new module, with rollback available.
Guarantees
- No module switches over without signed parity.
- Every switch-over is reversible in minutes.
- The code belongs to the client from day one.
AI agents
How we use AI agents
Specification before code
First we write what the system does; the code follows from that specification.
Agents implement against it
AI agents build the module against the specification, not against assumptions.
One test per clause
Every clause in the specification has an automated test that proves it.
Mandatory human review
A person reviews and merges every change. AI speeds things up; it does not decide on its own.
This is the agentic software development method applied to migration: here it lives as a method, not as a product.
Evidence
We did it on our own system
Migration of SISCON's management system off GeneXus
Complete exit from the proprietary environment and data migration with identifiers preserved.
Migration analysis of a rail logistics and transport system
The existing documentation underestimated the real size of the system. That is why the first step is to measure.
How to start
Three steps, no commitment to migrate
Measured sample, at no cost
5 to 10 screens of your system turned into a verifiable specification, with its tests and an inventory of differences.
3-to-5-week diagnostic at a fixed price
The real schema, a wave-by-wave plan, the estimate and the license spend that goes away.
Wave-by-wave migration
Quoted from the measured inventory, not from assumptions.
FAQ
Frequently Asked Questions
Do I have to stop operations to migrate?
No. We migrate module by module and none switches over without signed parity. In our own case it was 0 days of downtime.
Who owns the resulting code?
The client, from day one.
What if something fails at switch-over?
Every switch-over is reversible in minutes.
Where do I start?
With the measured sample, at no cost: 5 to 10 screens turned into a verifiable specification.
🔗 Related: ERP query agent — SISCON's second product, in production in our own ERP.