When a company asks me about ERP implementation phases, I first want to understand how it expects to reach the launch. Does it need a solution built against detailed requirements before users accept it? Can users test complete business processes as the team develops them? Or is it ready to start with standard functionality and adapt its way of working?
These lead to three approaches: a classical sequential implementation, iterative development with a single production launch, and a standard-first implementation followed by improvements. I recommend choosing according to the company’s operational risks, flexibility, and readiness to change.
Data migration, training, and documentation belong in all three. What changes is the sequence, when users provide feedback, and how much adaptation happens before or after go-live.
Three ways to organize the project
| Approach | Main phases | User feedback | Suitable when |
|---|---|---|---|
| Classical sequential implementation | Requirements → platform selection → configuration and development → trial operation → corrections → production launch | Primarily during acceptance, supported by earlier reviews | Critical processes need explicit requirements and controlled acceptance |
| Iterative development, one production launch | Initial scope → complete process iterations → combined readiness testing → production launch | During each iteration | The company can refine requirements through feedback but cannot switch operations process by process |
| Standard-first implementation | Confirm essential fit → prepare data and users → launch standard functionality → adapt and improve | During preparation and supported daily operation | The company accepts standard processes and has few essential gaps |
Developing a system in parts and launching it in parts are different decisions. An iterative project can still have one production launch.
ERP implementation phases: results, owners, and decision gates
An implementation approach describes how we organize delivery. A phase describes the work and the result we need before making the next decision. The same essential work appears in all three approaches, but it does not have to happen as one uninterrupted sequence.
I would use the following roadmap as a starting point, then agree on the actual deliverables and acceptance criteria with the client. These are recommended project controls, not a claim that every ERP project follows an identical methodology.
| Phase | Required result | Who owns the work and acceptance | Criterion for moving forward |
|---|---|---|---|
| Discovery and requirements | Agreed business objectives, process scope, essential requirements, constraints, and initial risks | Business analyst or functional consultant coordinates; business process owners approve requirements; sponsor resolves priorities | Critical processes have named owners, essential needs are explicit, and the business agrees what the project must achieve |
| Platform selection and solution planning | Platform-fit assessment, identified gaps, delivery approach, initial scope, dependencies, and acceptance plan | Solution lead assesses fit; process owners validate business scenarios; sponsor approves the choice and scope | Essential needs have a credible solution; unresolved gaps have agreed actions; the business accepts the proposed approach |
| Configuration, development, and integrations | Configured workflows and agreed extensions, with technical checks and updated delivery documentation | Implementation team delivers; solution lead coordinates dependencies; process owners review workflows | The agreed scope for user testing is demonstrable end to end; unresolved limitations are recorded and understood |
| Data migration preparation and rehearsal | Data mapping, cleaned source data, a trial migration, and reconciliation results | Migration lead runs the transfer; business data owners verify completeness and accuracy | Agreed checks pass; discrepancies affecting essential operations are resolved; final migration responsibilities are assigned |
| User acceptance testing and training | Completed business test scenarios, a findings register, user guidance, and trained key users | Business process owners accept workflows; key users execute tests; implementation team resolves defects and provides training | Critical scenarios pass; launch-blocking defects are closed; accepted remaining issues have owners and workarounds where needed |
| Cutover planning and go/no-go | Final migration schedule, system-switching tasks, communications, support coverage, and a contingency plan | Project manager coordinates; technical and business leads confirm readiness; sponsor or delegated business decision-maker authorizes launch | Named owners confirm readiness; the launch window and contingency decision points are agreed; no unresolved blocker prevents essential operations |
| Go-live and hypercare | Production operation, reconciled final data, close support, and an actively managed issue register | Operations owns daily work; implementation and support teams resolve issues; project manager coordinates escalation | Essential operations run reliably over an agreed observation period; critical launch issues are resolved; remaining work has an agreed route |
| Handover and ongoing improvement | Accepted operating documentation, support responsibilities, known issues, and a prioritized improvement backlog | Support lead accepts handover; process owners prioritize improvements; sponsor or delegate approves project closure | Support can operate without relying on the project team for routine tasks; the business accepts ownership and the remaining commitments |
Several rows overlap. Migration preparation should begin while workflows are being designed, and training should use processes that users will actually follow. The table separates responsibilities and decisions; it should not be read as permission to leave data or training until the end.
A decision gate is an explicit check that the next step is justified. It should identify who can approve progress, what evidence they need, and what would stop the transition. “Development complete” is too vague if nobody has demonstrated the business process or checked the data it depends on.
How the roadmap changes with the approach
In a classical project, requirements and solution planning establish the main baseline before delivery. Formal user acceptance follows the main build, and corrections must satisfy the agreed launch criteria. Earlier demonstrations can still expose misunderstandings before they become expensive acceptance disputes.
In an iterative project, solution planning, delivery, and user feedback repeat for successive process increments. An iteration needs its own definition of completion: what users can do, which tests pass, and which limitations remain. A completed iteration does not authorize production use. The combined system still goes through acceptance, migration rehearsal, and one coordinated go/no-go decision before the single launch.
In a standard-first project, the team validates essential fit against standard workflows and keeps pre-launch changes limited. Migration, training, acceptance, and cutover remain necessary. More process adaptation and optional improvements happen after launch, but a critical operational gap cannot simply be moved into the improvement backlog to make the launch date look achievable.
Before migration rehearsal, business owners should validate the master data that transactions depend on, including the relevant customer, supplier, and product records.
What determines the timeline and budget?
I would estimate the work after examining process scope, integrations, data quality, and the people available to make and accept decisions. A large development team cannot compensate for an unanswered business question or missing source data.
In a classical project, a requirements baseline makes it easier to assign work to stages and track scope changes. If new requirements emerge during acceptance, the project still needs an explicit decision about cost and timing.
In an iterative project, the team can plan the next increments in detail while revisiting the overall forecast as it learns. I would protect a defined minimum launch scope and distinguish new discoveries from optional improvements. Otherwise, a useful feedback process can become an indefinitely expanding project.
In a standard-first project, fewer pre-launch customizations can reduce the work needed before production use. The business still needs to budget for migration, training, support, and adaptation after launch. An earlier go-live changes when work happens; it does not make that work free.
For any approach, I would make the main dependencies visible: when source data will be ready, when integrations can be tested, when users can participate, and who can approve a decision. Those dependencies often explain a timeline more usefully than a generic promise about how many months ERP implementation takes.
1. Classical implementation: define, build, accept, launch
The classical approach starts with business requirements. The company describes the problems it wants to solve, the modules it needs, and the essential functionality it expects the ERP to provide out of the box.
These requirements become the basis for selecting a platform. For an Odoo project, consulting and fit-gap analysis can help clarify that decision. Here, the important point is that delivery starts with both an agreed requirements baseline and a selected platform.
Requirements and platform selection
Business representatives explain how their processes work and what the new system must support. A list of modules is only a starting point: purchasing, inventory, and accounting must work together in the way the business needs.
Before delivery, I would agree on the scope, the critical requirements, and the criteria for accepting the result. Otherwise, acceptance can become an argument about what each side originally meant.
Configuration, development, and integrations
The team prepares the ERP against those requirements. This can include configuration and customization, integrations, new business documents, additional forms, and development for functionality the platform does not provide as standard.
Depending on scope, this work can take several months. Its output is a system ready for the business to evaluate. Completing development does not yet mean the company is ready to run its operations on it.
Trial operation and acceptance
Users need time to work through their tasks. They test the system and produce a register of findings.
I would distinguish defects from missing or changed requirements. A function that fails an agreed requirement needs correction. A newly discovered need requires a scope decision. Mixing the two makes costs and responsibility harder to control.
Corrections and production launch
The team resolves the findings and prepares the final migration, training, documentation, and transition into production. The business then decides whether the system is ready to become its operational tool.
Go-live should be followed by close support, often called hypercare. I would agree who handles urgent issues and what must be stable before the company moves into routine support.
When I would choose it
I favor this approach when the client is complex and disrupting established processes would create serious operational risk. It provides clear stages, visible handovers, and a baseline for managing budget and scope.
Its main weakness is the distance between defining requirements and accepting the system. A company can receive software that closely matches what it wrote down and still find that it does not match what people expected.
That is why realistic process reviews remain useful during delivery. A sequential plan does not make incomplete requirements disappear or guarantee an unchanged budget.
My experience: the requirements stayed still while the business changed
I was involved in selecting an ERP for a fast-moving consumer goods (FMCG) holding company. Gathering requirements took approximately six months. Every department contributed, the requests were consolidated, and we ended up with a substantial requirements document.
We then selected the ERP that appeared to cover more of those requirements than the other candidates. After the contract was signed, the supplier prepared its own technical requirements document for approval and began adapting the system.
Around eight to ten months later, the supplier delivered the system with a list of the changes it had implemented. During that period, however, the business had moved on. Product management and purchasing processes had changed, and reporting had become more structured.
The delivered ERP matched the documented requirements much more closely than it matched the company’s current expectations. The company now faced additional spending to change a product that had just been built for an earlier version of its business.
My lesson from that project is that approving requirements does not freeze the organization. In a long sequential project, I would revisit important business assumptions during delivery and assess the effect of changes explicitly. Otherwise, the acceptance discussion can prove that the supplier built what was agreed without establishing that the business received what it now needs.
2. Iterative implementation: develop complete processes, launch once
The second approach develops the ERP through smaller iterations. Scrum can be used to organize this work, although iterative delivery does not automatically mean a team is following Scrum.
The principle I find useful is to build a complete business process, let users try it, and use their feedback to decide what comes next.
Build a workable end-to-end process
As an illustrative scenario, I would take purchasing, receiving goods into a warehouse, allocating applicable additional costs (landed costs) to the stock, and storing it. Users should be able to follow goods from the supplier into their own inventory and see the resulting quantity and inventory valuation in the system.
This brings several departments into one demonstration. Purchasing can check the order, warehouse staff can check receipt and storage, and finance can check how the cost is represented. They are reviewing one connected flow rather than separate screens.
Another useful scenario is a customer sale followed by warehouse dispatch and revenue recording under the agreed accounting workflow. The business can examine the documents, approvals, and dependencies needed to complete the transaction. These are examples of what I would demonstrate, not accounts of a particular client’s iteration or a claim that every ERP handles each step identically.
The aim is to make the flow understandable and testable. Some unusual cases, specialized reports, and additional conveniences can follow later. Critical controls and dependencies still need to be identified; a simplified demonstration must not conceal a gap that would prevent launch.
Test, refine, and extend
Users can now react to something concrete. They see what works, what is confusing, and which requirements they had not considered.
The next iteration improves that process or introduces another. Over time, the team builds a connected solution while users become familiar with it. People do not have to imagine every detail before they have seen the software in use.
Prepare the combined system for one launch
In the version I am describing, the company does not move live operations into every completed iteration. It develops and tests in parts, then launches the ERP as a whole.
Before launch, the team must check that the processes work together. Separate demonstrations are not enough. Data, integrations, user responsibilities, and the transition from the old system must also be ready.
The result is a functioning system and users who have participated in shaping and testing it. Post-launch support and hypercare follow the shared production launch.
When I would choose it
I recommend this approach for a flexible company that can make decisions and provide feedback throughout development, but cannot move into the ERP one process at a time.
Its strength is learning before launch. Its difficulty is forecasting: when the team discovers and revises work as it goes, a detailed final budget and schedule are harder to maintain.
Planning still matters. I would define the essential launch scope, identify dependencies, and regularly review the work remaining. The team needs a clear boundary between what is necessary for go-live and what can follow later.
3. Standard-first implementation: start working, then improve
The third approach starts from a different position. The company is willing to adopt the ERP’s standard processes rather than first asking the team to reproduce its existing way of working.
This can suit a business with few non-negotiable requirements that is ready to learn how the product expects work to be done.
Confirm essential fit
First, I would distinguish preferences from genuine requirements. A familiar screen layout may be negotiable. A process needed to ship orders, keep accurate records, or meet an obligation may not be.
Standard-first works when the standard solution supports essential operations. It should not postpone a gap that would prevent the company from working.
Prepare data and users
Migration becomes an early practical focus because users need their information in the new system. The team prepares and checks the data, configures the standard solution, trains users, and documents the workflows.
Preparation may be smaller than in a heavily customized project, but it still requires a clear decision about readiness to launch.
Launch, support adaptation, and prioritize improvements
The company starts working in the system and records what does not suit it. Support and learning become central parts of implementation.
Some original requests may disappear. A process may work differently in the new ERP, making an old requirement unnecessary. Users may discover that a standard workflow solves the underlying problem without reproducing every familiar step.
Other gaps remain real. Those become candidates for later configuration, development, or integration work.
Requirements that changed after users tried the system
One small but revealing example from my experience is terminology. A client insisted that customer records should be called “leads,” because that was the term its team preferred. After roughly a month of using the system, the naming request stopped being an issue. The team had become familiar with the system’s vocabulary. That does not mean leads and customers are interchangeable concepts; it shows why a preference for familiar labels should be examined before commissioning a change.
Document terminology can create a similar discussion. A team may say, “We want to send an invoice immediately and wait for payment,” when the system’s workflow uses a quotation or pro forma document at that point. The useful question is what business event the document represents and when the formal invoice should be created. I would explain and test that sequence before changing it. The appropriate accounting and tax treatment still needs to be checked for the company’s jurisdiction and configuration.
I have also seen finance teams request automatic posting of all invoices, then reconsider after about a month of practical experience. Accountants needed to review errors, analytic accounting allocations, and counterparty details. In those cases, retaining accountant review proved more appropriate than the original request for blanket automation.
I would not turn that experience into a rule against automation. It is a reason to establish which checks must happen, who is accountable for them, and which transactions can safely proceed automatically. Trying the workflow can reveal a more useful requirement than the one the team initially proposed.
When I would choose it
I recommend this option when the company is ready to adapt and trusts the ERP’s standard processes enough to give them a fair trial. It can provide a working foundation earlier, with improvements following actual use.
I would be cautious if management expects adaptation without giving employees time, training, or authority to change their routines. Critical requirements must also be resolved before launch.
Starting production earlier does not mean the whole implementation is finished. It moves more learning and improvement into the period after go-live.
How I choose between the approaches
My first question is what the company cannot afford to disrupt. My second is how much it is willing to change.
If established processes are complex and operational risk is high, I lean toward a classical project with explicit requirements and acceptance stages. If the company is flexible, can participate throughout delivery, and needs one coordinated launch, I favor iterative development. If standard functionality is sufficient and the team is ready to adopt it, I consider standard-first implementation.
Company size alone does not settle the choice. Process constraints, data readiness, integrations, and the availability of decision-makers matter more to this assessment.
Before recommending an approach, I would ask five concrete questions:
- Which processes must remain unchanged for operational or compliance reasons, and which can adapt to standard ERP workflows?
- Can process owners and key users participate regularly in demonstrations, testing, and scope decisions?
- Can the business operate with standard functionality at launch, or do essential integrations and extensions have to be ready first?
- Is the source data usable, and who is responsible for correcting and approving it?
- Can operations switch gradually, or do connected processes require one coordinated production launch?
The answers should influence the delivery plan. A willingness to experiment favors iterative feedback, but it does not by itself make a company ready for a standard-first production launch.
Whichever approach we choose, I would assign responsibilities clearly: business process owners approve how work should run; the implementation team delivers the agreed solution; the project lead manages scope and open decisions; and a named business decision-maker authorizes go-live.
I would also agree on what ends hypercare. Users need to perform essential tasks, important data and integrations need to work reliably, and unresolved issues need accountable owners and a support route. Making software available is only one part of completing an implementation.
Small omissions that can block go-live
In my experience, launch blockers can look deceptively ordinary: missing historical data, an approval step that was not accounted for, no workable way to cancel or reverse an operation, or an unresolved need to enter a transaction with an earlier date.
These questions often concern historical data and how the business must use it after migration. Importing records is not enough if users cannot complete the operations that depend on them.
Before authorizing launch, I would ask process owners to demonstrate the necessary historical-data scenarios and relevant exceptions. The team should agree which operations must be supported, what the system permits, and what controls apply. A need to correct a past transaction should not be interpreted as permission to bypass accounting controls or closed-period restrictions.
Where an essential scenario cannot be completed and there is no acceptable alternative, I would treat it as a go/no-go issue.
For the Odoo-specific methodology context, see our review of the official Odoo implementation guide. The comparison here addresses the broader buyer-side choice of ERP delivery approach.
Discuss the approach before committing to the project
At ERPixel, we recommend the approach that fits the client’s constraints and readiness to change. We do not need every implementation to follow the same sequence.
If you are considering Odoo, our consulting services can help clarify requirements and the roadmap. Our implementation services support the move into practical use, with migration and integration work where the project requires them.
Talk to us about your project. We can start with the processes you need to protect, the changes your team is ready to make, and the launch you need to achieve.