You search for a comparison of two business systems. Page one gives you a dozen articles, all helpful, all well written, and all published by companies that implement one of the two. There is no neutral page, and there is not going to be one, because nobody without a commercial interest has any reason to write it.
That is not a complaint about the industry; it is a structural fact you have to work around. This is how to run the choice from your own side of the table, so that the decision belongs to you rather than to whoever ranked first.
Why the search results cannot help you
The economics are simple. Implementation partners earn on projects, so they publish content that ranks for the comparison, and the comparison concludes with the product they implement. Every party in that market is behaving rationally, and the result is still that page one contains no independent assessment.
The practical consequence is that feature lists are the least useful input you can gather. Any serious system in this category will do what you need. The difference between them is not capability, it is what happens to you over the following five years: what the work costs, what your data does, and how easily you leave.
The overrun is measured, and it is not small
Before deciding anything, calibrate your expectations against evidence rather than against a proposal. The most useful study on this remains the analysis by Flyvbjerg and Budzier of 1,471 information technology projects, which found an average cost overrun of 27 per cent and, more importantly, that one in six projects overran by an average of 200 per cent.
Read the second number rather than the first. The average is manageable and misleading. The real risk in this category is not that the project costs a quarter more; it is the one-in-six chance that it costs three times more and takes far longer, and no vendor’s proposal has ever mentioned that distribution.
What that means practically: whatever the quotation says, ask what happens if the project takes twice as long, and get the answer before you sign rather than during month seven.
Write your requirements before you look at anything
The single highest-return hour in this process is the one you spend before opening a browser. Write down, in your own words, the twenty things the system must do — not features, but the actual jobs: raise a quotation with these approvals, see stock across two locations, produce this report for the auditor, let a salesperson check a price from a phone.
Then rank them. Five that would end the deal if missing, ten that matter, five that would be pleasant. Almost nobody does this ranking, and it is the thing that makes every subsequent conversation short, because it converts an open-ended sales discussion into a scored comparison.
The UK government’s guidance for its own technology choices frames the objective the same way, advising teams to minimise total cost of ownership, including reducing the chance of getting locked in to long contracts. Total cost of ownership is the phrase to keep saying in the room, because it moves the conversation off the licence fee.
Make the demonstration yours
A vendor demonstration is a rehearsed performance on clean data. It proves the software can do the thing under ideal conditions, which was never in doubt.
Replace it. Send each vendor the same three scenarios from your own business, in writing, before the meeting, and ask them to perform those and nothing else. Use a real awkward case: the order that is part cash and part credit, the customer with two trade licences, the item you sell by weight and buy by carton. Then watch what they do when it does not fit — whether they configure it in front of you, promise development, or change the subject.
Score the same three scenarios across every vendor and the comparison writes itself, in a form no published article could have given you. It also surfaces the thing feature lists hide: how much of what you need is standard, and how much is configuration somebody has to build and then maintain — which is the same distinction that decides whether a technology decision is one you end up paying for twice.
The data question that decides the real cost
The licence is quoted, the implementation is estimated, and the data migration is where projects actually go wrong. Your existing records have duplicates, inconsistent codes, and fields that mean different things to two departments who have each been right for years.
The UK government publishes a usable framework for describing this rather than arguing about it, defining data quality across six dimensions: completeness, uniqueness, consistency, timeliness, validity and accuracy. Score your customer list and your item master against those six before you choose anything. It takes a day and it tells you the size of the real project.
And be clear about what the subscription covers. Odoo, to take a vendor that publishes it plainly, states on its own pricing page that the subscription covers hosting, support and maintenance, and that implementation services, consulting and the maintenance of custom code are excluded. That is honest and it is typical. The licence is rarely the biggest line in year one.
Ask the exit question before you enter
The question that most changes a vendor’s tone is: show me the export, now, in this meeting.
Exports are usually possible and usually constrained in ways nobody mentions. Zoho documents that its CRM export is capped at 200,000 records per module per run in CSV, and 50,000 in spreadsheet format. Other vendors publish comparable limits: scheduled full exports restricted to higher editions, files that expire within days of being generated, and attachments handled separately from records. None of that is hidden. It is simply never in the comparison article.
None of that makes any of them a bad choice. It makes them systems with known exit conditions, which is the only kind worth buying. What you are testing is whether the vendor answers precisely or reassures vaguely, and that answer predicts the rest of the relationship.
The order I would actually take
Requirements ranked, in writing, before any vendor contact. A data quality score on your two most important lists. Three scenarios sent to every vendor in advance. A written total for year one and year three that includes implementation, migration, training and the internal time. The export, demonstrated. And a named person inside your company who owns the outcome, because a system nobody owns is the shape of failure described in why most UAE pilots never reach production.
The UK government’s own code of practice for technology decisions puts the same discipline into thirteen points, of which two matter most here: make use of open standards, and define your purchasing strategy before you go to market rather than after.
Do that and the absence of a neutral comparison stops mattering, because you have built one. If you are inheriting systems rather than choosing them, the starting point is different and is covered in the technical due diligence I run. And if there is nobody in the company whose job is to hold these questions, that is what a fractional CTO engagement exists for, and it is cheaper than the one-in-six outcome.
Frequently asked questions
Should we hire a consultant who does not implement anything?
It removes the obvious conflict, and it introduces a subtler one: an adviser paid to advise has an incentive for the evaluation to be thorough. Either arrangement works if the deliverable is defined in advance — the ranked requirements, the scenario scores, the total cost model — and if the engagement ends when that is delivered. What you should not do is take the recommendation of someone who will also be paid to build it, without a second opinion.
Everyone in our sector uses one particular system. Is that not the answer?
It is useful evidence and a poor decision rule. Sector concentration usually reflects which vendor invested in that sector’s sales, and it does tell you the local skills market is deeper, which genuinely reduces risk. Weigh it as one input among your ranked requirements rather than as a conclusion, and ask the companies using it what they would choose again, which produces more candour than asking what they use.
How long should an evaluation take?
Three to six weeks for a company of ten to a hundred people, most of it spent writing requirements and scoring data rather than in meetings. Longer than that and the market has moved and people have lost interest; shorter and you are choosing on impressions. The evaluation is also the cheapest part of the whole project, so compressing it to save time is the least profitable saving available.
Can we start small and expand later?
Usually yes, and it is generally the right approach, provided the first module is one that delivers value alone rather than one that only makes sense once three others are live. The failure pattern is buying the whole suite, implementing one part, and paying for the rest for two years while it sits unused. Ask what the licence looks like if you never adopt modules two and three.
The partner says our processes need to change to fit the system. Is that reasonable?
Often yes, and it is frequently the most valuable part of the project, because standard processes are cheaper to run and easier to hire for. The line worth defending is the handful of things that are genuinely how you compete rather than how you happen to work. Identify those in advance, protect them, and be willing to change everything else. A company that customises the system to preserve every existing habit ends up owning software nobody else can maintain.