Magic Software (eDeveloper, uniPaaS, xpa) Migration
even without source code to read.
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.
You get the metadata read as the specification it really is, then the system rebuilt in something a developer can maintain. We do this for businesses in Australia, New Zealand, the UK and the US, at a fixed price.
- 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
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
Your system has no source code, and that is fine
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.
What the work actually is
Your system already documents what it does
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.
Get a fixed-price scopeWhat 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
Only the Magic work you actually need
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 scopeWhat people ask us about Magic
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 your Magic system does
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.
