The real cost of a 6-18 month ERP rollout

Walk into any mid-market manufacturer running a 6-18 month ERP rollout and ask their CFO what it cost. They will quote you the licence and the implementation SOW. Those are the two numbers procurement underwrote. Those are also the two smallest numbers in the actual cost stack.

The expensive numbers are the calendar, the senior subject matter expert hours pulled off the floor for requirements workshops, and the operational disruption while the rollout is in flight. None of those land on a PO. All three are larger than the licence.

The calendar is what surprises buyers most. The licence conversation takes a week. The implementation SOW takes a month. After that the calendar runs on requirements gathering, config decisions, data migration, integration build, UAT, training, and cutover. none of which are individually unreasonable, but which compound.

A typical mid-market rollout we have observed lands in the 12-16 month range from kickoff to first measurable operational outcome. The first six months are mostly meetings. The next four are mostly migration and integration. The last two to four are mostly hardening and cutover. Through that window, the operating business is paying for both the legacy system and the new one, and the senior operators are spending one to two days a week in workshops instead of running the floor.

The senior subject matter expert is the person who actually knows how the shop runs. They are the buyer who knows the vendor history, the planner who knows the rough-cut capacity, the intake engineer who knows the conventions per customer. They are also the person whose time the rollout consumes most.

A representative SME load across a 14-month rollout: 4 senior people, 6-10 hours per week each, for 56 weeks. At fully loaded comp that is a six-figure operational cost the rollout SOW does not capture. It also creates a second-order cost the rollout SOW definitely does not capture: those people are not running the operations they are SMEs in. The floor feels it.

A rollout SOW quotes implementation services, licence, and (sometimes) data migration. It does not quote six costs that show up reliably in every rollout we have audited post-mortem. None of these are exotic. All of them are predictable. None of them are itemised in the contract.

Four senior operators, eight hours a week, for fifty-six weeks. At a fully loaded rate of $120/hr (salary + benefits + overhead + the opportunity cost of what they were not doing), that is $216k of internal payroll the rollout consumes. None of it lands on the rollout PO.^[1]

We have seen this every rollout. A senior buyer or a senior planner who has been carrying institutional knowledge for a decade gets pushed into eighteen months of workshops, twelve months of UAT failures, six months of post-go-live triage, and gives notice in the third quarter. The cost of replacing them. recruiting, ramp, lost institutional context. is a line item nobody put in the rollout business case.

During requirements workshops the shop asks for a long list of small customisations. extra fields on the PO form, a custom approval workflow for capital equipment, a bolted-on report for the operations VP's Monday meeting. Each one is cheap individually. Each one is also a permanent dependency you have to carry through every subsequent upgrade. By rollout three years later, the customisation list is the reason the upgrade slips by six months.

The integration to the existing MES, WMS, or finance system is built once during the rollout. Then the legacy system changes (a vendor patch, a schema migration, a connector deprecation) and the integration breaks. The first re-build is unbudgeted. The second is also unbudgeted. By year two, the integration carries its own steady-state maintenance cost that nobody quoted.

Training happens on a schedule. Operators on PTO, parental leave, vendor visits, or any of the legitimate reasons a real workforce is not 100% present miss the training. They get retrained ad-hoc, by their colleagues, on the floor, with all of the consistency that implies. Six months after go-live, the variance in operator competency on the new system is the highest-frequency source of data quality issues.

The rollout SOW ends at cutover. The reality is that the system needs one to two quarters of stabilisation work before it produces stable operational outcomes. fixing workflow bugs that only show up at month-end close, re-training operators on the workarounds that emerged, fixing the report definitions that came out wrong. The quarter of stabilisation is paid for by the operating business in unbudgeted time.

The operations-layer alternative does not replace the ERP. The ERP stays. The integration is read-mostly initially, with scoped write paths through the approval gate for the specific workflows that get put in scope. The unit of deployment is one workflow.

The math at the workflow level looks very different from the full-rollout math. The first workflow ships in a calendar window measured in weeks, not quarters. The SME hours consumed are scoped to the workflow being deployed. typically two to four hours per week from one or two operators. The ERP integration is bounded. read access to a defined set of tables, write access through the gate for a defined set of actions. None of the operating business changes outside the scope of that workflow.

That is a different shape of investment. The buyer is not underwriting an 18-month bet on a system. The buyer is underwriting a 4-week bet on a workflow. If the workflow ships, the next workflow is a 4-week bet against a measurable outcome the first one produced. If it does not ship, the investment is a quarter of a quarter, not a quarter of a year.

A common confusion when buyers first see the overlay shape is whether the operations layer is a replacement for the ERP. It is not. The distinction worth being precise about: the operations layer replaces the human translation workthat sits between unstructured sources and the ERP write. It preserves the ERP itself, the existing integrations, and the existing reporting.

PDF transcription into PO forms. Email-to-RFQ packet conversion. Cross-checking engineering revisions against open POs by hand. Bulk-keying drawing intake into the item master. Reconciling spreadsheet trackers against ERP records at month-end. All of this is human translation work. None of it requires the ERP itself to change.

The ERP system of record. The finance posting logic. Statutory reporting. The MES on the floor. The WMS in the warehouse. The existing integration to the customer's procurement portal. The chart of accounts. The data model the finance team has spent years tuning. All of these stay in place and keep doing what they do.

The most underrated criterion in the table above is reversibility. A full ERP rollout is functionally irreversible once you are past the cutover. The legacy system is decommissioned, the data is migrated forward, the licences are signed for multiple years. If the new system is the wrong fit, the recovery cost is a second rollout.

An overlay workflow is reversible per workflow. If the drawing-intake workflow does not perform, you turn off the gate, the upstream parsers stop drafting proposals, and the intake engineer goes back to the previous flow. The ERP was never modified outside the explicit scope of the workflow. The data the workflow generated is auditable and can be unwound.

For a CFO underwriting an investment under uncertainty, the reversibility property is what makes the overlay shape fundable. The downside is bounded.

This is not an article that says the full rollout is never the right answer. There are clear cases where it is.

If the current ERP is a 20-year-old on-prem system that no longer receives security patches, the full rollout is probably the right answer regardless of cost shape, because the risk profile of the legacy is no longer acceptable. If the company is consolidating across multiple legacy ERPs following M&A, the full rollout is the right answer because the value is in the consolidation itself, not in any one workflow. If finance and compliance are stuck on an unsupported version, the full rollout is the right answer because the alternative is non-compliance.

In every other case. and this covers the bulk of mid-market manufacturers. the operations-layer overlay is the under-discussed alternative that gets the operational outcomes the rollout promises, faster, and at a fraction of the calendar and SME cost.

Four ERPs cover most mid-market conversations we have. A two-or-three sentence honest take on each, from the overlay perspective. None of this is an endorsement of any vendor; it is a read on where the overlay shape sits against each incumbent.

If you are already on S/4HANA, the overlay sits cleanly on top. read APIs are good, the data model is consistent, and the customisation surface in S/4 means the overlay can be additive without colliding with the existing config. If you are mid-rollout from ECC to S/4, an overlay can absorb the intake-and-quote workflows during the cutover quarter and take pressure off the parallel-run window.^[2]

F&O is well-architected for operations-layer overlay - the entity model is queryable, the workflow framework is configurable, and Microsoft's own integration story (Power Platform, Dataverse) overlaps with the operations layer in productive ways. The friction is shops that have carried heavy customisation through several versions; the overlay still works, but the integration design has to account for the customisation surface.

NetSuite is the easiest ERP we integrate with. REST APIs are coherent, SuiteScript is documented, and the data model is consistent across customers. The overlay does well here because the integration overhead is small and the finance-side reporting NetSuite already provides means the overlay does not need to duplicate it. Most NetSuite shops we work with adopt the overlay for procurement and intake and leave the rest of NetSuite untouched.

The frequent QB Enterprise pattern: the shop has outgrown the operational side of QB (no real BOM, no real MRP, no real WO management) but the finance side still works fine. The temptation is to do a full ERP migration. The overlay is usually the better answer. keep QB for finance, run the operational workflows (intake, RFQ, PO, planning) on the overlay against a read mirror of the QB data. The migration cost is avoided; the operational gap is closed.