The short answer
Rebuild it one module at a time. Choose an order that starts where the risk is manageable and the value is clear, keep the new module in sync with the old system, run both side by side until the new one is proven, then switch that module over and move to the next. Production never has to wait for the whole project to finish.
Why ‘we can’t stop production’ is the right instinct
In a manufacturer or print-on-demand operation, the ERP is not a back-office tool. Orders, purchasing, receiving and the warehouse all run through it. A big-bang replacement asks the business to switch everything at once and hope. In Panorama Consulting Group’s 2026 ERP Report, more than a quarter of organisations exceeded their project budgets, and a budget overrun is the mild version of what can go wrong when the switch happens on a single weekend.
The approach, step by step
- Stabilize first. Fix security gaps, put the code under version control with an automated build and test pipeline, and document how data flows between modules. You cannot change a system safely if you cannot release it safely.
- Map the flows. For each module, list what it reads, what it writes, and which other modules depend on it.
- Choose the order. Start with a module whose boundaries are clear and whose improvement people will feel, then follow the flow of work.
- Build each module with a two-way sync to the old system, so either one can carry the work.
- Run old and new side by side, compare results every day, and agree in advance what ‘proven’ means.
- Cut over that module only when it is proven, with a tested way back. Then retire the old screens and move on.
What ‘proven’ can look like
Agree the switch-over test before you build. Example criteria for the common order of work:
| Module | Why in this position | Example switch-over test |
|---|---|---|
| Order intake | Clear boundaries; every later step depends on clean orders | Every order entered in the new module appears correctly in the old system for two weeks with no manual fixes |
| Purchasing | Follows from orders; errors are visible and fixable | Purchase orders, approvals and supplier confirmations match the old process for a full buying cycle |
| Receiving | Depends on purchasing data being right | Receipts match purchase orders and stock levels agree in both systems |
| Warehouse | Biggest change for floor teams; benefits from clean upstream data | Pick, pack and stock counts agree with the old process through a peak week |
How it went at Stakes Manufacturing
Stakes Manufacturing runs a high-volume print-on-demand apparel operation on a core ERP the whole business depends on. Replacing it in one go was not an option.
A hybrid Sprint Pod, onshore and offshore, first stabilized the system: security hardening and a CI/CD pipeline on the existing Laravel codebase. Then order intake, purchasing, receiving and warehouse moved over one at a time, each proven before the next. A new warehouse management system cut dock-to-stock time. With the new modules in place, an AI layer now reads them and shows where spoilage is happening across the company.
Production paused zero times through more than 13 months of work.
A checklist before you start
- Pick a quiet window for each cut-over. For apparel, avoid the fourth-quarter peak.
- Decide which system is the source of truth for each record during the overlap.
- Test the way back before every cut-over, not after.
- Train the people who use each module in the week before it switches, not months earlier.
- Keep one owner on the client side who can say ‘go’ or ‘not yet’.
Where AI fits
Modernization and AI are not either-or. Clean, well-structured modules make an AI layer far more useful, and an AI layer can often start on the old system while modernization continues. At Stakes, the layer came once the new modules were in place; elsewhere it can come first.
Got a system you can’t afford to stop? Bring us one problem. We’ll map an order of work with you.
Bring us one problem →Related: Modernize & Integrate · Stakes Manufacturing case study · Do you need a new ERP to use AI?
Frequently asked questions
Can you modernize an ERP without downtime?
Yes, by rebuilding one module at a time, keeping it in sync with the old system and switching each module only when it is proven.
Which ERP module should you modernize first?
Usually one with clear boundaries and visible value, often order intake, then follow the flow of work: purchasing, receiving, warehouse.
How long does a phased ERP modernization take?
It depends on scope. Each module delivers value when it switches over, so the business does not wait for the whole project.
Is a phased approach more expensive than a big-bang replacement?
It can involve extra work to keep two systems in sync, but it spreads cost and risk and avoids betting the business on one switchover.
Can we add AI before modernization is finished?
Often yes. An AI layer can read the old system while modernization continues, and gets better as cleaner modules come online.
