Rolling Out an ERP in Stages Without Stopping the Business

ERP projects rarely fail because the software was wrong. They fail because the business was asked to change everything at once, on a date, while continuing to trade.

The alternative is not a slower project. It is a differently shaped one, where each phase delivers something usable and nothing depends on one high-stakes weekend.

Start where the pain is, not where the diagram starts

The instinct is to begin with the general ledger, because it is the foundation. That is architecturally sensible and practically wrong: finance is the area least likely to be in crisis, and a first phase that delivers nothing anyone was asking for burns the goodwill you need for the harder phases.

Start with whatever is currently costing the most manual work. Usually that is inventory or purchasing. Doing so buys credibility — the operations team sees the system solve a problem they actually have, and are far more willing to endure the next phase.

Each phase must stand alone

The test for a phase: if the project stopped here, would the business be better off?

If the answer is no, the phase is too small or wrongly cut. Phases that are only useful once the next three land are how projects end up half-implemented and abandoned, with the business running two systems and reconciling.

A sequence that generally works:

1. Item master and inventory. Get stock right first. Everything downstream depends on it and it is usually the biggest immediate win.
2. Purchasing and supplier ledger. Purchase orders, receipts, payables. Ties directly to inventory, so it reinforces phase one.
3. Sales and receivables. Orders, invoices, customer ledger.
4. General ledger and financial reporting. By now most transactions are already posting; this makes the accounts fall out of it.
5. HR, payroll and attendance. Genuinely separable, and often better run in parallel by a different group.
6. Analytics and management reporting. Only meaningful once there is real data.

Adjust the order to your pain. Do not skip the principle.

Data migration is most of the work

Every ERP project underestimates this. The system is ready weeks before the data is.

What has to happen:

Decide what actually moves. Open balances and current master data, almost always. Full transaction history, almost never — it is expensive, and the old system can be kept read-only for reference far more cheaply.

Clean before migrating. Duplicate suppliers, items with three spellings, customers who are the same person twice. Migrating dirty data means the new system is wrong on day one and gets blamed for it.

Someone from the business owns it. Not the vendor. Only your staff know which of the three “Ram Traders” is real.

Reconcile after loading. Stock value, supplier balances and customer balances in the new system must equal the old. If they do not, find out why before going live, not after.

Budget more time for this than seems reasonable. It is always more.

Run in parallel, briefly and deliberately

Parallel running — both systems, same transactions — is the safety net. It is also double work, so it has to be time-boxed.

Two weeks is usually enough to expose real problems. A month is tolerable. Three months means nobody has committed to the new system and staff have quietly decided the old one is authoritative.

Set the exit criteria in advance: when these specific reports match for these specific periods, the old system goes read-only on this date. Without a defined end, parallel running does not end.

Train on real work

Classroom training on sample data does not transfer. People learn the system by doing their actual job in it.

What works: pick the transactions each person does most, have them do this week’s real work in the new system alongside the old, with someone available to answer questions immediately. Slow for a week, permanent afterwards.

Identify one person per department who learns it properly and becomes the person others ask. They will handle most questions faster than any support channel, and their engagement is the strongest predictor of whether the department adopts the system.

Expect the productivity dip

For a few weeks after each phase, the business will be slower. Staff are learning, exceptions are being discovered, and confidence is low.

Plan for it rather than being surprised: do not go live at month end, during a festival season peak, or at fiscal year close. Tell management the dip is coming so it is a predicted event rather than evidence the project is failing.

Projects get abandoned during this dip. Knowing it is coming is most of surviving it.

Watch for the parallel spreadsheet

The clearest sign a phase has not landed: someone is still maintaining a spreadsheet.

It is never defiance. It is that the system does not do something they need, and rather than raising it they worked around it. Every one of those spreadsheets is a requirement you missed, and each one that survives means the system’s data is incomplete in a way nobody has told you.

Go looking for them, treat each as a bug rather than a discipline problem, and fix the underlying gap. A phase is not done when the software is live. It is done when the spreadsheets are gone.

Decide what “done” means before starting

Define, per phase, what has to be true: which transactions run only in the new system, which reports must reconcile, what the acceptable error rate is, and who signs off.

Without that, phases blur, nothing is ever formally complete, and the project runs indefinitely while everyone loses confidence in it.

If you are still deciding what to implement in the first place, custom vs off-the-shelf ERP for businesses in Nepal covers that decision.

We build and implement ERP software for businesses in Nepal, and we would rather phase a rollout over months than stake it on one weekend. Talk to us.