A DDR Lab research project examining whether functional legacy systems can remain operational through modern gateway architectures.
Project status: Proposed
Research series: Part I — Research Rationale
Implementation status: No experimental implementation has yet been completed.
Introduction
Modernisation is often treated as synonymous with replacement.
When a computer system can no longer communicate directly with a contemporary network, browser, authentication service or software platform, the usual assumption is that the system itself has become obsolete.
That assumption is not always correct.
A system may remain perfectly capable of performing the function for which it was designed while becoming incompatible with the technological environment that has developed around it.
DDR Lab intends to investigate that distinction through a deliberately demanding test case.
The proposed project will attempt to integrate a late-1980s Robotron administrative workstation into a contemporary Spanish digital administrative workflow.
The Robotron will not be connected directly to the modern Internet.
It will instead communicate with a Lenovo ThinkPad running Linux Trabant, which will act as a controlled gateway between the legacy environment and contemporary digital services.
The selected demonstrator will be Modelo 100, the Spanish Personal Income Tax return.
The purpose is not to discover a more convenient way to file a tax return.
It is to answer a more general engineering question:
Can a legacy system remain functionally useful when the technologies it can no longer support are moved to a modern interface layer?
1. The research hypothesis
DDR Lab distinguishes between two different forms of obsolescence.
The first is functional obsolescence.
A system is functionally obsolete when it can no longer perform its intended task with the reliability, capacity, security or accuracy required from it.
The second is interface obsolescence.
A system may remain capable of performing calculations, processing structured information, storing records or controlling equipment while being unable to communicate directly with the current technological environment.
Modern encryption, web browsers, authentication systems, network protocols and document formats evolve much faster than many underlying operational functions.
Replacing the entire system because its external interface has aged may therefore solve a problem considerably larger than the one that actually exists.
The proposed architecture investigates an alternative:
Legacy core → modern gateway → contemporary infrastructure
For this project:
Robotron → Linux Trabant → Spanish digital administration
The working principle is simple:
Don’t modernize the legacy system. Modernize the interface.
2. Why Robotron?
Robotron is not technically indispensable to the experiment.
An early IBM PC or another DOS-compatible administrative computer could be used to test essentially the same principle.
Robotron has nevertheless been selected for methodological reasons.
The machines belong to a computing ecosystem developed in the former German Democratic Republic and represent a technological environment that has disappeared almost completely.
Successfully integrating such a machine into a contemporary workflow would therefore provide a deliberately extreme demonstration of interoperability between technological generations.
The objective is not to transform the Robotron into a modern computer.
Its age is part of the experiment.
The system should remain as close as reasonably possible to its original technical environment and perform only tasks that are appropriate to its capabilities.
The final Robotron model has not yet been selected. Hardware availability, operating condition, documentation, interfaces and acquisition cost will form part of the technical assessment before implementation begins.
3. Why Modelo 100?
A tax return may be legally complex, but computationally it ultimately consists of structured information, relationships between fields, validation rules and calculations.
The user interface through which those values are currently entered is not the tax calculation itself.
This distinction makes Modelo 100 an unusually useful demonstrator.
The Spanish Tax Agency permits tax returns prepared using external software to be submitted by importing a file containing data adjusted to the published record design. The current procedure includes the import of an XML file generated by an external application.
Official technical guidance is available from the Agencia Estatal de Administración Tributaria:
How to file an Income Tax return using a file generated by external software
This provides an important conceptual separation:
preparing structured tax information and interacting with the modern electronic administration are not necessarily the same computational task.
The Robotron would therefore not attempt to reproduce Renta WEB, execute a modern browser or authenticate a taxpayer.
Its role would be considerably narrower.
It would process a controlled experimental dataset and produce a documented intermediate representation of the relevant information.
Conceptually, that representation might initially be as simple as:
DDR-TAX/1.0
TAX_YEAR=2025
TAXPAYER=TEST000001
EMPLOYMENT_INCOME=32450.00
WITHHOLDINGS=5120.00
RESULT=-284.50
STATUS=VALIDATEDThis would not constitute an AEAT submission file.
It would be the internal exchange format between the legacy workstation and Linux Trabant.
The gateway would be responsible for translating that information into whatever contemporary structure is required for the next stage of the workflow.
4. Linux Trabant as the boundary system
Linux Trabant will perform the functions that cannot reasonably be delegated to the legacy computer.
- contemporary networking;
- modern browser execution;
- encrypted communications;
- electronic certificates and authentication mechanisms;
- data conversion;
- integrity checking;
- current storage formats;
- interaction with web-based administrative services.
The architecture therefore separates stable functions from rapidly evolving ones.
The Robotron does not need to understand TLS, current browser engines or electronic identification.
It needs only to understand the protocol agreed between itself and the gateway.
That protocol can remain intentionally simple.
If the external administrative environment subsequently changes, the objective would be to modify the gateway rather than redesign the legacy application.
5. Why use a Tax Administration as the reference environment?
There is a second reason for selecting tax administration as the demonstrator.
Large public and private organisations rarely modernise every technological layer simultaneously.
They evolve incrementally.
Contemporary user interfaces may coexist with applications and data-processing layers whose technological origins are considerably older.
The Spanish Tax Agency itself provides an instructive example.
Official Spanish Government documentation published in 2026 refers expressly to applications developed in COBOL/DB2, proprietary IBM z/OS environments and projects intended to migrate some of those applications towards Java and Oracle architectures.
That information does not establish that any particular tax census, database or application uses COBOL, nor does DDR Lab intend to speculate about internal systems for which no public technical information is available.
It demonstrates something more relevant to this research:
Legacy and contemporary technologies can coexist inside a modern digital organisation.
A modern workstation can provide the interface to applications whose underlying architecture originated in a very different technological generation.
The proposed Robotron experiment makes that separation unusually visible.
6. Modernisation does not require simultaneous replacement
The conventional image of technological progress is linear:
old system → replacement → new system
Real infrastructures are frequently more complicated.
A more realistic model may be:
stable legacy component → adaptation layer → new services
The important engineering question therefore becomes not:
How old is this system?
but:
Which of its functions have actually become obsolete?
A thirty-year-old system performing a narrow, deterministic and well-understood function is not necessarily equivalent to a thirty-year-old network interface exposed directly to contemporary threats.
Those components present different risks and should not automatically be treated as a single replacement problem.
7. The economic question
Replacement costs are also frequently underestimated.
The cost of modernising a legacy environment is not limited to purchasing new hardware.
A complete replacement may involve:
- software redevelopment;
- data migration;
- integration work;
- testing;
- user retraining;
- new licences;
- replacement of compatible peripheral equipment;
- operational interruption;
- documentation;
- cybersecurity validation;
- regulatory approval or recertification.
In complex environments, the secondary costs may considerably exceed the price of the replacement equipment itself.
Consequently, preserving a stable system while modernising only the interface can sometimes represent a significant economic and budgetary advantage.
The principle is not:
Old equipment should always be preserved.
It is:
Before replacing a system, determine which part of the system actually requires replacement.
A legacy system should remain in service only when doing so continues to be technically safe, maintainable and economically rational.
8. Beyond tax administration
Modelo 100 is a demonstrator.
The research question extends much further.
Long-lived technical systems exist in railway signalling, industrial automation, manufacturing, laboratories, logistics, energy infrastructure, scientific instrumentation and specialised equipment.
In some of these environments, replacing a functioning component can trigger consequences far beyond the component itself.
A replacement may require interfaces to be redesigned, dependent systems to be modified and the resulting architecture to be tested or certified again.
A controlled gateway may, in appropriate circumstances, permit the functional core to remain stable while the external communication layer evolves.
This project does not suggest that an experimental Robotron architecture can simply be transferred to safety-critical infrastructure.
Railway signalling, medical systems, industrial control and similar environments require specialised engineering, redundancy, cybersecurity analysis, formal validation and regulatory compliance.
The experiment investigates the underlying architectural principle, not the certification of any particular implementation.
9. An intentionally exaggerated test
Using an East German computer from the late 1980s as part of a 2026 Spanish tax workflow may appear excessive.
That is partly intentional.
A marginal difference between two recent generations of hardware would make the principle difficult to observe.
The technological distance between Robotron and modern electronic administration makes the separation unmistakable.
If meaningful work can still be allocated to the legacy system while everything that genuinely requires contemporary technology is placed at the boundary, the experiment will demonstrate that technological age alone is an insufficient measure of functional usefulness.
In that sense, the apparently unusual nature of the project is methodologically useful.
10. What the project will not claim
DDR Lab will not claim that a Robotron has submitted a Spanish tax return unless such an experiment has actually been completed and documented.
At the present stage, it has not.
Nor will the project imply that the Robotron communicates directly with the Spanish Tax Agency if the interaction is actually performed by Linux Trabant.
The distinction is essential.
If successful, the claim will be narrower:
A legacy workstation successfully remained a functional component of a contemporary administrative workflow through a modern gateway.
That is the hypothesis to be tested.
11. Research outcome policy
DDR Lab does not regard confirmation of the original hypothesis as the only acceptable result.
This project may ultimately be:
Completed.
The proposed architecture operates substantially as intended.
Partially completed.
Some stages operate successfully while others prove impractical.
Suspended.
The experiment remains technically viable but cannot currently proceed.
Discontinued.
The project ceases because of technical limitations, unavailable components, disproportionate cost, lack of suitable hardware or another documented constraint.
Failure is an experimental result.
If appropriate Robotron hardware cannot be obtained within a reasonable research budget, that fact will be recorded.
If an apparently viable interface proves unreliable, that will be recorded.
If maintaining the legacy component ultimately proves more expensive than replacing it, that result would be particularly relevant to the original hypothesis.
The objective is not to prove that legacy technology should always survive.
The objective is to determine when it can, when it should, and when it should not.
12. Next phase
The next publication in this series will be the Technical Project.
It will define the proposed implementation in detail, including:
Robotron hardware and operating environment → local application → intermediate data format → physical transfer mechanism → Lenovo ThinkPad → Linux Trabant gateway → validation and contemporary administrative interface.
Hardware selection will remain open until a suitable operational unit can be located and assessed.
No experimental outcome will be assumed in advance.
Conclusion
The easiest solution to technological incompatibility is often complete replacement.
It is not necessarily the most intelligent one.
Systems should be replaced when their continued operation is unsafe, unreliable, uneconomic or incapable of meeting their functional requirements.
They should not necessarily be replaced merely because the world surrounding them has changed.
The Robotron–Linux Trabant project will deliberately place that proposition under unusually demanding conditions.
A computer from a technological ecosystem that no longer exists will be asked to perform a limited function inside a modern digital administrative process.
It will not be made modern.
The environment around it will.
A legacy system does not necessarily need to become modern in order to remain useful. Sometimes the boundary is the only part that needs to change.
