Legacy system migration: Magic, uniPaaS, Access, VB6
Many Israeli companies still run a system written ten or twenty years ago on Magic, uniPaaS, Access or Visual Basic 6. It does its job. The problem is not that it is bad, but that fewer and fewer people can change it.
In short
There are four paths, and a rewrite from scratch is not always the best of them. Keep and stabilize if the system works and rarely changes. Upgrade within the platform: Magic has a path from uniPaaS to Magic xpa. Migrate in parts: a new system grows next to the old one and takes over functions one by one until the old one is empty. Rewrite if the old platform already holds the business back. The choice starts not with technology but with two questions: where does the business logic live, and who can explain it today.
Why now
| Platform | What is known |
|---|
| Magic, uniPaaS | An Israeli platform. The product line ran from eDeveloper through uniPaaS to Magic xpa, and the product is still being developed. After the merger with Matrix IT, Magic left the stock exchanges |
| Visual Basic 6 | The development environment has long been unsupported. The runtime is supported for the life of supported Windows versions, but only for serious regressions and critical security issues, and only in 32-bit mode. Microsoft explicitly recommends replacing such applications |
| Microsoft Access | Support for Access 2016 and Access 2019 has ended. Access itself continues as part of Microsoft 365, so the question is not whether it disappeared, but which version your database runs on |
The common denominator is not the technology. It is that the person who wrote the system has retired or moved on, and new developers do not learn these platforms.
Four paths
1. Keep and stabilize
If the system works, changes once a year and its data is not needed by other systems, there is no need to rewrite it for fashion. What is needed is different: a backup that has been tested by restoring, a description of what the system does, and a person who can restart it.
2. Upgrade within the platform
For Magic, the vendor provides an upgrade wizard that moves eDeveloper and uniPaaS projects to Magic xpa. One important detail from the documentation: the upgrade is irreversible, and afterward the project cannot be opened in the old version. So this is done on a copy and with a test plan. This path preserves the logic but does not solve the people problem.
3. Migrate in parts
The new system is built next to the old one. First a modern layer connects to the old database: reports, a web interface, integration with other systems. Then functions move one by one to the new system while the old one keeps running the rest. The risk is lowest, because at any moment what worked keeps working.
4. Rewrite
This is justified when the old platform prevents what the business needs: no web access, no integration, the system cannot handle the volume. The most common mistake here is rewriting screen by screen instead of rule by rule. Screens are easy to move, but the rules hidden inside them get lost.
Where the business logic hides
In systems of this age, the logic rarely lives in one place. It is usually spread across three:
- In screen and procedure code: a discount calculation, a stock check, a rounding rule.
- In the database: triggers, stored procedures, fields that fill in by themselves.
- In people's heads: at month end, you press this button twice. That rule is written nowhere except in an employee's habit.
The third place matters more than the first two. A migration that covered the code and the database but did not talk to people will reproduce a system nobody actually uses.
So the first step in any path is the same: recover what the system does. AI is a good helper here. It reads old code quickly and proposes a description, which is then checked against real data and with the people who use the system.
How to choose
| Question | If yes | If no |
|---|
| Does the system change more than once a quarter? | Upgrade or migrate in parts | Keep and stabilize |
| Do other systems need its data? | Migrate in parts, starting with integration | No rush |
| Is there someone who understands it? | Less urgent, but write down what they know | Urgent, start with the description |
| Is the platform holding the business back? | Rewrite, but by business rules | Upgrade or stabilize |
Frequently asked questions
What should we do with a system on Magic or uniPaaS?
There are four paths: stabilize as is, upgrade to Magic xpa with the vendor's wizard, move functions in parts to a new system, or rewrite. The choice depends on how often the system changes, whether other systems need its data, and whether anyone understands it.
Can uniPaaS be upgraded to Magic xpa?
Yes, the vendor provides an upgrade wizard for eDeveloper and uniPaaS projects. According to the documentation the upgrade is irreversible, so it is done on a copy and with a test plan.
Is Visual Basic 6 still supported?
The development environment is not. The runtime is supported together with supported Windows versions, but only for serious regressions and critical security issues. Microsoft recommends replacing such applications.
Do we have to rewrite an Access system?
No. If the database works and rarely changes, it is enough to stabilize it and check the Access version. Migration is justified when many people use it at once, or when web access or integration is needed.
Can AI help migrate an old system?
Yes, especially in the description stage: AI reads old code quickly and proposes what it does. But the description is checked against real data and with the people who work with the system, or the rules that are not in the code get lost.
Where to start
Tell me what the system is written in, how many people use it and whether someone understands it. That is enough to know which of the four paths to look at first.
Talk to me
Related: Integrations, Prototype to production
SLAtech LTD