A Shop-Floor Alternative to Epicor ERP

By reading it out of the system and rewriting it as ordinary code. Epicor ERP customisation lives in BPM directives and embedded C#; we inventory it, discard the rules nobody triggers any more, and re-express the rest as TypeScript over PostgreSQL in your repository, reviewed and tested in GitHub Actions like any other change. The gain is not writing speed. It is that upgrades stop re-validating custom logic that lives outside version control.

Epicor ERP stores its data in SQL Server, so extraction is a well-understood ETL problem: map the base tables, the user-defined fields and the BPM logic, pipe them into a normalised PostgreSQL schema with Drizzle ORM, then run both systems in parallel until the numbers reconcile. 8 to 12 weeks is typical for a single-plant mid-market Epicor deployment. Multi-plant and heavily modified installs run longer, and those get scoped separately rather than averaged in.

That is the risk that actually kills these projects, so it is worth being blunt. Epicor is already moving its user experience into the browser, meaning operators face retraining either way. What a custom build changes is who chooses the screens: order entry, labour capture and job costing get designed around your routings and run as a React interface on tablets at the cell, showing the three or four actions an operator performs rather than a full Epicor menu tree.

Manufacturers leaning hard on Epicor's advanced planning, MES or quality modules, and plants that need on-premises deployment — which Epicor still supports alongside hybrid. Those modules carry decades of accumulated manufacturing detail. A custom ERP makes sense when you use only a narrow slice of Epicor ERP, when upgrade consulting is a recurring line item, or when the software cannot describe how you actually schedule manufacturing work.