An ERP integration is not a CRM project with an extra system attached. The ERP refuses documents that break its rules, production data has consequences, and the expensive mistakes are made in week one and discovered at cutover. This is the six-phase model Twopir Consulting runs, what has to be true before phase one, and what each phase produces. Including the prerequisites that most often delay go-live.
Trusted by 500+ organizations — including distributors, manufacturers and field-service businesses running HubSpot in front of an ERP with Twopir Consulting.
Implementation Coverage
Almost never in the code. These six are the real causes of a slipped go-live, and five of them are decided before anybody writes a line of integration logic.
The Service Layer is not enabled, the integration user does not exist, or nobody has authorised network access. Work begins anyway, and the first four weeks are spent waiting on an IT ticket that should have been raised in scoping.
Without a test company database that resembles production, every flow is proven against either toy data or live data. The first tells you nothing; the second creates real documents you then have to unwind.
Whether an order is created at Closed Won or at a later stage, who owns pricing, which warehouse is chosen — these need a decision-maker. Without one named, the project stalls in design and the delay is blamed on the build.
Duplicate companies, missing tax IDs, items with no usable code. Every one of these becomes an integration error, and cleaning them during user acceptance testing is the slowest possible moment to do it.
Everything is turned on at once on a Monday. In-flight deals, part-processed orders and records that exist in one system but not the other all surface simultaneously, with nobody agreed on what should happen to them.
The team moves on the day it launches. The first genuinely unusual transaction arrives in week three, fails silently, and nobody is watching the queue it failed into.
Two constraints shape everything about how an ERP integration is delivered. Both of them argue for the same thing: do the unglamorous work first.
A SAP Business One HubSpot implementation is the project that takes an agreed integration design and makes it a running service: environment validation, mapping and rules, build against a test company, user acceptance testing, cutover and hypercare. It is distinct from choosing an integration route, and distinct again from owning the integration afterwards.
The defining constraint is that one of the two systems keeps the accounts. SAP Business One will reject a sales order whose item does not exist, whose business partner is blocked, or whose tax code does not apply — and it is correct to. A CRM project can usually fix bad data after the fact; an ERP integration cannot, because the document either posted or it did not. That is why everything here is proven in a test company before production is touched.
The second constraint is that the prerequisites are mostly not ours to deliver. Service Layer availability, licensing, an integration user, authorised network access and a usable test company all sit with your IT team or your SAP partner. Published below deliberately: in our experience these, not the build, are the most common reason a go-live date moves.
Durations are indicative planning ranges for scoping, not commitments — your own are agreed after phase two. Every phase produces something you can hold, which is how you tell whether it finished.
The process as it actually runs, workarounds included.
What your SAP Business One exposes, and what has to be arranged.
Objects, fields, values and the business rules, signed off.
Built against the test company, failure paths exercised.
Your people test real scenarios; then a timed cutover rehearsal.
Controlled go-live, reconciliation, watched period, handover.
Published in full, because the middle column — what we need from you — is the part that determines whether the right-hand column arrives on time.
| Phase | What happens | What we need from you | What it produces |
|---|---|---|---|
| 1 · Discovery | Current-state process walkthrough, including the workarounds. Every point where a person moves data between the two systems. | Process owners for 2–3 sessions; access to how orders are actually raised today. | Current-state map and a prioritised flow list. |
| 2 · Environment validation | What your installed SAP Business One actually exposes: version, localization, Service Layer availability, licensing, network path, integration user. | IT or SAP partner availability; a test company database. | Technical feasibility note and the route decision. |
| 3 · Mapping and rules | Object, field and value mapping. The business rules: creation trigger, pricing owner, matching logic, failure behaviour, replay authority. | A named decision-maker who can settle rules in the room. | Signed mapping and rules document — the build contract. |
| 4 · Build and unit test | The integration built against the test company. Error, retry and replay behaviour exercised deliberately rather than discovered. | SAP-side changes applied: user-defined fields, permissions, document settings. | Working flows in the test environment, with a test log. |
| 5 · UAT and dry run | Your people run real scenarios end to end. Then a full cutover rehearsal against the test company, timed. | Business users for scenario testing; agreed acceptance criteria. | Signed-off scenarios and a timed cutover plan. |
| 6 · Cutover and hypercare | Controlled go-live, first live documents reconciled one by one, then a watched period before handover. | An agreed change freeze window and someone available on the day. | Running service, runbook, and a named owner. |
Scroll the table sideways to see every column
Most of these are not ours to deliver. They are, in our experience, the most common reason a go-live date moves — so they are published here rather than buried in a statement of work, and you can start them today.
| Prerequisite | Owner | Why it matters | If it is late |
|---|---|---|---|
| SAP B1 Service Layer enabled and reachable | Your IT or SAP partner | It is the REST interface the integration talks to. Where it cannot be exposed, the DI API on an in-network host is the fallback — which changes the infrastructure and the cost. | Blocks phase 4 |
| Network access authorised | Your IT | An on-premise Service Layer is typically reachable only from specific, agreed addresses. The authorisation is a ticket in someone else's queue, so it belongs in week one. | Blocks phase 4 |
| Integration user and licence | Your SAP partner | A dedicated user with exactly the permissions the mapping needs — not a person's named account, which breaks the first time they leave. | Blocks phase 4 |
| Test company database | Your SAP partner | A company database that resembles production in configuration and data shape. Proving flows against toy data proves nothing. | Blocks phase 4 |
| A named business-rule decision-maker | You | Someone who can settle when an order is created, who owns pricing and what happens on rejection — in the room, not by email over three weeks. | Blocks phase 3 |
| HubSpot super admin access | You | To create the private app, properties, custom objects and pipelines the mapping requires. | Blocks phase 4 |
| Data state understood | Joint | Duplicate companies, missing tax IDs, items without usable codes. Identified in phase 1 so cleanup runs in parallel rather than during UAT. | Slows phase 5 |
| Agreed success criteria | You | What “working” means, in scenarios rather than adjectives. This is what phase 5 tests against. | Slows phase 5 |
Scroll the table sideways to see every column
Durations run from a signed mapping document, not from the first call. Treat them as planning ranges for a scoping conversation; the committed dates come after environment validation.
| Scope | What it covers | Indicative duration | What moves it |
|---|---|---|---|
| Single flow, standard objects | Won deal to sales order, with business partner and item resolution. No custom objects. | Roughly 4–6 weeks from signed mapping | Environment readiness; whether items and customers already reconcile. |
| Order-to-cash, both directions | The above plus delivery, invoice and payment status returning to HubSpot, and an inventory or price feed outward. | Roughly 8–12 weeks from signed mapping | Data cleanup volume; how many pricing and tax rules are genuinely non-standard. |
| Multi-company or multi-entity | Several SAP Business One company databases, or several currencies and localizations, behind one HubSpot portal. | Roughly 12–20 weeks from signed mapping | Per-entity rule differences; whether one HubSpot portal should serve all of them. |
| Rescue of an existing integration | Assessment, then remediation of what is failing, keeping whatever is working. | Assessment roughly 2–3 weeks; remediation depends on findings | How much of the original design was documented at all. |
Scroll the table sideways to see every column
Design that is specific enough to argue with, delivery that never touches production untested, and a cutover rehearsed against a clock.
The mapping and rules document is written before anybody builds, and it is specific enough to argue with.
Every flow is proven against a SAP Business One test company before production is touched, including the paths that fail.
Go-live as a planned sequence with a decision point at each step, not a switch thrown on a Monday morning.
Cutover problems are almost always decisions that were deferred. These four are the ones worth settling in the dry run.
Configuration, localization and data shape close enough that a flow proven there will behave the same live. This is the single highest-value prerequisite.
Deals mid-pipeline at cutover, orders part-processed, records in one system only. Decided in the dry run rather than improvised on the day.
The first orders through are checked individually against SAP Business One. A count-level check comes later; document-level is what catches a mapping error.
A watched period after go-live where somebody specific reads the error queue daily. Handover happens after that, not instead of it.
These are delivery practices, not client metrics — we publish numbers only where a specific engagement has measured them. The case study beside them is real and linked.
Service Layer availability, licensing, the integration user and the network path are confirmed before design starts, because every one of them is somebody else's ticket.
Including the failure paths: a rejected document, a timeout mid-create, an item that does not resolve. Production sees nothing that has not already failed safely in test.
The full sequence run against the test company and timed, so the go-live window is based on a measurement rather than an estimate.
Hypercare with daily queue review and document-level reconciliation, and handover only once the runbook has been used by the people who will own it.
A quote-to-order process delivered across CPQ and the systems around it. Different platform pair, the same delivery discipline: design signed off first, built and tested away from production, cut over in a controlled sequence.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. An ERP cutover is the point where a project stops being reversible, which is why it earns a rehearsal.
Phase two exists because designing against an assumed Service Layer, and discovering in week six that it was never enabled, is the most expensive ordering mistake in this kind of project.
Every flow, including the failure paths, is proven against a SAP Business One test company. An ERP document either posted or it did not; there is no fixing it afterwards the way a CRM field can be fixed.
The items on your side of the line are listed above rather than buried in a statement of work, because they are the most common reason a date moves and you can start them today.
The go-live window comes from a measured dry run against the test company, not from an optimistic estimate made in a planning meeting.
A watched period with a named owner, then handover once the runbook has actually been used. We help growing and mid-market companies solve complex CRM, integration, and business system challenges.
Timeline, prerequisites, data cleanup and cutover — the four that shape the plan.
The indicative ranges in the table above start from a signed mapping document, not from the first call: roughly four to six weeks for a single standard flow, eight to twelve for order-to-cash in both directions, and twelve to twenty where multiple company databases or localizations are involved.
Those are planning ranges for scoping conversations, not commitments — your own timeline is agreed after phase two, once we know what your environment actually exposes. The variables that move them most are environment readiness and the volume of data cleanup, and both are largely on your side of the line.
The Service Layer enabled, licensed and reachable from the agreed addresses; a dedicated integration user with the permissions the mapping needs; a test company database that resembles production; and HubSpot super admin access.
Also a named person who can decide business rules in a session rather than by email over three weeks. The full checklist is in the prerequisites table above, with who owns each item and which phase it blocks.
Because an ERP document either posted or it did not. If a mapping error creates a sales order against the wrong business partner in production, that is a real document with real accounting consequences, and unwinding it is manual work for somebody in finance.
A test company that resembles production lets us exercise the failure paths deliberately — rejected documents, timeouts mid-create, items that do not resolve — so the first time any of those happens live, the behaviour is already known and correct.
That is a business decision made during the dry run, and it needs to be made explicitly. The usual options are to let existing deals finish under the old manual process and apply the integration only to new ones, or to migrate in-flight deals with a one-off reconciliation.
Either works. What does not work is leaving it undecided until the morning of cutover, when in-flight deals, part-processed orders and one-sided records all surface at once.
Usually some of it, and the point of identifying it in phase one is so cleanup runs in parallel with the build rather than blocking user acceptance testing.
The items that matter most are duplicate companies, missing or inconsistent tax IDs, and products without a code that maps reliably to a SAP ItemCode. Name matching is not a substitute: it breaks the first time someone types the legal entity name instead of the trading name.
Yes, and it is common. We specify exactly what is needed on the SAP side — user-defined fields, integration user permissions, document settings — and they apply it on their schedule.
The coordination risk is real, though, so those dependencies are named in the prerequisites with the phase they block. A SAP-side change that arrives in week six instead of week two moves the build, and everyone should be able to see that coming.
Daily review of the integration error queue, document-level reconciliation of the first live transactions, and immediate remediation of anything the live environment surfaces that test did not. Typically one to two weeks, longer where transaction volumes are low enough that unusual cases take a while to appear.
Handover happens after hypercare, once the people who will own the integration have actually used the runbook. Whether that is your team or ours is decided on the services page.
Four companion pages. This one covers how the project runs; the others cover the architecture, the data model and the custom work.
Bring your target date and your current environment. We will tell you which prerequisites are likely to move it, what a realistic phase one looks like, and where in the six phases your project actually is.
Talk to a team that has cut over CRM to ERP integrations before
