The best way to understand Magic Software Enterprises is to picture the least photogenic moment in corporate technology: a sales order trapped between Salesforce and an old ERP, while someone copies fields by hand and hopes the numbers match. Magic lives in that gap. Since 1983, the Israeli company has built tools and staffed projects that connect databases, enterprise apps, mobile screens and factory equipment. The brands changed - from an early rapid-application environment to Magic xpa, xpi, FactoryEye and MagicTouch - but the proposition stayed remarkably stable. Keep the systems that matter. Make them cooperate.
That proposition is almost defiantly practical. The software industry loves a clean break: replace the mainframe, move everything to the cloud, rebuild the application, start fresh. Most enterprises do not enjoy that luxury. Their systems encode decades of pricing rules, production quirks, regulatory controls and employee know-how. Magic sells a bridge across those constraints. It can build a new interface without discarding the old application, or move information between an ERP, CRM and shop-floor machine without pretending they were designed for one another.
Low-code before it had a conference badge
Magic began as Mashov Software Export, founded by David Assia and Yaki Dunietz as personal computers were entering business. Its early idea was metadata-driven development: describe business logic at a higher level, then let the platform handle much of the machinery underneath. Today that sounds like low-code. In the 1980s, it was simply a way to make scarce programmers faster.
The product family grew around two jobs. Magic xpa builds and modernizes business applications across desktop, web and mobile deployments. Magic xpi moves data and coordinates processes between applications. AppBuilder serves heavy-duty legacy environments. SmartUX puts modern mobile experiences over existing workflows. FactoryEye carries the integration idea onto the manufacturing floor, where equipment, planning software and quality systems often speak different dialects. MagicTouch extends the pitch into governed enterprise data and real-time analysis.
The alternatives are recognizable names: MuleSoft, Boomi, Microsoft, SAP, Oracle, Mendix and OutSystems. But Magic also competes with things procurement teams do not call products - custom scripts, point-to-point interfaces and heroic spreadsheet labor. Its distinction is breadth across old and new deployments, paired with people who will implement the result. That combination is valuable when a company cannot pause operations for a fashionable rebuild.
The software company hiding a consulting company
Here is the part that changes the picture. In 2024, Magic reported $552.5 million in revenue. Software sales contributed $38.2 million. Maintenance and technical support added $34.8 million. Consulting services produced $479.6 million. In other words, the product names explain what Magic knows; the service organization explains how it earns.
The model includes licenses, annual support, and professional work billed at fixed prices or by time and materials. It gives customers one accountable party from connector to deployment. It also creates a less glamorous risk: people must stay billable. At the end of 2024, 3,166 of Magic's 3,787 employees worked in technical support and consulting. When a large North American customer abruptly suspended significant time-and-materials projects in 2023, the effect carried into 2024 and cut that region's professional-services revenue by roughly $26.8 million.
That was the business model showing its seams. Software can be sold again with low incremental cost; consulting hours cannot. Magic's 2024 gross margin was 28.6%, well below the margins investors associate with pure SaaS. Yet services also keep the company close to the ugly, specific problems that generate product demand. The tension is not a bug to eliminate. It is the operating system of the company.
“Magic xpi runs as a silent engine in the background.”Mercer Rosenthal customer story
What failed first - and what finally worked
A manufacturing deployment offers the cleanest view of Magic's method. A global industrial company with more than 25 sites relied on a 25-year-old Excel reporting system. Reports took as long as 15 minutes to load. Security concerns grew. Plant teams stopped trusting the data. The company then spent 18 months with another vendor and still failed to establish reliable end-to-end data integrity.
What changed minds was not a grander promise. Magic started smaller. It ran a focused proof of concept, followed by a 90-day pilot at one plant. The team tested the complete data lifecycle, used industrial sensors for collection, and connected plant-floor sources to enterprise systems with xpi. Only after the information held together from source to report did the rollout expand. Eighteen more plants went live in 18 weeks.
The public case study does not disclose the contract price, which is consistent with Magic's quote-based enterprise sales. The economic case instead appears in avoided delay and manual work. Other published customers put numbers around those outcomes: Michelman said an automated JD Edwards and Salesforce link saved more than 60 hours a week and reached return on investment in under ten months; Remtron reported $63,000 in annual savings; Kinetico removed a 45-minute manual step from each order.
- Pick one workflow whose failure is visible and expensive.
- Prove the entire data path, not a pretty dashboard fed with sample data.
- Run one operating site long enough for users to challenge the numbers.
- Turn the validated pattern into a repeatable rollout kit.
This is the copyable bit. The failed attempt spent 18 months proving that activity is not integrity. Magic's sequence made trust the gate between stages. It is less about FactoryEye specifically than about rollout design: narrow the surface area, test live exceptions, earn belief in the output, then scale the known pattern.
A merger paid in shares, not magic beans
Magic entered public markets in 1991 and later traded in Tel Aviv. That chapter closed on February 24, 2026. Matrix IT acquired all of Magic through a reverse triangular merger. Eligible Magic shareholders received 0.5878202 Matrix shares for each Magic share - 28,861,564 Matrix shares in total - leaving them with 31.125% of the combined company on a fully diluted basis. Magic became a private, wholly owned Matrix subsidiary.
The logic is straightforward. Magic brought proprietary platforms, international reach and integration know-how. Matrix brought a larger set of IT services, cybersecurity, cloud capabilities and vendor relationships, particularly in Israel. Both were already controlled by Formula Systems, so the combination simplified a family tree as much as it created a new one. For customers, the promised payoff is a wider bench around the same integration products. For Magic, it is a chance to cross-sell without carrying the costs and scrutiny of a separate public listing.
The company entered the merger with momentum and complications in equal measure. Third-quarter 2025 revenue reached $161.7 million, up 13.1% from a year earlier. It had acquired Axiom Manufacturing Systems, released xpa updates and obtained SOC 2 Type II compliance. But its financial identity remained tied to project labor and customer budgets. Matrix does not remove that exposure; it makes the delivery machine larger.
Where this approach earns its keep
Magic fits organizations with heterogeneous systems, operational downtime they cannot tolerate, and valuable logic embedded in old applications. Manufacturers are obvious buyers because the factory floor rarely follows a clean cloud architecture. So are distributors, hospitals, banks and global businesses that need SAP, Salesforce, JD Edwards, custom databases and mobile workflows to agree on the same order, customer or asset.
Good conditions
Several critical systems, meaningful legacy investment, messy data ownership, recurring workflows, and a team willing to govern connectors after launch.
Bad conditions
A small greenfield stack, few integrations, no need for hybrid deployment, weak executive ownership, or a project that cannot define one measurable operational result.
It will not work merely because a company buys a platform. If nobody owns the source data, if process rules change by department, or if the pilot avoids real exceptions, integration only moves confusion faster. Nor is Magic automatically the right answer for a cloud-native startup with five standard SaaS tools. A lighter iPaaS or direct APIs may cost less and require fewer specialists.
Magic's endurance comes from accepting an enterprise truth that trend cycles prefer to ignore: most technology arrives before the old technology leaves. The company did not win by predicting one perfect future. It kept building translation layers between imperfect presents. Now, inside Matrix, the question is whether a larger services organization can preserve that patient specificity without turning every problem into a larger engagement. For customers with a factory to keep running on Monday morning, that answer matters more than the latest label on the software.