The proposal said implementation. It meant installation.

Six workstreams: data migration, integration, permissions and roles, process configuration, testing against real usage, and training with written handover. Proposals commonly quote it as one line, which is why it is commonly underquoted. The work that gets compressed is almost always testing and documentation, and both bills arrive later.

For business software it frequently exceeds the first-year licence, and for ERP it runs one to three times annual licence spend. The driver is data and integration complexity rather than headcount. We quote against a defined scope after mapping the process, because a number produced before that is a placeholder.

Configure first, in nearly every case. Configuration inside a system you already pay for is cheaper and stays supported when the vendor ships an update. Building earns its cost where the process is specific to how your business operates, no product covers it, and it runs often enough for the payback to be real.

A focused CRM or departmental rollout commonly runs four to ten weeks. A first custom workflow in production is usually six to twelve. Multi-module ERP is a different scale again, typically six to nine months across overlapping workstreams. The variable is data readiness far more often than engineering.

Yes, and it is a meaningful share of the work. The first deliverable is an honest assessment of what is salvageable, which occasionally concludes that continuing is cheaper than restarting and occasionally concludes the opposite. You get the assessment either way.

Frequently. Sitting on the client side of an implementation run by someone else is a real engagement shape: scope control, quality review, and someone in the room who is not paid more when the scope grows. We hold no partner agreements with any vendor, which is what makes that position credible.

Documented handover, written for how your business uses the system rather than the vendor's generic help centre. Support is available, but the goal is a team that can answer its own questions in a year without calling whoever ran the project.

You do. Custom work is delivered into your repositories and your infrastructure, with the documentation to go with it. A build you cannot maintain or move is a dependency, not an asset.

Usually, though the approach and the honesty about its limits matter. Some systems expose a decent API, some expose a file drop, and some expose neither and require a scheduled export. All three can work. What differs is how gracefully each fails, and that should be stated before anyone commits to it rather than discovered afterwards.

The process was never agreed before it was configured. Teams encode how management believes the work happens, the work goes on happening elsewhere, and within a year the system holds data nobody trusts. That is not a technical failure and no amount of engineering fixes it after the fact.