Open source ERP

Scope is the main driver: the number of modules, the depth of process mapping, the volume and quality of legacy data, and the number of integrations with banking, payroll, tax and reporting tools. Costs fall into three groups: software licensing (zero for Odoo Community and ERPNext, which are open source, or a subscription for Odoo Enterprise), implementation services paid to a partner for planning, configuration, migration, testing and training, and hosting and operations inside your own cloud or data center. Implementation is usually one-time, while hosting, support and upgrades recur. Ask for a quote built from a written scope that lists each module, each integration, each migration source and each environment, so you can compare proposals line by line.

The timeline depends on how many business processes change, how many entities, currencies and legal books the system must support, and how clean your source data is. A phased plan usually starts with finance and procurement, then adds sales, inventory, manufacturing or projects, with each phase going live only after testing signs off. Dependencies outside the project often set the pace: approvals from process owners, chart-of-accounts decisions, tax configuration, and access to the team that runs your current systems. Ask the partner to show phases, milestones and the assumptions behind each date in the written scope, and to name the decisions that must be made before build starts.

The project needs named process owners for finance, procurement, sales and operations who can make binding decisions quickly, a data owner who can extract, reconcile and approve legacy balances and master data, and testers who can run month-end and order-to-cash scenarios against real examples. Plan for regular time from these people throughout the project, not only at kickoff and go-live. Your team should also own access approvals, security policies for user roles and segregation of duties, and sign-off on the migration reconciliation. Confirm these commitments, the number of testing cycles and the owner for each sign-off in the written scope before work begins.

Some organizations can, particularly where they have experienced administrators, a development process for customization and a tested backup and restore routine. Running it alone means your team owns the hosting, patching, database administration, security configuration, backups, upgrades, add-on compatibility and user support, and it also owns the knowledge when staff leave. Many buyers split the work: an internal team runs daily operations while a partner handles the initial build, hardening, documentation and periodic upgrades under a retainer. Assess your skills honestly against each of these tasks before deciding, and ask a partner to document the runbook so the handover is testable.

Support after launch usually covers three areas: incident response for outages and failed jobs, routine operations such as monitoring, backups, restore tests and security patches, and change requests for new reports, workflows or integrations. DeployOpen offers ongoing support and upgrades as a retainer, which is agreed separately from the implementation scope. Ask any partner what response process applies, who holds the on-call duties, how changes are tested before production, and how documentation is kept current. Any service level figures should appear in the written agreement, not in a sales conversation.

Odoo Community is the open source core published under the GNU LGPL version 3, while Odoo Enterprise is a licensed edition built on that core that adds features such as mobile apps, Studio customization, version upgrades and hosting. Enterprise therefore introduces a recurring subscription cost on top of implementation and hosting, and the budget should reflect the modules and users you need. Check whether the features you depend on sit in Community or Enterprise, and note that AI features in Odoo 20 require credits bought as in-app purchases. Ask the vendor for current pricing in writing, because this page does not state prices.

Plan upgrades as a recurring project, not a one-off event. Each upgrade requires a test copy of production, a review of custom modules and integrations against the new release, a reconciliation of key financial reports, and a rollback plan. Odoo Enterprise includes version upgrades as one of its listed features, while ERPNext and Community deployments depend on your own or a partner's process. Track the release cadence of your chosen platform, keep customizations in version-controlled code, and agree in the written scope who performs upgrades, how often, and who signs off on testing. Ask the partner to show a previous upgrade plan as an example.

A fixed-scope quote should list the modules, the number of users, the companies and currencies, the integrations, the data migration sources, the training sessions and the go-live support, each with a named deliverable. Ask the partner to show what is excluded, such as new custom reports, extra integrations or post-go-live fixes, and how a change request is priced and approved. The written scope should be signed before work starts, because the scope, deliverables and timeline are what you are actually buying. If a line item says only "implementation" without deliverables, ask for a breakdown before comparing quotes.

The partner should name each module in scope, such as accounting, inventory, purchasing or manufacturing, and state which standard features will be used without code changes. Ask which customizations are planned, whether they rely on configuration or custom code, and who maintains that code after handover. Ask how the plan handles a requirement discovered during design that the standard module does not cover. A strong answer describes a written process for assessing fit gaps, estimating the effort, and deciding whether to change the process or extend the software.

The partner should describe how it will extract balances, open invoices, chart of accounts mappings, customer and vendor master data and historical transactions from the legacy system. Ask for the reconciliation method, such as comparing trial balances, subledger totals and open item counts by period, and for the named person on your side who approves each reconciliation before cutover. Ask how many dry-run migrations are planned and what happens to data changed in the legacy system between the last test and go-live. Without a written sign-off step, a migration has no clear finish line.

Confirm which edition the quote assumes, because Odoo Community is the open source core, while Odoo Enterprise is a licensed edition built on it that adds features such as mobile apps, Studio customization, version upgrades and hosting. ERPNext is licensed under GPL-3.0 and is free to use, but the implementation and support services are paid separately. Ask for each license or subscription in the quote, who holds it in your name, the renewal terms, and the number of users it covers. A good answer separates software licensing from services and states what changes if you later switch editions.

The partner should explain how it will test each upgrade in a staging environment built from recent production data, how custom modules will be checked for compatibility, and how a rollback will be prepared. Ask whether upgrades are included in a support retainer or quoted separately, and how often they are scheduled. For Odoo, ask whether the plan depends on Enterprise upgrade tooling and how that is licensed. Ask for an example of the upgrade runbook and the change control record that will be kept for each release.

Ask for written support hours, the severity definitions, the channels for reporting an incident, and the escalation path from first-line support to engineering. Confirm whether support covers the platform, the customizations, the integrations and the hosting layer, or only some of them. Ask who is on call for month-end close and how urgent issues during that period are handled. Support terms should be written into the contract with clear response expectations, and any figures for response or resolution should be stated explicitly in the signed agreement.

A backup is only useful after a restore has been tested. Ask the partner which data stores are backed up, including the database, file attachments and configuration, how often backups run, where they are kept, and how long they are retained. Ask for the restore test schedule, the success criteria, and whether the test includes a full application restore into a separate environment. Records that must be kept for regulated finance activity, such as those described in SEC Rule 17a-4(b) for broker-dealers, should be part of the retention design, so ask how retention is set and who confirms it with your compliance team.

Ask the partner to confirm in writing which administrator accounts will be created, who will hold the root, database and application admin credentials at handover, and how those credentials are stored and rotated. Ask whether multi-factor authentication is enforced for every administrator and how access is logged and reviewed. Your organization should hold the primary administrator access, with the partner's access granted through a documented, time-limited process. Confirm the offboarding steps for any partner staff who leave the project, since this is a common gap in handover.