ERP RFP questions

A sound fit-gap method checks each business process against standard functions before any configuration starts, then records every difference as a named decision. The partner should walk your processes end to end, mark each step as covered by standard features, configurable, requiring a workaround, or requiring custom code, and agree the classification with your process owners. Ask the partner to explain how they will handle steps that fall outside standard features, since those steps drive most of the later cost and upgrade effort. Confirm that the method covers finance, sales, purchasing, inventory and any industry-specific processes in your scope.

Each requirement should have an identifier, a plain statement of the business need, the process it belongs to, the owner who approved it, and the standard feature or configuration that meets it. The partner should keep this traceability in a shared register so that a change request can be followed from the original need to the setting, module or custom code that delivers it. Ask how they link requirements to test cases, since that link is what lets you confirm nothing was dropped during configuration. A partner that cannot show this linkage will struggle to explain later why a feature behaves as it does.

Workshops should be organized by process, such as order to cash, procure to pay, record to report and inventory, rather than by software module, so that the discussion follows how work actually moves between teams. Each session should have a fixed agenda, a named facilitator, the process owner and the users who perform the work, and a written output within a short period after the session. Ask the partner how many workshops they expect for your scope and who must attend, and confirm that the schedule is part of the written scope rather than an informal estimate. Workshops that skip the exception paths, such as credit holds, returns or intercompany entries, tend to surface gaps only during testing.

A gap register is the working list of every requirement the standard product does not meet directly. Each entry should describe the gap, the business impact, the options considered (configuration, process change, third-party add-on, or custom module), the chosen option, the estimated effort as stated by the partner, and the owner who accepted the trade-off. The partner should maintain the register during the project and review it at each steering meeting. Ask for a blank template and a populated sample so you can judge whether the register contains real decisions or only a list of features.

Decisions should be captured in a sign-off record that names the decision, the process owner who approved it, the date, the alternatives rejected and the reason. Sign-off should happen before configuration begins for each process, and changes after that point should go through a formal change request with the same record. The partner should also state who in your organization has authority to accept residual gaps, since that authority is often unclear in multi-entity programs. Confirm that the sign-off record will be handed over as part of the deliverables and kept in your document system, not only in the partner's tools.

A strong answer names a process owner for each area, produces a written gap register with classified items, and ends each workshop with a sign-off record that lists the decisions taken. Ask the partner to provide a sample deliverable from a previous engagement with client details removed, or a fully illustrative example, so you can review the format and level of detail. Look for specific references to standard features, the reasons for each custom item, and the owner who accepted it. Vague summaries, feature lists without decisions, or registers with no owners are signs that the fit-gap will not hold up under testing or audit.

The fit-gap phase is usually a one-time cost paid to the partner for analysis, workshops, documentation and sign-off, and it is priced from the written scope rather than from a published rate. The main drivers are the number of entities, currencies and countries, the number of processes in scope, how many workshops are needed, how many stakeholders must attend, and how many industry-specific processes require custom analysis. Ask the partner to separate fit-gap effort from configuration and custom development in the quote, so you can see what you pay for analysis and what you pay for building. DeployOpen does not publish prices, and a quote follows from the written scope agreed before work starts.

Your team can run a fit-gap internally if it has process owners who know the work, someone who understands the standard Odoo or ERPNext functions, and time to maintain a register and sign-off record. The risk is that internal teams often map to the software they already know rather than to the standard features that exist, which pushes gaps into custom code. Many organizations use an external partner to challenge the classification and facilitate workshops while keeping decisions with their own owners. Confirm with any partner whether they will accept your existing templates or require their own, and who owns the final register.

A credible partner keeps custom code in its own version-controlled repository, separated from the vendor core, and tests every change against a copy of production data before it moves forward. Custom behavior should live in separate modules or extensions that hook into documented extension points, so the vendor's core can be replaced during an upgrade without rewriting the business logic. Ask the partner to show the repository layout, the branching and review process, and the list of places where custom code touches standard objects. Each of these answers tells you how much work the next major version will require.

According to the Odoo upgrade documentation, major version upgrades are mandatory every two years on Odoo Online and Odoo.sh. That means custom modules must be planned as a recurring cost, not a one-time build. Odoo's upgrade service moves a database to a newer supported version using an upgraded test database, which the client should test before anything goes to production. Ask the partner how many custom modules they expect to adjust in each cycle and who owns that testing window.

No. Per the Odoo upgrade documentation, using the upgrade service on premise requires an Enterprise subscription, and the Community edition has no access to that service. A Community-based deployment can still be upgraded, but the team must perform the migration of code and data itself, so the effort and skill required should be scoped before you commit. Ask the partner which edition they have assumed, who holds the subscription, and what happens to custom modules if the subscription lapses.

Each upgrade should be rehearsed on a non-production copy that matches production in code, configuration and a recent data extract, with personal data masked where the rules require it. For Odoo, the upgraded test database is the primary rehearsal artifact, and it should pass the agreed test scripts before production is touched. Ask the partner to describe the environments (development, test, staging, production), how refreshes are scheduled, and who signs off the results. Database duplication with neutralization is one documented way to create test copies on premise.

ERPNext customers must run a listed version of the Frappe Framework and ERPNext, according to Frappe's supported versions policy. Per that page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Both supported majors receive frequent minor releases, for example v16.51.1 on October 15, 2026 and v15.123.0 on October 14, 2026, so the partner should plan routine minor-release testing as well as major migrations. Ask which version the design targets, when the next major move is planned, and whether the build avoids core file edits.

Custom code should ship with automated tests, documented dependencies, and a short description of each business rule it implements. Without tests, every upgrade becomes a manual regression exercise, and the team cannot prove that financial postings, tax calculations or approvals still behave as before. Ask the partner what test coverage they commit to for custom modules, which test data they use, and how failing tests are handled before a release. A partner who cannot describe their test approach should not be scoping upgrade work.

A useful upgrade estimate lists each custom module, the core objects it depends on, the changes expected in the next major version, the test cases to rerun, and the environments needed. It should also state the assumptions about the vendor's release notes and the partner's involvement in each cycle. Ask for the estimate in writing, with the basis for each line and a clear statement of what the client's team would own. The estimate is only as good as the module inventory behind it, so ask how that inventory is kept current.

Upgrade work usually falls into three cost areas: vendor subscription or licensing needed to access upgrade tools, partner effort for code and test changes, and internal time for business testing and sign-off. The first is recurring, the second recurs with each major version, and the third is often underestimated. Ask the partner to separate these items in the quote, to state whether ongoing upgrades sit under a support retainer or a separate fixed scope, and to confirm how changes to custom modules are documented and approved.

Role-based training is normally part of the written scope, and the roles come from the fit-gap workshops. Each role, such as accounts payable clerk, warehouse operator, approver or controller, gets a list of the screens, documents and approval steps it uses in the configured system. Training then covers those tasks using your own company data and your own approval rules, not generic demo content. Confirm in the quote which roles are covered, how many session groups are planned, and whether sessions are delivered on site, remotely or both.

Train-the-trainer means the implementation team teaches a smaller group of your own super users, who then train colleagues in their departments. This reduces dependence on the implementation team after go-live and gives you people who can answer routine questions locally. Ask the partner how many super users they expect per function, what material they will hand over, and whether super users sit in the same sessions as the implementation consultants so they learn the configuration reasons, not just the button clicks.

Practice happens in a non-production copy of the system, usually a training database that contains configured processes and sample or anonymized data. Users need repeatable practice on the same transactions they will run in production, such as a purchase order through receipt and vendor bill, or an order through delivery and invoice. Ask how many practice environments are provided, how they are refreshed when configuration changes after testing, and how personal data is masked in them, since a copy of production data carries the same privacy obligations as the original.

Ask for training materials to be delivered into your own documentation system, in editable formats, and linked to your configuration record. Typical items are role guides, process maps, screenshots from your configured system, short recordings and a list of known exceptions. Materials that stay only inside the partner's tools become expensive to update later. Confirm in writing who holds the source files, whether they can be edited by your staff, and how they are versioned against each release of the platform.

Training should be repeatable without the implementation team. Plan an onboarding path for new hires that uses the role guides and the sandbox, and a named internal owner who approves changes to those guides. After each platform upgrade, the super users should test the changed screens in the upgraded test environment before production, then update the guides and run a short briefing. Odoo states that on-premise and cloud upgrades should be tested on an upgraded test database before production, so ask how the partner will support that cycle and whether it is in the fixed scope or a retainer.

Training should be scheduled backward from the cutover date, not as a separate workstream. Users need to be trained on the configured system close enough to go-live that they remember the steps, yet early enough to practice the migrated data and the first closing period. The cutover plan should name which roles are needed during the freeze, which users handle the first live transactions and who supports them during the first weeks. Ask the partner to show this sequence in the project plan and to state what happens if a role is not trained by the planned date.

Training cost depends on the number of roles, the number of users per role, the number of sites and languages, and whether sessions are live or recorded. Your own staff time is a cost too, because super users and approvers must release hours for practice and review. Ask for the training effort to be itemized in the quote, with session counts, material deliverables, sandbox refreshes and any post-go-live refresher sessions. No price or duration should be assumed until those items are written into the scope.