Odoo ERP implementation: from a manufacturer's processes to a working system
We implement Odoo for manufacturing companies that want to connect sales, purchasing, inventory and production. We design how the team will work in the system, configure the applications, move the data across and build the integrations that order fulfilment depends on.
Before work starts, we agree what has to work in the first stage, who makes the decisions and how we will know the system is ready to go live. Your team takes part in testing on its own products and working scenarios.
- Process analysis
- ERP configuration
- Data migration
- Integrations
- Testing and training
The company takes orders, but fulfilling them takes more and more manual work
The sales rep records the agreement in the quote, the planner schedules production in a spreadsheet and the warehouse keeps its own records. While orders are few, the team can piece this information together. With every new product variant, sales channel and change of date, the discrepancies multiply.
An Odoo implementation puts order into how work passes between departments: the data needed to complete an order, the moment it is approved and who is responsible for what happens next.
A first ERP covering several departments
The company uses invoicing software, production spreadsheets and separate order lists. It needs shared records, clear statuses and rules for handling an order from receipt to dispatch.
Replacing the current system
The ERP does not support the production or sales model the company needs, and every change requires a workaround. Before migrating, you have to decide which functions to rebuild, which to simplify and what data to move.
Launching another sales channel
Orders from the store, the B2B platform and sales reps land in different places. A new channel needs agreed product availability and order handling that draws on the same warehouse or production plan.
Bringing production into the system
Sales and the warehouse already have their tools, but materials, operations and output are accounted for outside them. The project has to link the product structure with demand and with recording work on the shop floor.
Before configuration, we agree how the company will work in Odoo
A list of applications is not enough to price an implementation. You need to know what triggers a material purchase, when an order can still be changed and who confirms that a product is ready to ship.
We run the analysis on examples from your company: selected products, documents and orders. Besides the typical flow, we go through the situations that need an employee's decision or a departure from the standard path.
- 01
Sales and fulfilment model
Do you make to stock, to order or a mix of both? When do you confirm a date to the customer? What happens when a variant or quantity changes after the order is accepted? The answers define the dependencies between sales, stock and production.
- 02
Product and material structure
We review item codes, variants, units, semi-finished goods and bills of materials (BOM). We decide which information describes the product and which is a parameter of a specific order. That split shapes the configuration and the data migration later on.
- 03
Production flow and inventory management
We describe operations, work centres, storage locations and the points at which consumption is recorded. We agree how to handle partial completion, shortages, rework and work given to subcontractors, if your plant uses them.
- 04
Systems and data ownership
We set out what Odoo takes over, what stays in e‑commerce, the PIM, the WMS or accounting, and how data should move between these tools. For information used in several places, we agree the master source.
- 05
Initial scope and acceptance criteria
We choose the processes needed for the first go-live. We define the expected test results, who signs off each area and the data requirements. Other changes get a place in the development plan.
What do you get after the analysis?
- a description of the target processes and responsibilities
- a list of requirements split into standard, configuration, extensions and integrations
- the migration scope and a list of data that needs preparing
- a stage plan and acceptance criteria
- a quote and a schedule with tasks on both sides
Already have an analysis or a specification? We check that it is current and complete, then use it to prepare the scope.
Let's start with an implementation analysisWhat does an Odoo implementation cover?
The scope covers preparing the system for the agreed way of working. Which applications you need depends on your processes, the Odoo edition and what the chosen environment allows. The proposal states which elements belong to the first go-live.
Important: Odoo comes in Community and Enterprise editions. Not all Odoo features, applications and services are available in both. Before we close the scope, we confirm which requirements the chosen edition covers, which need Odoo Enterprise and which need an additional module or a custom extension.
Sales and order handling
We configure the CRM, quoting and order scope you need. We clean up customer data, commercial terms and the information passed on for fulfilment. We agree the rules for discounts, order changes and date confirmations.
Purchasing and inventory
We set up the warehouse and location structure, receipt and delivery documents and the agreed replenishment rules. We check the purchase, storage and consumption units, so that a bulk pack bought in is converted correctly for production.
Manufacturing and execution
We configure BOMs, operations and work centres to the agreed extent. We define how the quantity produced, material consumption and operation time are recorded. We test partial completion and the hand-over of finished goods to the warehouse.
Roles, permissions and approvals
We agree who creates and changes data, approves orders and corrects documents. We configure user access to the areas each person needs. If the approval flow you need goes beyond the standard, we describe it as a separate extension.
Integrations with your systems
We build the connections the chosen scope needs at go-live. Each one has defined data, a direction of exchange and an update moment. We cover recognising an order that is sent again and handling a failed synchronisation.
Data, documents and reports
We prepare the mapping and import of the agreed data, document templates and the views and reports you need. For every report we agree the definitions and data sources.
The scope of finance and accounting features depends on the Odoo edition, the installed applications and the localisation, so we agree it with your accountants even when finance stays in another system.
Testing, training and go-live
We verify the processes with users, run role-based training and prepare instructions for everyday tasks. Before go-live we sign off the test results, how the final data will be moved and the support plan for the first days of work.
Sales and order handling
We configure the CRM, quoting and order scope you need. We clean up customer data, commercial terms and the information passed on for fulfilment. We agree the rules for discounts, order changes and date confirmations.
Purchasing and inventory
We set up the warehouse and location structure, receipt and delivery documents and the agreed replenishment rules. We check the purchase, storage and consumption units, so that a bulk pack bought in is converted correctly for production.
Manufacturing and execution
We configure BOMs, operations and work centres to the agreed extent. We define how the quantity produced, material consumption and operation time are recorded. We test partial completion and the hand-over of finished goods to the warehouse.
Roles, permissions and approvals
We agree who creates and changes data, approves orders and corrects documents. We configure user access to the areas each person needs. If the approval flow you need goes beyond the standard, we describe it as a separate extension.
Integrations with your systems
We build the connections the chosen scope needs at go-live. Each one has defined data, a direction of exchange and an update moment. We cover recognising an order that is sent again and handling a failed synchronisation.
Data, documents and reports
We prepare the mapping and import of the agreed data, document templates and the views and reports you need. For every report we agree the definitions and data sources.
The scope of finance and accounting features depends on the Odoo edition, the installed applications and the localisation, so we agree it with your accountants even when finance stays in another system.
Testing, training and go-live
We verify the processes with users, run role-based training and prepare instructions for everyday tasks. Before go-live we sign off the test results, how the final data will be moved and the support plan for the first days of work.
Migrating to Odoo also covers work that is already in progress
Moving master data does not finish an ERP migration. On go-live day the company has stock, materials on order, work in progress and partly shipped orders. For each of them, you have to decide which system it will be finished in.
We check what the current tools can export and prepare the data for Odoo's structure. We run a trial import in a test environment. Only after checking the results do we prepare the final load.
| Data | What we agree before the move |
|---|---|
| Products, materials and semi-finished goods | Shared identifiers, variants, units, statuses and the relations between records. |
| BOMs and operations | Component quantities, units, links to variants and the completeness of the product structure. |
| Customers and suppliers | Duplicates, addresses, billing data and the commercial terms in force. |
| Stock | The position at cut-over, locations, lots or serial numbers if used, and the rules for reconciling quantities and values. |
| Open orders | What has already been produced, delivered or invoiced and what is left to handle. |
| Work in progress | Which orders finish in the old system and which move to Odoo, together with consumption and output so far. |
| Financial data | Balances, documents and settlement rules agreed with your accountants, if finance is part of the migration. |
| History | The data Odoo needs for operations and what stays in an accessible archive. |
Products, materials and semi-finished goods
What we agree before the move
Shared identifiers, variants, units, statuses and the relations between records.
BOMs and operations
What we agree before the move
Component quantities, units, links to variants and the completeness of the product structure.
Customers and suppliers
What we agree before the move
Duplicates, addresses, billing data and the commercial terms in force.
Stock
What we agree before the move
The position at cut-over, locations, lots or serial numbers if used, and the rules for reconciling quantities and values.
Open orders
What we agree before the move
What has already been produced, delivered or invoiced and what is left to handle.
Work in progress
What we agree before the move
Which orders finish in the old system and which move to Odoo, together with consumption and output so far.
Financial data
What we agree before the move
Balances, documents and settlement rules agreed with your accountants, if finance is part of the migration.
History
What we agree before the move
The data Odoo needs for operations and what stays in an accessible archive.
How do we check the migration result?
We compare record counts, the links between data and agreed control totals. Process owners review representative products and documents. We log discrepancies together with a decision on who fixes them and which ones need a fresh import.
The trial also tells us how long the final move will take. On that basis we plan the freeze on changes in the old system and the order in which work starts in Odoo.
How does an Odoo implementation run, step by step?
Every stage ends with a result you can check: an agreed scope, a working process or a confirmed test. The schedule also allows for data preparation and the availability of people on your side.
- 01
Discovery and analysis
We learn how you sell, produce and handle orders. We collect sample data and the requirements of the departments the project covers.
ResultA process map, implementation goals and a list of requirements.
- 02
Checking the Odoo fit
We test the key scenarios on selected products. We set the limits of the standard, the extensions needed, the edition and how the environment will be maintained.
ResultA confirmed solution direction, first-stage scope, quote and schedule.
- 03
Configuration and extensions
We configure applications, working rules, roles and documents. We build the agreed extensions. We present each part to the people responsible for the processes as it is ready.
ResultA test environment with processes ready for review.
- 04
Trial migration and integrations
We import the prepared data, check the result and switch on the flows needed between systems. We run connection trials so that they cannot trigger unplanned actions in the live business.
ResultA migration report and the results of data exchange tests.
- 05
Process testing with users
We test complete scenarios, from receiving an order to the agreed end of its handling. We log defects, make fixes and repeat the relevant tests.
ResultConfirmed acceptance criteria and a list of any limitations accepted before go-live.
- 06
Training and preparing the organisation
Users practise the tasks that belong to their roles. We agree working instructions, the people supporting each department and how problems are reported.
ResultA prepared team and a plan for moving to the new way of working.
- 07
Cut-over and go-live
We move the final data following the approved procedure, reconcile stock and switch on processes and integrations. We check the first documents and operations.
ResultThe Odoo scope live, with a confirmed opening position.
- 08
Stabilisation and hand-over to maintenance
We review the first working cycles, analyse tickets and put the list of next changes in order. We agree ongoing support in line with the scope of our cooperation.
ResultDocumentation handed over, support rules and a plan for further development.
We test readiness on your own orders and exceptions
A form that opens correctly does not prove that the process works. Before testing starts, we record the expected result, the input data and who signs it off. We choose cases that match how your plant actually works.
| Example scenario | What we check |
|---|---|
| An order needs production and a component is missing | Whether the shortage is visible and starts the agreed replenishment path or purchasing decision. |
| The customer changes the quantity after the order is accepted | Whether the change reaches the right people and is reflected in further demand according to the agreed rules. |
| Only part of a manufacturing order was completed | Whether the quantity produced, the consumption and the remaining part of the order are recorded correctly. |
| A product needs rework | Whether it goes to the agreed handling and is not treated as ready to ship. |
| The store sends the same order again | Whether the integration recognises the repeat and does not create a second order. |
| One order ships in two deliveries | Whether quantities, statuses and documents match what actually happened. |
An order needs production and a component is missing
What we check
Whether the shortage is visible and starts the agreed replenishment path or purchasing decision.
The customer changes the quantity after the order is accepted
What we check
Whether the change reaches the right people and is reflected in further demand according to the agreed rules.
Only part of a manufacturing order was completed
What we check
Whether the quantity produced, the consumption and the remaining part of the order are recorded correctly.
A product needs rework
What we check
Whether it goes to the agreed handling and is not treated as ready to ship.
The store sends the same order again
What we check
Whether the integration recognises the repeat and does not create a second order.
One order ships in two deliveries
What we check
Whether quantities, statuses and documents match what actually happened.
These are examples of acceptance criteria. How each is handled, including any extensions needed, is agreed during the analysis. Before go-live we fix the defects that block the agreed process, and the remaining tickets get a priority and a due date.
Who takes part in an Odoo implementation?
The project needs people who know the company's day-to-day work and can approve how it should run. At the start we agree the project owner on your side, the workshop participants and the time needed for decisions and testing.
| Area | Aurora Creation | Your team |
|---|---|---|
| Processes and scope | Running the analysis, proposing the solution and describing the dependencies. | Explaining the business rules, pointing out exceptions and approving the process. |
| Data | Mapping, transformation rules, import and a discrepancy report. | Supplying the data, deciding on duplicates and confirming it is correct for the business. |
| Configuration and integrations | Building the agreed features, connections and documentation. | Providing access and the cooperation of the vendors of systems that stay in the company. |
| Testing and acceptance | Test scenarios, technical testing, fixes and support for sign-offs. | Checking everyday tasks and process owners accepting the results. |
| Go-live | The cut-over plan, technical work and monitoring. | Confirming the opening data, user readiness and the go-live date. |
Processes and scope
Aurora Creation
Running the analysis, proposing the solution and describing the dependencies.
Your team
Explaining the business rules, pointing out exceptions and approving the process.
Data
Aurora Creation
Mapping, transformation rules, import and a discrepancy report.
Your team
Supplying the data, deciding on duplicates and confirming it is correct for the business.
Configuration and integrations
Aurora Creation
Building the agreed features, connections and documentation.
Your team
Providing access and the cooperation of the vendors of systems that stay in the company.
Testing and acceptance
Aurora Creation
Test scenarios, technical testing, fixes and support for sign-offs.
Your team
Checking everyday tasks and process owners accepting the results.
Go-live
Aurora Creation
The cut-over plan, technical work and monitoring.
Your team
Confirming the opening data, user readiness and the go-live date.
We bring sales, production, purchasing, the warehouse and accounting into the conversations, to the extent the project covers them. Not everyone attends every meeting, but every decision has a named owner.
We implement Odoo around the systems that stay in the company
Each integration gets its own scope and acceptance criteria. Building the connections can be part of the implementation project, and the proposal describes the exact scope.
See the scope of Odoo integrationsE‑commerce and product data
Magento 2 or Shopify can keep running the store, and Pimcore the product information and assets. In the project we define which data goes to Odoo, where the channels get prices and availability from and how order fulfilment status comes back.
Warehouse, shop floor and specialist tools
If the company uses a separate WMS, a shop-floor data collection system or engineering tools, we set the limits of their responsibility. We check the available interfaces, the operation confirmations required and what happens when the connection is down.
Accounting and documents in Poland
With your accountants we agree where invoices and corrections are issued, which system handles the Polish e-invoicing system KSeF and what data is needed for settlements and reporting. When finance is to run in Odoo, we verify the Polish localisation for the chosen version and edition and test the required document scenarios. We do not assume that every Odoo variant offers the same range of accounting and localisation features. If finance stays in the current software, we design the right exchange.
How much does an Odoo implementation cost and how long does it take?
The cost depends on the number of processes, the quality of the data and the changes needed beyond the standard. Buying access to the applications does not cover designing how the company works, the migration or onboarding the users.
We start by agreeing the scope of the analysis. Once the processes and key scenarios have been checked, we present a quote for the implementation and a schedule split into stages.
What do we include in the budget?
- Analysis and solution design
- Workshops, a fit check, the process description and acceptance criteria.
- Configuration and development
- Applications, roles, documents, reports and the agreed extensions.
- Migration and integrations
- Data preparation, trial moves and connections with the other systems.
- Testing and team preparation
- Sign-offs, training, instructions and go-live work.
- Running the system
- Costs that depend on the chosen edition and environment. Odoo Community does not need an Enterprise subscription, but it can still bring hosting, maintenance and add-on module costs. For Enterprise we also include the relevant Odoo subscription and, where it applies, the cost of Odoo.sh.
- Ongoing support
- An agreed scope of support, updates and maintenance of extensions and integrations.
The proposal separates implementation work from recurring fees and states what each one covers. When the scope changes, we describe the effect on budget and timing before any extra work starts.
What affects the timeline most?
How complete the BOMs and master data are, the number of integrations, how available users are for testing and how the switch from the current ERP is made. The schedule also allows for the production calendar, stocktaking and periods when the company cannot cut over.
We can plan a staged go-live, for example for a selected product group or one plant. The condition is agreeing how it will work with the parts of the process that are still in the existing tools.
Do you need a new implementation or work on an existing Odoo?
The service depends on where your company is today. Choose the situation closest to yours.
FAQ: Odoo implementation
Answers to the questions we hear most often before a decision to implement Odoo.
Let's discuss an Odoo implementationYes. The analysis checks how well Odoo fits, defines the scope and estimates the work before you decide to implement. It delivers the requirements, the proposed approach and the questions still to be settled. We agree the scope of the documentation at the start.
Yes. We choose a stage that can go live and be tested in everyday work. It can cover selected processes, a product group or one location. Before go-live we agree the records and the data exchange between the new scope and the part that stays in the current system.
We review each one against today's business need. Some can be replaced by standard Odoo or a simpler way of organising the process. We build extensions where they are justified, allowing for their testing and later upgrades.
We set the scope after checking the exports and how available the data is. It can include master data, product structures, stock and open documents. Moving history and work in progress needs separate agreement. A trial import shows the quality of the sources and the transformations needed.
Configuration, trial migrations and testing take place in a separate environment. The cut-over itself may require limiting operations or freezing changes while the final data is moved. We set the length and conditions of that window after the trials, taking the plant's work into account.
Before go-live we split them into cases finished in the old system and cases moved to Odoo. For those that move, we establish the quantities already produced, the materials consumed, the deliveries and the remaining scope. Every case must have one clearly defined place where it continues.
Yes, for the users in the agreed scope. Training covers specific tasks: receiving an order, buying material, recording output or shipping goods. The team practises them in the prepared environment and receives instructions and rules for reporting problems.
It is not a condition of an Odoo implementation. We check which systems should stay and which connections are needed. If accounting runs outside Odoo, we agree the handling of invoices, corrections, settlements and KSeF separately. There is more about connections on the Odoo integrations page.
Based on the applications, integrations and extensions you need and how the system will be maintained. Odoo Community is the free open-source edition, and Odoo Enterprise extends it with additional functionality and services. Odoo Enterprise can run in Odoo Online, on Odoo.sh or in your own environment, among others, while Odoo Community can be installed in your own environment. Odoo Online does not support custom code modules, and running a project on Odoo.sh requires an Enterprise subscription that includes that hosting. That is why we choose the edition and hosting model only after agreeing the features you need and the extent of customisation.
We prepare the quote after reviewing your processes, data and integrations. We show design work, configuration, extensions, migration, training and the fees for running the system later as separate items. Depending on the chosen variant, these can include an Odoo Enterprise subscription, hosting, Odoo.sh, add-on modules and maintenance of custom extensions. Odoo Community does not need an Enterprise subscription, but that does not mean the implementation and maintenance cost nothing. The number of users is one of the factors, but it does not describe the full complexity of the project.
The schedule follows from the first-stage scope, the quality of the data and the number of connections. It allows time for decisions and testing on your side and a cut-over date that suits production. We confirm the go-live date based on how ready the processes, data and team are.
The scope live and signed off, the agreed data and integrations, user instructions and documentation of the solution. We also hand over the rules for handling tickets and the list of further changes. Access rights and responsibility for the environment follow from the chosen hosting model and the contract.
First we assess the configuration, code, data, integrations and documentation. We check what is ready and which problems block go-live. Only then do we decide whether it can be continued, what needs fixing and how to finish the project. Care for a running system is described in our Odoo maintenance and development service.
Let's plan your Odoo implementation around your production and orders
Tell us what you make, which systems you use and which part of the work you want to improve. In the first conversation we will agree the starting point, the people needed for further analysis and the information required to prepare a quote.
You do not need a finished specification. An example order and a description of what happens to it from receipt to dispatch is enough.
What is worth having for the first conversation?
- the type of production and an example product
- a list of your current systems
- the departments and locations the project should cover
- the main problems or constraints
- the planned date of the change and any production calendar constraints
Enquiry sent
Thank you, we'll get back to you within 1 business day.
The enquiry has not been sent
We have marked the fields that need filling in or correcting.