The legacy PHP/Drupal ERP behind erp.netorigo.com still actively serves dozens of Hungarian SMEs. Migration to the modern Netorigo stack (Admin + Finance + Logistics + Storefront) is the strategic direction today — but there is no single path. There are four. Picking the right one for a given customer matters more than the execution itself.
The four patterns
1. Full cutover — 10 weeks. One weekend switch, then the legacy stays read-only for 90 days. Works when the tenant is under 50 people and processes are not heavily customised. High risk, low cost.
2. Parallel run — 12 weeks. Both systems run side by side for 4 weeks, recording the same transactions twice, with weekly reversals on one side. Risk low, cost high (~1.5x payroll burden during transition months). We pick this when the integrity of the accounting close is critical.
3. Strangler-fig — 6 months. Replace one module at a time. Storefront first, then Logistics, then Finance. The legacy ERP's APIs glue them together in the interim. Best when the customer's internal team needs time to catch up.
4. API-only — forever. Don't migrate at all; put a REST layer in front of the legacy and let modern UIs read from there. See the separate article on the topic. Picked when the tenant has neither capacity nor business reason for a full swap.
What migrates fast — and what does not
Fast (1–2 days, scripted):
- Customer master (name, address, tax ID, email).
- Vendor master.
- Product master basics (SKU, name, unit, price).
Slow (3–6 weeks, hand-tuned):
- Multi-level BOM hierarchies, with versions.
- Manufacturing routings, broken down by machine time and labour.
- Custom pricing rules (quantity tiers, customer-specific list prices).
Most projects fail because planning anchors on the fast-data estimates, and the slow-data slippage breaks the sprint priority.
Why we keep legacy reports for 90 days
Post-cutover, legacy ERP stays online read-only for 90 days. Full reporting still works. Two reasons:
- Auditor requests. The annual audit asks for the old formats, and we are not willing to port the old reports to the new system only for nobody to look at them again.
- Trust. The tenant's bookkeeper runs a weekly diff between the two systems. After 90 days without drift, they relax. This is a human problem, not a technical one.
One real story
12-person custom-electronics manufacturer. 8-week sprint, full cutover. NAV 2015 to the modern Netorigo stack. 4,200 BOMs, 1,847 customers, 137 custom reports (94 of which had not run in two years). Cutover Friday 18:00 to Monday 09:00. One 14-minute rollback on the payment_method.gateway_credentials key rotation. Six partner payments were affected, zero data loss.
The retro takeaway we wrote down: user training was scheduled for week 8, and everyone regretted it. Training should start in week 7, in parallel with UAT. One week of partial productivity could have been saved.
When to pick which
- Under 50 people, standard processes → full cutover.
- 50+ people, accounting integrity is non-negotiable → parallel run.
- Internal IT team needs to ramp up → strangler-fig.
- No migration capacity, but modern UI is required → API-only.
Pattern selection is not a technical decision — it is a business one. The technical execution is routine in every case today.