Which costs arise before and after launch?
First separate the effort needed to reach initial production use from the expenses that follow. Also record which work your provider handles and which stays with you. This reveals whether a low proposal price assumes, for example, that your team does all the data cleaning itself.
Design, setup and development
Preparation includes understanding workflows, making business decisions and describing what the first version should do. Standard software then requires configuration and possibly extensions. Custom ERP software requires the agreed features to be developed and tested. An existing platform can combine both approaches.
The number of screens is not enough to estimate effort. A simple approval step may need different deputies, permissions and exception handling. Describe who starts a work item, who may edit it and when it is complete.
Data migration, interfaces and training
A data export is not a completed migration. Old customer numbers need mapping, required fields need completing and open work items need transferring correctly. Plan a test import and a business review. Clarify both sides of each integration: data format, access rights, test access and contact people.
Training is more than a product demonstration. Future users should practise their actual tasks. Project management, test appointments and questions about requirements take working time within the business. Our guide, Plan ERP implementation, helps you assign this effort to individual owners early.
Operations, maintenance and later changes
Depending on the agreement, licence or subscription fees, hosting, support, updates and interface maintenance continue after launch. New users, growing data volumes or additional features may also change the costs. Ask about the billing unit and included quantity for each item.
A concrete example shows why these boundaries matter: Odoo's pricing page lists implementation services, certain usage credits and maintenance of custom code as excluded from the stated subscription price. This is a limit of that provider's offering, not a general pricing rule for ERP systems. Source: Odoo, plan inclusions, checked on 22 September 2026.
The following structure is a template for your estimate. Enter prices only once scope, quantity and responsibility are clear.
| Cost category | Before launch | Clarify for ongoing operations |
|---|---|---|
| Software | Setup, development or licence | Users, modules, usage |
| Data & integration | Cleaning, import, integration testing | Interface maintenance, changed data formats |
| Team | Decisions, testing, training | Onboard new users, review processes |
| Technology & support | Set up the environment, support launch | Hosting, updates, support, recovery |
How do you compare standard software and custom development?
Start with one complete workflow from your business. If existing software can support it with reasonable configuration, it deserves a place in the comparison. Record where you would need to change your workflow and what that would mean in daily work.
Assess a custom solution against the same workflow, roles, data and acceptance criteria. A lower initial total means little if a required integration is missing. Conversely, a larger feature catalogue is not an advantage if your team does not need the extra features.
The choice between cloud and self-hosting is separate. Custom software can also be hosted externally. Compare both the business implementation and responsibility for operations and changes. None of these combinations is inherently cheaper without knowing the project.
If essential workflows in existing solutions only work with extra manual effort, it is worth assessing custom ERP software. The starting point should be the specific bottleneck, rather than a wish to reproduce every existing habit.
Even a solution without licence fees may involve setup, infrastructure, customisation and support costs. “Free” should always refer to a named service.
How do you make proposals comparable?
Use the same period of use and starting scope for every provider. Include recurring costs during testing or setup if the proposal says they begin then. Avoid counting the same service twice, such as support already included in a subscription.
Use these fields for each proposal item: service and exclusions, quantity, unit, price per unit, one-off or recurring, included or optional, delivery party and business owner. Mark estimates and assumptions that have not been checked. An empty field is an open question; it does not mean zero euros.
The following calculation model organises the items. It does not automatically produce a project price.
- Record initial effort. One-off external services and necessary purchases.
- Add operations over the same period. Use transparent quantities and price changes.
- Include internal capacity. Value planned hours per role using a consistent internal cost rate.
- Show risks separately. Record unresolved migration, integration or change risks with their causes and assumptions.
Internal effort matters to the business case but does not automatically create an additional invoice. Keep two views: which payments fall due, and how much capacity does the project use overall? Management can then assess both cash flow and availability.
Which costs are easily overlooked?
Watch for tasks that fall between responsibilities. Who fixes an import error if the legacy system delivers a different data structure than assumed? Who tests a connector after the connected service is updated? Is launch support included, or does the proposal end at technical delivery?
Also check data export and handover at the end of the relationship, access to documentation and responsibility for customer-specific changes. These arrangements belong in the proposal. A generic contingency allowance does not replace clarifying them.
A short risk register helps with uncertainty: cause, possible impact, next assessment step and owner. Unknown data quality can be examined with a representative sample export, for example. A fixed percentage contingency for every ERP project would hide the differences between these risks.
When does the investment pay off?
Before implementation, define which operational effort you want to change. Useful observations include processing time per order, the number of follow-up questions and manual rework. Measure the same activities again later, allowing for changes in volume and complexity.
Freed working time is initially available capacity. It is not automatically a salary saving or additional revenue. Separate demonstrable financial effects from better visibility, fewer interruptions and other qualitative improvements. Without reliable assumptions, these factors cannot establish a fixed payback date before the project begins.
What information does your budget discussion need?
Prepare a typical work item and an important exception. Add the roles involved, existing systems, available data exports and the integrations that must work at initial launch. Also identify business deadlines and the time available from your subject-matter owners.
This makes it possible to distinguish what can already be estimated from what first needs assessment. A useful outcome of the initial budget discussion is a clear scope with assumptions, responsibilities and next assessment steps.