Published Sep 14, 2026
Custom ERP or an off-the-shelf platform?
Compare a working solution, not a license
The choice is not simply a software license versus a development quote. Both approaches need a path from the current operation to a system the team can use.
Start with the important workflows
Identify the rules that are genuinely specific to the business and the areas where standard practice would work. A packaged platform may cover common needs well; custom development may be relevant where the differences are material.
Include the exceptions and integrations
Show both options the same examples: amended orders, partial payments, duplicate records and the systems that must remain. Ask how those cases will be handled and maintained.
Make implementation visible
Compare configuration or development, data migration, testing, training, rollout and support. Record what the quote excludes and who owns each dependency.
Look beyond the first release
Consider licenses, access to the code and data, supplier dependence, maintenance and the cost of expected changes. Custom is not automatically cheaper; an existing platform is not automatically simpler to implement.
Choose around the business
A hybrid approach may preserve useful software and add the missing workflows. The recommendation should explain the fit and trade-offs, rather than begin with a preferred technology.
Run a comparison using your own examples
Prepare a small evaluation pack before asking vendors for a demonstration. Include a normal order, an order amended after approval, a partial delivery and a record with incomplete information. Choose examples that reflect your business, with sensitive data removed where appropriate.
Ask each team to walk through the same cases. Record which behavior is available, which requires configuration, which needs custom work and which is unsupported. This makes differences visible without relying on a long checklist of feature names.
Clarify the implementation boundary
Identify the systems that will remain, such as accounting or a specialist operational tool. For each integration, agree data ownership, identifiers, the direction of updates and the handling of failures. Include a way to investigate a transaction that has not arrived as expected.
Treat migration as a defined workstream. Determine what history needs to move, who will clean the data and how the result will be reconciled. Ask for a rehearsal and an explanation of the checks before the production change.
Compare ownership after launch
Discuss who can change the system and what access the business receives to its data, configuration and source code where relevant. Establish responsibility for maintenance, support and the integrations. Record the terms that affect a future move to another provider.
A credible comparison also includes the changes you already expect. Consider how a new approval rule, business unit or reporting requirement would be delivered and supported. The answer should identify assumptions rather than promise that all future changes will be simple.
Make the recommendation reviewable
Summarize the options against the important workflows, implementation effort, recurring costs, constraints and remaining uncertainty. Separate known scope from work that still needs investigation. A decision can then be based on fit and ownership across the project, rather than the appearance of the demonstration.
For an example of the type of operational work involved, read our ZMatic ERP case study. Its starting point was complex spreadsheet-based operations; your own recommendation should reflect the differences in your business.
