The legacy ERP ships with about 40 predefined workflow templates. RMA processing, drop-ship orders, multi-warehouse transfers, production scheduling, inventory-variance closing — covering the Hungarian SME workflows that crystallised through the early 2010s. Templates are tenant-overridable (custom steps, custom approvers), and the overwhelming majority port cleanly to the modern Admin → Flows engine.
What a template gives you
Every workflow template carries four things:
- Step graph. Process states and transitions (e.g. RMA:
received → inspecting → approved → refunded). - Role mapping. Which step needs which user role (warehouse worker, warehouse lead, bookkeeper).
- Event hooks. Which step transition fires which system event (invoice correction, stock adjustment, email notification).
- SLA timer. Optional per step — e.g. RMA
received → inspectingmax 48 hours, otherwise escalation.
In the legacy ERP the templates are PHP classes (workflow_*.inc.php); tenant overrides live in a YAML config file. The modern Admin → Flows engine stores the same shape in JSON definitions, editable through the tenant UI.
37 of 40 port cleanly
During migration we audit all 40. 37 go straight through: the step graph rewrites to JSON, role mapping migrates 1:1, event hooks point at the modern stack's equivalent APIs, the SLA timer drops into the new Flows-engine timer system. For a mid-sized tenant this is 2–3 engineer-days.
The three that DON'T port cleanly
1. Hungarian EKAER reporting workflow. Alive since the 2015 EKAER rules, the entire flow is wired to NAV's legacy WSDL API which NAV has not actively supported since late 2024. We do not rebuild this in the new stack; NAV Online Számla 3.0 is a different beast. Tenants who still use it stay on the legacy ERP for this module until NAV switches the WSDL endpoint off. That becomes a hard migration-stop point.
2. Two-step customs declaration. Non-EU (Swiss, UK) shipments have a custom template integrating with a third-party (PHP-based, vintage 2012) customs-broker service. The service's API is exotic (XML-RPC), only two of our clients use it, and both contractually requested we leave it untouched. The modern Flows engine has no XML-RPC client, and we will not add one for two customers.
3. Payroll-from-ERP. The legacy ERP has an integrated payroll module — the modern stack deliberately does not. Payroll in Hungary is a regulatory minefield, and we don't want dedicated-payroll-software responsibility. Tenants currently using legacy payroll either stay on legacy for it or move to an external Nexon/KulcsBér/Magasház-style solution.
What this means for the migration project
Practical impact: workflow migration usually lands in weeks 4–6 of the sprint plan, averaging 4–7 engineer-days for a 12–25 person tenant. Using any of the three non-portable templates does not block migration — the legacy ERP simply lives on for those flows, in API-only mode, while the new stack takes over the rest.
A rhetorical question
Why don't we rebuild the three problem templates? Because they're not worth it. The NAV WSDL is sunsetting, customs XML-RPC has two users, payroll is its own profession. Modern Netorigo stack capacity creates more value on the 37 templates plus brand-new workflows than on three where market retreat solves the problem for us.
The workflow layer of an ERP is always the last thing to migrate because it holds the most tenant-specific knowledge. The template-based approach works precisely because it standardises the bulk — and concentrates tenant-uniqueness into the override layer.