The five stages
These are not phases in a methodology. They are the five distinct questions a company has to answer, in the only order in which the answers are cheap.
| Stage | The question | Done when | Typical length |
|---|---|---|---|
| Evaluate | Does this fit how we work? | You can name what it will not do for you. | 1–2 weeks |
| Pilot | Does it survive one real workflow? | A small team ran a real week in it. | 2–4 weeks |
| Migrate | Can we get our history in? | A balance ties to the old system. | 2–6 weeks |
| Roll out | Will the rest of the company use it? | The old system is read-only. | 2–8 weeks |
| Operate | Does it stay correct? | A close ran without heroics. | Ongoing |
Prove the fit, and find the limits before you commit to them.
PilotAvailableOne team, one workflow, real data, a fixed end date.
MigrateAvailableStructure first, balances second, history last.
Roll outAvailableSequencing people and modules so the old system can actually be switched off.
OperateAvailableThe rhythms that keep a suite correct: close, review, audit, access.
The two orderings that cause most of the pain
Migrating before piloting. Historic data loaded into a structure nobody has tested has to be loaded twice. The second load is worse than the first, because now there is live data to preserve alongside it.
Rolling out before migrating. A team asked to work in a system that has none of last year in it will keep the old system open "just to check", and a company running two systems in parallel is running neither. Parallel running has a place — one close, maybe two — and it is a scheduled overlap with an end date, not a habit.
A young company, or one moving only a single function across, often has nothing to migrate. That is a real and good position to be in. Skip straight from Pilot to Roll out; do not invent a migration to feel thorough.
In this section
What to actually test while evaluating erp.io, which questions separate a good fit from a bad one, and where the product is deliberately not competitive.
PilotAvailableHow to run a pilot on erp.io that produces a real decision: one team, one workflow, real data, a fixed end date, and a written verdict.
MigrateAvailableThe order that makes a migration survivable: structure first, opening balances second, transactional history last — and the checks that prove it worked.
Roll outAvailableSequencing people and modules so the old system can actually be switched off — and the checks that tell you it is safe to do it.
OperateAvailableThe rhythms that keep a live erp.io workspace correct: the monthly close, access review, audit log review, AI spend, and what to check quarterly.