Magic Software (eDeveloper, uniPaaS, xpa) Migration
for businesses in Australia, New Zealand, the UK and the US.
Magic Software renamed its platform twice, from eDeveloper to uniPaaS to Magic xpa. Applications are defined as metadata in tables rather than written as source, so there is no source code to read in the usual sense.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
There is no source code, and that surprises everyone
Magic is genuinely different. You do not write code, you fill in tables that describe the program, and the runtime executes that metadata. It made development fast and it means a developer asking to see the source has misunderstood what exists.
Magic built a lot of ERP and distribution software, often through partners, and the applications are frequently mission-critical. The renames make research harder than it should be, because the same product has three names depending on when you last looked.
Your Magic project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
Export the metadata, then read it as the specification
Because the program is metadata, it can be exported and read systematically. That turns out to be an advantage: the definition of what the application does is far more complete than most legacy source code.
What you have now
- An eDeveloper, uniPaaS or Magic xpa application
- Program logic held as metadata, not source
- A supporting SQL or ISAM database
- A partner who may no longer be trading
Export the metadata, then read it as the specification
Because the program is metadata, it can be exported and read systematically. That turns out to be an advantage: the definition of what the application does is far more complete than most legacy source code.
See how a project runsWhat you end up with
- The application logic documented in readable form
- Data migrated and reconciled into a standard database
- A replacement on a mainstream stack
The 5 pieces of Magic work we are asked for
Most engagements are some combination of these, and most start with the first.
Export the application definition
Program metadata exported and read as a specification. It is unusually complete compared with reading somebody else’s source.
Document the business rules
Turned into readable documentation, which is normally the first time anyone in the business can see what the system actually does.
Migrate the data
Into SQL Server or PostgreSQL, reconciled against the original before anything is trusted.
Rebuild on a mainstream stack
A web application on something with a normal hiring market and no runtime licence.
Stage it by module
These applications are usually modular, which makes a phased replacement realistic rather than all at once.
Where you are now
It works, and nobody will touch it
- No source code in any conventional sense
- Three product names for the same platform, which confuses every search
- A partner who may no longer be trading
- Runtime licensing and an empty hiring market
After
Supported, documented and yours
- The business rules documented in plain language
- Data in a standard database
- A mainstream stack you can hire for
- No runtime licence to renew
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeMagic questions
Where is our Magic source code?
There is not any, in the usual sense. The application is metadata held in tables and executed by the runtime. That is not a problem once you know it, and the metadata can be exported and read.
Is eDeveloper the same as Magic xpa?
Same lineage, different names. eDeveloper became uniPaaS and then Magic xpa. The renames are why searching for help returns three apparently different products.
Our implementation partner has closed. Can you still help?
Yes, and it is the most common reason we get this call. The metadata is exportable and the database is accessible, so we do not depend on the original partner being available.
Can this be replaced in stages?
Usually yes. Magic applications tend to be modular, so replacing one module at a time against the same database is realistic and much lower risk.
How do we know nothing is missed?
The exported metadata is the specification, and it is more complete than most legacy documentation. We work from that and reconcile the data against totals the business already trusts.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
