Odoo implementation, built around how you actually work, not around the demo
We map how your business actually works, configure Odoo around that, migrate your data and train your team. Before we start, you'll know which apps you need, how long it takes and what it costs.
Odoo Enterprise, hosted on Odoo Online or on Odoo.sh
We work exclusively with Odoo Enterprise. What's still open is the second question: where your system runs. Both paths come from Odoo itself, both are maintained and secured, and they differ in what you're allowed to do with them.
| Odoo Online | Odoo.sh | |
|---|---|---|
| What it is | Hosted by Odoo itself, with no server to manage on your side. | A development and operations environment from Odoo, with access to servers and logs. |
| Custom development | Changes through settings and apps from the Odoo Store. Your own program code isn't possible. | Your own modules and code, managed through Git. |
| Test environments | A copy of the database to try things out in. | Your own branches for testing and development, with a copy of production data. |
| Updates | Odoo updates it, nothing for you to schedule. | You decide when to update, and can test it first in a staging branch. |
| Backups | From Odoo, automatically. | From Odoo, automatically, plus your own backups on request. |
| Cost | Included in the subscription. | In addition to the subscription, depending on size and number of environments. |
| Best fit | Businesses that get by with the standard and don't want to deal with operations. | Businesses with their own modules, integrations, or multiple companies. |
Our recommendation depends on what you're planning.
As long as the standard is enough, Odoo Online is the simpler path.
As soon as custom modules, an integration like our BMD export, or multiple companies come into play, the path leads through Odoo.sh, because it lets you test before anything goes into production.
A switch from Odoo Online to Odoo.sh is possible later, and the other way around too.
Whatever version you're on today
From an old installation to the current release: few projects start from zero. Here's where we work, and what we'd actually recommend.
Migrate, don't build further
Odoo no longer ships bug fixes or security updates for these versions. Version 15 fell out of support in October 2024, version 16 in September 2025. We still support installations like these, but the sensible next step is a cleanly planned migration, not further development on a version nobody maintains anymore.
This is where we like to work
These three versions get bug fixes and security updates from Odoo. Version 19 has the longest runway ahead of it. Implementation, customization and support, we do all of it here in full.
Leaves standard support in September 2026
If you're on version 17 today, that's not an emergency, but it is the moment to plan the migration instead of putting it off. We'll look at your installation and tell you honestly how much work the switch actually is for you.
The apps that carry most of the weight
Odoo ships with dozens of apps, but most implementations run on a focused core. Here's what we configure most often, and roughly what each one is responsible for.
Sales
Quotes, order confirmation and pricing rules, feeding straight into invoicing and delivery.
CRM
Pipeline stages, activities and follow-ups, so no lead sits untouched in someone's inbox.
Inventory
Real-time stock across warehouses, with routes for receiving, picking and delivery.
Manufacturing (MRP)
Bills of materials, work orders and shop-floor tracking tied directly to stock.
Purchase
Requests for quotation, vendor pricing and automatic reorder rules based on demand.
Accounting
Bank reconciliation, tax rules and localised statutory reports for your country.
Point of Sale
Offline-capable checkout that syncs back to inventory and accounting the moment it's online.
Website & eCommerce
A storefront on the same data as the rest of the business, no separate platform to sync.
Project
Tasks, timesheets and milestones for teams billing time or delivering client work.
Employees & HR
Contracts, time off and org structure, the backbone most other HR apps plug into.
Field Service
Scheduling, on-site checklists and instant billing for engineers working off-site.
Subscriptions
Recurring billing, upsells and churn tracking for membership or SaaS-style revenue.
Six phases, the same on every project
The names are deliberately simple, so at any point you can say exactly where we are and what happens next.
Discovery & process mapping
We sit with the people who actually do the work, not just management, and document how orders, stock and money really move today.
Blueprint & module strategy
A written future-state design: which apps, which edition, what stays standard and what genuinely needs configuration.
Configuration & build
We configure the system against the blueprint, building only the pieces that settings alone can't cover.
Data migration & testing
Historical data is cleaned, mapped and loaded, then the whole system is tested against real business scenarios, not just happy paths.
Training & go-live
Role-based training on real tasks, a rehearsed cutover plan, and a go-live date the whole team has actually agreed to.
Post-launch support
We stay close in the first few weeks, because that's when most questions come up. After that, it moves into ongoing support.
Configure first, adapt second, code only when needed
Every custom line of code is a small, permanent liability. It has to be tested against every future upgrade, understood by whoever supports it next, and maintained for as long as the business uses the system. So we default to the platform's own configuration first, and reach for custom development only when there's genuinely no other way to meet a real business requirement. It keeps your system leaner, cheaper to maintain, and safe to upgrade for years after we hand it over.
Does the standard already have this?
Most special requests turn out to be a built-in workflow nobody has set up yet.
Can settings handle it?
Rules, approvals, numbering sequences, pricing logic and permissions are settings, not development.
Does it need its own module?
Anything that needs new fields or views, we build as its own module: versioned, documented, and traceable at the next upgrade. We don't click it into the database, because changes like that become impossible to find later and break at the next upgrade.
Only then, custom development
Reserved for genuine edge cases, built to platform standards and fully documented.
The part everyone underestimates
"Just export the spreadsheet" is where most migration timelines quietly fall apart. Product codes don't match across systems, the same customer exists under three different names, and stock counts from a year-end audit rarely agree with what's actually on the shelf. We treat migration as its own workstream, not a task squeezed in during the last week.
Audit the source data
We look at what actually exists before assuming what should be migrated.
Clean and de-duplicate
Merging duplicate customers and products before they ever reach the new system.
Map fields deliberately
Every field mapped and documented, so nothing gets silently dropped or guessed.
Dry-run before cutover
A full rehearsal migration you can inspect, so go-live day has no surprises.
Odoo Ready Partner and active OCA member
Working with an official Odoo partner means your implementation follows standards Odoo itself sets, not one consultant's personal way of doing things.
Odoo Ready Partner
Verified in Odoo's official partner directory, so you are working with a vetted team.
OCA Member
An active member of the OCA, contributing to and building on trusted open-source ERP modules.
What an implementation actually means day to day
The difference doesn't show up as a percentage. It shows up in the fact that Monday after go-live, people are working, not debating it. That stock counts are right, invoices go out without a follow-up question, and nobody's quietly still running the old spreadsheet in the background.
Questions we get on almost every call
Let's scope your implementation together
Tell us where you are today, spreadsheets, an outgrown system, or a first ERP altogether, and we'll give you a straight answer on scope, edition and timeline before you commit to anything.