Yes, a phased ERP rollout for small business is usually the safer route. If you have roughly 10 to 50 staff, go live in two to four stages rather than switching everything on one weekend. The main exception is a single site with very few users and simple processes. The staging logic is the same whether you are planning custom ERP software development or buying a packaged system.
The thresholds in this article, including the 10 to 50 staff range, the week counts and the user numbers, are Treevoxa's rule-of-thumb working figures from building and rolling out business systems. They are not industry standards. Where a figure comes from someone else, it is cited.
1Should a small business roll out an ERP in phases?
For most, yes. A big bang rollout moves every module and every user to the new system on one date. A phased rollout moves in steps. You can phase by module (finance first, then stock), by site (head office, then the second branch), by business unit, or by process (sales orders, then invoicing).
For a business of this size, phasing by module is usually the most useful. It keeps each step small enough to check, fix and, if needed, reverse.
2Phased or big bang: which suits a business of 10 to 50 staff?
On big bang vs phased ERP implementation, the trade-off is simple. Phasing reduces the size of each mistake but adds length and temporary plumbing. Big bang is quicker on paper but puts all the risk on one date.
| Phased | Big bang | |
|---|---|---|
| Risk | Spread over several small go-lives | Concentrated on one go-live |
| Typical length (our rule of thumb) | About 5 to 9 months end to end | About 3 to 5 months, with a harder final push |
| Cost | Extra for temporary bridges and repeated cut-overs | Lower build cost, higher cost if the go-live fails |
| Staff disruption | Smaller each time, but repeated | One large disruption |
| Bridges needed | Yes, between old and new systems | Few or none |
| Best for | Stock, payroll, several sites, many spreadsheets | One site, few users, simple processes |
Phasing has real downsides. You pay for bridges you will throw away. Management attention is spread over months. Staff can tire of being asked to change again every six weeks. Panorama Consulting also sets out the big bang and phased trade-off if you want a second view.
Our rule of thumb:
- Go big bang when you have one site, fewer than about 10 users, no real stock and no payroll complexity. A small services firm moving from spreadsheets and accounting software to one system is the typical case.
- Phase it when stock, payroll, batches, several sites or several departments are involved. These are the areas where a bad cut-over costs money rather than just time.
3Which ERP modules should you go live with first?
If you are asking which ERP modules to implement first, start with master data and finance. Then move to purchasing, inventory and sales. Payroll or production comes last. This is common practice, and this module-order roadmap follows a similar logic.
The reason is dependency. Everything else uses your items, customers, suppliers and chart of accounts. If those are messy, every later module inherits the mess. Finance also gives you a fixed point to check against: your old ledger.
Sector variations are common:
- Pharmacy: batch and expiry stock comes early, because it is a compliance and waste issue, not a nice-to-have. See our guide to FEFO batch and expiry tracking.
- Factory: costing follows stock. You cannot cost a product until quantities and purchase prices are trustworthy. Our guide to product costing for factories explains why.
- Gym: memberships and recurring billing first, then access control and reporting.
- Property developer: instalment schedules and receivables come right after finance, because they drive cash flow. See instalment plans and collections.
- HR team: attendance before payroll. If hours are wrong, pay will be wrong. Here is how attendance data flows into payroll.
4What does a phased ERP rollout for small business look like?
Here is the plan we would use as a starting point for the ERP implementation phases: a discovery step (Phase 0) followed by four go-live phases. The weeks are typical ranges for a 10 to 50 user business, not guarantees. Complexity, data quality and how quickly your team answers questions all move them.
| Phase | Modules | Typical weeks | Exit criteria | Staff involved |
|---|---|---|---|---|
| 0. Discovery and demo | Process mapping, working demo on your data | 2–4 | Scope signed off; demo walked through by the people who will use it | Owner, finance lead, one lead per department |
| 1. Finance and master data | Chart of accounts, customers, suppliers, items, bank, opening balances | 4–8 | Balances agree to old ledger; one month reconciled | Finance, owner, one data owner |
| 2. Purchasing, stock and sales | Purchase orders, goods received, inventory, quotes, invoices | 6–10 | Stock count within tolerance; staff complete daily tasks unaided | Operations, warehouse, sales, finance |
| 3. Payroll or production | Attendance and payroll, or production orders and costing | 6–10 | Parallel run matches; costing reviewed by finance | HR or production lead, finance |
| 4. Reporting and clean-up | Management reports, approvals, retire old tools | 3–4, then ongoing | Old system closed; reports used in monthly review | Owner, managers |
Added together that is 21 to 36 weeks of work. Once you add two to four weeks of hypercare between phases, expect roughly five to nine months from first workshop to switching off the old tools.
What stays on the old system at each stage:
- After Phase 1: stock, sales entry and payroll stay where they are. Finance gets summarised postings from them.
- After Phase 2: only payroll (or production) remains on the old system.
- After Phase 3: nothing operational. The old system is read-only for reference.
- Phase 4: spreadsheets that crept back in get removed, not tolerated.
Phase 0 matters more than it looks. A working demo before Phase 1 means people have clicked through their own tasks before anyone is committed.
5How do you decide when a phase is ready to go live?
Use measurable gates, not a feeling. Treat the table below as your ERP go-live checklist. Each gate is a number or a yes/no, with a named person who signs it off.
| Gate | Test | Signs off |
|---|---|---|
| Opening balances | Trial balance in the new system agrees to the old ledger, line by line | Finance lead |
| Bank reconciliation | A full month reconciles in the new system and matches the old one | Finance lead |
| Stock accuracy | Sample count is within the tolerance you agreed in advance | Operations manager |
| Payroll parallel run | New system matches the old payroll exactly, to the smallest currency unit, for a full cycle | HR lead and finance |
| Daily tasks | Each user completes their usual tasks unaided, with no help from the vendor | Department lead |
| Backups | A backup is restored into a test environment and the data checks out | Technical owner |
Agree the stock tolerance before the count, not after. Set afterwards, it will be whatever you happened to get.
Two more points on sign-off. The person who prepares payroll should not be the person who approves it, in the old system or the new one. Our guide to payroll approval controls explains why. If payroll is part of your build, our HR software development work treats that split as a basic control.
Also check local payroll and tax rules with your accountant before any payroll cut-over. Depending on where you operate, that means your tax authority: HMRC in the UK, the IRS in the US, the ATO in Australia, IRAS in Singapore, or the relevant body in the UAE. Mid-period switches can affect year-to-date figures and filings.
A no-go is a normal outcome. It means a gate failed and you fix it before going live. That is the point of having gates.
6How do old and new systems run together?
Keep the rules simple, because bridges are where phased projects get messy.
- One source of truth per data type at any moment. Customers live in one system, not both. Decide which, and write it down.
- Avoid two-way sync. It creates conflicts nobody can resolve. Use a scheduled one-way import instead, such as the old stock system feeding a nightly summary into finance.
- Keep the bridge list short. If you have more than three or four, the phasing is too fine.
- Retire each bridge on a set date. A bridge with no end date becomes permanent.
Data migration per phase follows the same discipline:
- Migrate only what the phase needs. Do not load three years of stock movements to go live on finance.
- Clean before you move. Merge duplicate customers, fix item codes and agree units of measure first.
- Set a freeze date after which nobody edits the old data for that module.
- Do a final delta load for anything entered between the test migration and go-live.
Parallel running should be short and bounded. For finance, run one full month-end in both systems. For payroll, run one full pay cycle. Longer than that and staff do double entry, stop trusting both systems and drift back to the old one.
7When is the best time of year to go live?
Avoid the busiest and most fragile times, and give each phase room to settle.
- Start finance at the beginning of an accounting period, ideally a month or quarter start. Opening balances are then clean and there is no split-period reporting.
- Avoid year-end, stocktake and peak trading season. Staff attention is already spoken for.
- Never put payroll go-live in the same week as a finance cut-over. If numbers look wrong, you will not know which change caused it.
- Leave two to four weeks between phases for hypercare and fixes before the next change.
Here is a purely illustrative calendar for a business with a 31 December year-end and a busy November and December:
| When | What |
|---|---|
| January–February | Phase 0: demo and scope |
| 1 April | Phase 1: finance and master data go live (quarter start) |
| Early May | First month-end closed in the new system |
| 1 June | Phase 2: purchasing, stock and sales (after a stock check, not during stocktake) |
| 1 September | Phase 3: payroll, at the start of a pay period and quarter |
| November–December | Peak trading and year-end: no changes, only fixes |
| February–March | Phase 4: reporting, clean-up, old tools retired |
Your calendar will differ, especially if your tax year or trading peak falls elsewhere. The principle does not change: nothing major lands in the busiest weeks.
8What if a phase fails? Rollback and hypercare
This is the main reason to phase. A small phase is cheap to roll back. A failed big bang is not.
Rollback plan, agreed before each go-live:
- Keep the old system running read-only for a set period, such as one month-end for finance or one pay cycle for payroll.
- Decide the rollback point in advance: what failure triggers it, and by when. Rolling back after two weeks of new data is far harder than after two days.
- Record what you would need to re-enter if you rolled back, and who would do it.
- Take a full backup of the old system on the freeze date.
Hypercare is the period straight after go-live when you expect problems and staff the response:
- Two to four weeks of short daily check-ins, ten minutes at most.
- A named person who owns fixes, so problems do not float between you and the supplier.
- A short list of known issues, each with an owner and a date, visible to everyone.
- No new features until the list is under control.
If hypercare shows the phase has failed, a pause is cheaper than pushing on. Fix it, re-run the gates and set a new date.
9How do you stop staff resisting the change?
Most resistance is practical, not stubborn. People worry the new system will make their day slower. Address that directly.
- Pick a champion per team. Someone respected, not necessarily senior, who tries things first and tells the others honestly.
- Train on real tasks in the demo system. Raising an actual purchase order beats a slide deck.
- Train just before each go-live, not months earlier. People forget what they cannot use.
- Make the first phase quick and visible. If finance gets month-end faster, people notice.
- Fix the first complaints within days. Fast fixes build trust. Silence kills it.
Change fatigue is the downside of phasing, so keep the gaps between phases real. Give people a few quiet weeks.
10How much does a phased ERP implementation cost?
In our experience it costs somewhat more in total, because of bridges and repeated cut-overs, but it limits the cost of a failure. Published figures for ERP implementation cost for small business projects vary widely. They are vendor and reseller estimates, not quotes, and they mostly describe packaged ERP projects.
| Figure | Source (2026) |
|---|---|
| About $20,000 for a small deployment; $20,000 to $200,000 for 10 to 50 users | Godlan, citing ERP Software Blog |
| $80,000 to $300,000 all-in for SAP Business One or Dynamics SMB projects; SAP typically 4 to 8 months under 150 staff | Granuler |
| Implementation costs 2 to 3 times first-year software cost | Granuler |
| Implementation and consulting 30 to 45% of budget; licensing 25 to 40% | Godlan |
Treat these as ranges. Scope, data quality, number of sites and whether you build or buy all move the answer. A custom build has no licence line, so its split looks different. Our guide to ERP development cost covers that side in detail.
Below is an illustration, not Treevoxa pricing, of how a $100,000 project budget might split across the phases. The 7% bridge allowance is an assumption. It is not a benchmark, so adjust it to how many bridges you actually need.
| Item | Share | Amount |
|---|---|---|
| Phase 0: discovery and demo | 8% | $8,000 |
| Phase 1: finance and master data | 25% | $25,000 |
| Phase 2: purchasing, stock, sales | 30% | $30,000 |
| Phase 3: payroll or production | 22% | $22,000 |
| Phase 4: reporting and clean-up | 5% | $5,000 |
| Bridges between old and new | 7% | $7,000 |
| Contingency | 3% | $3,000 |
Phasing lets you pay as you go and see results before committing the next tranche. To price your own scope, try the software cost calculator or check our software development rates.
11Why does a custom ERP suit a phased rollout?
You can build and release one module at a time, and shape each phase around your own processes. With custom ERP software development, Phase 1 can be finance and master data, built the way your accountant needs it. Phase 2 is not released until Phase 1 has passed its gates.
You also see a working demo before committing. That lowers the risk of Phase 1, because you have already tested the idea on your own data.
If you want to see what a business-specific ERP looks like, Treevoxa's Batchbook manufacturing ERP and RE-ERP for property developers are examples for factories and property developers. Ask how the modules you need would be released in stages. If you cover costing, accounting and costing software development is where the costing phase is scoped.
There is a trade-off. A packaged ERP may be quicker and cheaper if your needs are standard and you are happy to adapt your processes to it. Our comparison of custom ERP vs Odoo vs ERPNext sets out where each one wins, and custom software vs SaaS covers the wider choice.
12A worked example: a 30-person factory in three phases
This is a composite illustration, not a named client. It shows how gates catch problems while they are still small.
The factory went live in three stages, which map to Phases 1, 2 and 3 of the plan above. It skipped a formal Phase 0 because the owner had already seen a demo, and it left Phase 4 (reporting and clean-up) for the following quarter. Each stage took about two months.
| Month | Stage (plan phase) | Gates checked | What went wrong and how it was fixed |
|---|---|---|---|
| 1–2 | Finance and master data (Phase 1) | Trial balance matched; one month of bank reconciled | A supplier credit note was missing from the old ledger. Found at reconciliation, added before go-live. |
| 3–4 | Purchasing, stock and sales (Phase 2) | Sample stock count within agreed tolerance; staff raised orders unaided | Some raw materials were held in kilograms in one list and grams in another. Units standardised, count repeated and passed. |
| 5–6 | Costing and production (Phase 3) | Costing reviewed by finance against a sample of recent jobs | Early cost figures looked high because old purchase layers were loaded incorrectly. Reloaded and re-checked. |
Each fault was cheap to fix because it showed up in one stage with a limited amount of data. In a single-date cut-over, all three would have landed together.
The costing stage depends on stock quantities and purchase prices being right first, which is why it came last. The Batchbook manufacturing ERP is built around that stock-to-cost order.
13How many phases does a small business need?
For most businesses of 10 to 50 staff, a phased ERP rollout for small business works best as a discovery step followed by two to four go-live phases: finance and master data, then purchasing, stock and sales, then payroll or production, with reporting and clean-up last. Simple, single-site firms can use fewer. More than four go-live phases usually means too many bridges and too much change fatigue.