I think the “shoe-horned SaaS” comment mostly comes from the fact that Kinetic is still fundamentally an on-prem ERP architecture that has been containerized and hosted, rather than redesigned as SaaS from first principles.
Firstly,Database architecture
Epicor is still tightly coupled to Microsoft SQL Server with a schema that assumes a single tenant, single logical owner of the database. Multi-company and hosted multi-tenant scenarios are handled with guardrails, BPMs, and operational separation rather than true tenant isolation.
A SaaS-native ERP would typically have:
- Strong tenant isolation at the data layer by design, not convention.
- Either logical tenancy with enforced row-level security everywhere, or physical tenancy with sharded or distributed data stores.
- Minimal assumptions in the schema about a single customer owning the entire database.
- The entire security model of Epicor needs to be re-done to handle row level permisions across the ERP
Epicor’s schema and transaction patterns reflect decades of single-tenant assumptions, and those assumptions leak everywhere.
Business object and service layer
While Epicor exposes REST endpoints, the core business logic is still built around legacy BO patterns that originated in Progress and were converted largely 1-to-1. These BOs are stateful, chatty, and transaction-heavy. Hell there are very few BOs in Epicor that can handle true multi row CRUD. Everything is single row edits
A SaaS-native system would typically:
- Be designed API-first, not BO-first.
- Use stateless services with clear ownership boundaries.
- Favor coarse-grained, idempotent APIs over tightly coupled server-side workflows.
- Avoid long-running server transactions that assume persistent session state.
Epicor REST often feels more like a transport wrapper around legacy server logic than a system designed around RESTful principles from the start.
Epicor still carries a strong assumption of session state, server affinity, and predictable user counts. Kubernetes and containers help with packaging and deployment, but they do not automatically make an application cloud-native.
In a true SaaS ERP you would expect:
- Horizontally scalable stateless application tiers. (Serverless)
- Clear separation of read and write workloads.
- Event-driven or asynchronous processing for long-running operations.
- Built-in resilience patterns rather than operational workarounds.
Epicor can scale, but it scales more like a hosted on-prem system than an elastic SaaS platform.
Releases are a mess
Even with more frequent releases, Epicor still behaves like a product that expects customer-specific validation, regression testing, and change management. That is a very on-prem mindset.
True SaaS systems are designed so that:
- Features are rolled out progressively.
- Backward compatibility is enforced at the API level.
- Customers do not need to deeply understand internal changes to remain stable.
Epicor’s architecture makes that much harder than it would be in a ground-up SaaS design.
Not to mention our beloved Customizability. BPMs run at the core level of the application and can and do affect every aspect of the RUN Time this was written on the assumption of a single tenant and single runtime control. A BPM shouldn’t be able to take down an entire SaaS deployment and its neighbors but today you can do that with a Bad BAQ or BPM.
