Migrating from Epicor ERP: a plan that protects production
Whether the destination is another ERP or Epicor's own cloud, the risks are the same: data, customisations and the weeks around cutover. This is how to sequence them.
Contents
An ERP migration in a manufacturing business is judged by one thing first: whether jobs kept shipping. Everything else (the new screens, the reports, the AI features) comes after. The plan below is built around that test.
The dates that frame the project
For on-premises Kinetic, Epicor's last feature release is planned as 2028.1, tentatively in January 2028. Active Support ends on December 31, 2029, and Sustaining Support begins on January 1, 20301. Those dates apply whether the destination is another ERP or Epicor's own cloud, because a move to the Epicor Cloud is also a migration.
Working back from the end of 2029, a manufacturer needs time to select a system, clean its data, configure and test, run the old and new systems side by side, and stabilise. Vendors' stated timelines cover only part of that:
| Destination | Stated timeline | What the vendor says about method |
|---|---|---|
| Epicor Cloud (Ascend) | As little as 90 days for qualified deployments2 | AI audits the environment, extracts and organises data and generates a migration plan; covers on-premises customers and non-Epicor replacements |
| JobBOSS² | About 3 to 6 months3 | Implementation with US-based support |
| OpenLazarus beside the ERP | Usually a few weeks for a shop of about 200 people, by its own estimate4 | Engineers connect the ERP, phones and drawings; the ERP is not replaced |
| Acumatica, Infor, Business Central, NetSuite, Plex, Global Shop Solutions | Not stated on the pages we read | Partner-led or not described |
Epicor's 90-day figure applies to "qualified" deployments, a term the announcement does not define, and the republished announcement's figure of implementations up to 40% shorter comes without a stated baseline2.
What has to move
Three layers of data, in order of risk
- Master data: parts, bills of material, routings and operations, work centres, customers, suppliers, price lists and units of measure. Errors here break every job that follows.
- Open transactions: released jobs, open purchase and sales orders, inventory by location and lot, and open receivables and payables at cutover.
- History and balances: opening financial balances, plus whatever job and quality history customers or auditors may ask for. Much of this can sit in a read-only archive instead of being converted.
Customisations are the fourth layer and often the largest. Screen changes, custom reports, integrations and workflow rules built over years in Epicor do not move by themselves. Each one needs a decision: rebuild it, replace it with a standard feature, or retire it. Epicor itself sells an AI developer agent for App Studio that it says cuts the time to build and test screen customisations by an average of 60%, a vendor figure that also shows how much effort customisation carries5.
Two ways to sequence the move
All at once. The new ERP replaces Epicor on a single cutover date, ideally at a quiet point in the production calendar, with a short period of parallel running. This is quicker on paper and concentrates the risk in a few weeks.
In phases. The office work around production changes first, while Epicor keeps running: quoting, purchasing follow-up, supplier and customer mail, quality records. The ERP moves later. This spreads the change, and the first phase delivers value whatever the ERP decision. OpenLazarus is designed for that first phase: it reads jobs, routings and inventory from the existing ERP and writes back what changes, and its manufacturing page says most shops keep the ERP for job costing and the books4. It is not a migration tool for the ledger, and it has no published manufacturing case studies, so the phase should be scoped and measured like any pilot.
Risks to plan for
- Dirty master data. Duplicate parts and outdated routings cause wrong costs and wrong schedules on day one. Clean before converting, not after.
- Lost tacit knowledge. Long-serving planners know which routings are wrong and which customers need special handling. Put them on the team.
- Too short a parallel run. Plan to close at least one month in both systems before switching off the old one.
- Unpriced customisations. Inventory every report, integration and screen change, and assign a decision to each before signing.
- Support gaps. Confirm what Epicor support covers during the project, and when Sustaining Support begins for your product1.
The plan, step by step
- Set the go-live window from the production calendar and Epicor's support dates, with a buffer before December 31, 2029.
- Inventory customisations and integrations, and decide what to rebuild, replace or retire.
- Clean master data in Epicor while it is still the system of record.
- Change the office work first if it is the constraint, and measure it: quote turnaround, purchase-order follow-up time, certificates filed.
- Run scripted tests with real jobs, parts and routings in the new system.
- Run in parallel through at least one month-end, then cut over.
- Stabilise for 90 days before adding new modules or features.
The end state is a plant that shipped on time through cutover, a ledger that reconciled in the first month, and an office that spends its hours on customers and suppliers rather than on re-keying. Compare the destinations in the main guide.
Questions buyers ask
How long does an Epicor migration take?
Stated timelines vary. Epicor's Ascend programme targets go-live in as little as 90 days for qualified cloud deployments, and ECI states about three to six months for a JobBOSS² implementation. Plants with many customisations, several sites or poor master data should plan for longer and include a period of parallel running.
What data should move from Epicor to a new ERP?
Master data (parts, bills of material, routings, work centres, customers, suppliers and price lists), open transactions (jobs, purchase orders, sales orders and inventory balances) and opening financial balances. Detailed history is often archived in a read-only copy rather than converted.
Can we migrate in phases?
Yes. A common pattern is to change the office work around production first, while the ERP stays in place, then move the ERP at a quiet point in the production calendar. Systems that sit beside the ERP, such as OpenLazarus, are built for that first phase.
Sources
- Epicor announces schedule of final on-premises feature releases for Kinetic, Prophet 21 and BisTrack. Epicor (Business Wire release, republished by 01net), 6 Jan 2026. Accessed 8 Nov 2026.
- Epicor delivers 90-day cloud ERP with AI-driven Ascend program. TechIntelPro (republished Epicor announcement), 20 May 2026. Accessed 8 Nov 2026.
- JobBOSS²: centralize job shop data and scale operations. ECI Software Solutions. Accessed 8 Nov 2026.
- OpenLazarus for manufacturing. OpenLazarus. Accessed 8 Nov 2026.
- Epicor Prism launches across European markets, bringing embedded, industry-specific AI to manufacturers. Epicor (Business Wire release, via TT), 23 Jun 2026. Accessed 8 Nov 2026.
Updated 8 Nov 2026: First published.