Everyone claims to be faster than average. Here's our arithmetic.
When we say a project came in under the industry benchmark, that benchmark has to mean something. This page shows which published figures we start from, the two ways we turn them into hours, and where the method is weak. If you disagree with it, you have everything you need to say so.
Cost doesn't travel. Hours do.
Every public figure for this kind of work is published in dollars. That's useless for comparison: a rate in Stockholm isn't a rate in Chicago isn't a rate in Bangalore, and the same scope can differ by a factor of three on price alone without anyone being faster or slower at anything.
Hours are the honest unit. They describe the size of the work rather than the size of the invoice. So the first thing we do is convert everything published in currency into hours — and the way we do that is the part most open to challenge, which is why it's spelled out below rather than buried.
Two published guides. Both linked, both quoted directly.
We don't paraphrase the numbers we depend on. Every figure below appears in one of these two documents, and we quote the sentence it comes from so you can check it against the original.
Infor CloudSuite Implementation: Realistic Timeline & Cost Guide
erpresearch.com →The figures we actually use
“A typical mid-market implementation requires 2,000–4,000 partner consulting hours.”
Integration development is listed at 8–15% of total cost, and the mid-market integration line item at $50K–$150K.
Consultant rates: junior $150–225/h, senior $225–350/h, solution architects $300–450/h, project managers $200–325/h.
Training is 5–8% of total; change management a further 5–10%.
Timelines: single-site with extended modules 9–12 months; multi-site international 15–24 months.
Dynamics 365 Business Central, mid-market implementation: $25K–$150K.
Two ways in. They land in the same place.
We ran the derivation twice, from different figures, deliberately. If two independent routes disagree, the method is broken and we shouldn't publish a number at all. They agree — so we take the overlap.
We publish the overlap: 200–600 hours.
Method A reaches down to 160 hours. We don't use that — a range both methods support is worth more than the widest range one of them allows. Worth being explicit that this cuts in our favour at the bottom: a 200-hour floor is easier to come in under than a 160-hour one. We'd rather publish the number the evidence agrees on and name that bias than quietly pick whichever floor flatters us.
What this number is not
- Not a full ERP implementation — that's the 2,000–4,000 hour figure it's derived from.
- Not software licensing or subscription.
- Not data migration, which the same source lists separately at 8–12% of cost.
- Not training or change management — see the next block.
- Not testing, UAT or project management overhead.
What it is
- The integration development line item, and only that.
- The work of making an ERP talk to the systems around it.
- Directly comparable to hours we log against an ERP integration.
Training & change management
Applying the same arithmetic: 5–8% training plus 5–10% change management, against 2,000–4,000 hours, gives roughly 200–700 hours. We quote that band whenever we compare training effort.
Five reasons to treat this as an estimate.
A benchmark that only lists its strengths isn't a benchmark, it's marketing. These are the parts we'd attack if someone else published this.
The method's soft spots
- Cost share stands in for hours share. The 8–15% figure describes budget, not time. Integration developers may bill above or below the project's average rate, which would move the answer.
- The $250 blended rate is ours, not published. We built it from the source's rate card. A different mix of juniors, seniors and architects gives a different divisor.
- The bands are wide. “Mid-market” spans a lot of very different companies, and so does “2,000–4,000 hours”.
The sources' soft spots
- These are commercial market guides, not audited research. They're vendor-adjacent, not peer-reviewed. They're also the best public data we could find — which says something about the state of public data here.
- Figures are dated and pages get revised. Both were published in March 2026 and accessed 31 July 2026. These pages change quietly; if they change, this page changes with them.
One source is Infor-focused, the other spans Dynamics 365, SAP, Oracle and NetSuite. We treat the effort ratios as broadly platform-independent, which is an assumption, not a finding.
How we count our own hours.
A benchmark is only half of it. The other half is whether our own figure is honest — so here are the rules we hold ourselves to.
What we count
- Every hour logged against the project, including meetings, standups and workshops.
- Hours logged outside the official project window when the work was genuinely part of it.
- Go-live day and post-launch support.
- Time spent on work that didn't ship.
What isn't in the number
- Training, which we don't charge for and therefore don't reliably log. When we quote it, we say it's approximate.
- Pre-sales conversations before a project exists.
- Platform development — building Hantera_ itself is not project time.
- The client's own internal hours, which we can't see.
Where a figure is an estimate rather than a timesheet total, the page carrying it says so at the point of use — not in a footnote.
Tell us we're wrong.
If you have better data — a real programme, an audited study, a rate card that makes our divisor look silly — we want it. The number changes when the evidence does, and we'll say so on this page.