ERP Integration Services: Scope Before You Pay

Why scope ERP integration services first and quote second?

Scope first because an integration quote is only as accurate as the list of objects, directions and rules behind it. A price given before that list exists is a guess, and the guess gets corrected through change requests.

Viithiisys has shipped software since 2007 across 500+ projects, for clients including Paytm, Snapdeal, IKEA, Nestle, Shiprocket and Vikram Solar. The pattern repeats: the ERP itself is rarely the hard part. The hard part is the three systems around it that nobody documented.

What a quote built on guesses looks like

A vendor sees "connect ERP to Shopify and the warehouse system" and prices two integrations. The real list is orders, refunds, stock levels, price lists, tax codes, customer merges and shipment events, each with its own failure modes.

Count that list honestly and the "two integrations" become seven object types across two links, so up to fourteen flows once direction is considered. If the vendor priced for two, the other twelve arrive later as change requests, each one negotiated after the client has already committed to the vendor. That is how a modest quote ends up well above a properly scoped one.

What a scoped quote contains

A scoped quote names each system, each business object, each direction of flow and the volumes expected. It also states what happens when a message fails. That is the document a fixed scope can be written against.

How to map the data model before anything else

Start by listing every entity that crosses a system boundary and naming one system as owner of each. The mapping document, not the architecture diagram, is what prevents rework.

Build an entity inventory

For each object (customer, SKU, order, invoice, ledger entry), record the source system, the identifier each system uses and the fields that must travel. Include the awkward ones: units of measure, currency, tax treatment and status codes.

Most ERPs expose these through documented interfaces. Microsoft's Dynamics 365 finance and operations documentation, for example, describes OData access to data entities, which is the starting point for any ERP API integration on that platform.

A worked example shows why units matter. The ERP stores a product in cases of twelve, the warehouse system counts single units, and the storefront sells in packs of three. A stock level of "5" means sixty, five or fifteen depending on who reports it. Without a conversion rule written into the inventory, the storefront oversells or the warehouse under-ships, and nobody can say which system is wrong.

Find the identifier problem early

The same customer is often "C-10442" in the ERP, an email address in the CRM and a numeric ID in the storefront. Decide on a cross-reference table before building anything. If two systems disagree about who a customer is, no amount of middleware fixes it.

Where the source data is dirty, that is a data engineering task in its own right, and it should be estimated separately from the integration build.

Point-to-point vs middleware vs iPaaS: which fits?

Point-to-point wins for two or three stable connections, middleware wins when many systems share the same objects, and iPaaS wins when speed matters and volumes are moderate. Choose per connection, not per company.

When middleware earns its place

Middleware for ERP integration pays back when the same order or customer must reach several consumers. Publishing one canonical message and letting each consumer translate it avoids rewriting the ERP side every time. Microsoft's anti-corruption layer pattern describes exactly this translation boundary.

The arithmetic is simple. With four systems wired point-to-point, you can end up maintaining up to six links, and each added system multiplies that. Through a hub, four systems need four connections and a fifth needs one more. The crossover usually arrives around the fourth or fifth system.

When it does not

If you have two systems and a team that will never add a third, a hub is a second thing to patch and monitor. Be honest about the roadmap before choosing.

Sync direction, conflict rules, idempotency

Decide, for every field, which system wins, whether data flows one way or both, and what happens when the same message arrives twice. These three decisions cause more production incidents than any technology choice.

One-way, two-way and who owns the field

One-way flows are cheap to build and easy to reason about. Two-way sync needs a rule for every field that can be edited in both places: last write wins, source of truth wins, or a human resolves it. Write the rule per field, not per object.

For example, a customer's shipping address might be editable in both the storefront and the ERP. "Last write wins" looks fine until a clerk fixes a typo in the ERP at 09:00 and a stale storefront sync overwrites it at 09:05. A safer rule is that the storefront owns addresses and the ERP receives them, with edits in the ERP blocked or routed back.

Idempotency and retries

Networks fail, so messages get sent twice. An idempotent operation produces the same result however many times it runs. The HTTP standard defines which methods are idempotent, and Stripe's documentation on idempotency keys shows the practical pattern: a client-supplied key that lets the receiver discard duplicates.

Partial failure

An order that posts to the ERP but fails to reach the warehouse leaves two systems disagreeing. Microsoft documents the compensating transaction pattern for undoing the first step. Decide upfront whether you compensate, retry or queue for manual review.

What does ERP integration cost by integration count?

Cost follows the complexity of each integration, not the headline count. Two connections with heavy transformation and two-way sync can cost more than eight simple one-way feeds. Count objects, directions and exceptions instead.

No credible public benchmark exists that converts integration count into effort across ERP platforms, so this article does not quote one. Published figures tend to come from vendors selling the tooling, and they rarely say what was included. Treat any single number for ERP integration cost with suspicion.

The drivers that move the estimate

• Objects per connection. Orders alone are simple; orders plus returns, partial shipments and tax adjustments are not.
• Direction. Two-way sync roughly doubles the rules to design and test.
• Data quality. Cleansing and de-duplication sit outside the integration but block it.
• Customisation in the ERP. Heavily modified ERPs have undocumented behaviour.
• Volume and latency. Batch overnight is far cheaper than near-real-time.

Ongoing costs buyers forget

Monitoring, credential rotation, vendor API version changes and licence fees for middleware recur after launch. Ask for them in writing. At Viithiisys, engagements are scoped per project after a discovery call, and a fixed scope only exists once these drivers are listed.

What UAT plan prevents a failed go-live?

A UAT plan that uses production-shaped data, tests failure paths as well as happy paths, and names a business owner who signs off each flow. Without those three, user acceptance testing becomes a demo.

Test with real shapes of data

Sanitised copies of last quarter's orders expose problems that ten hand-made test records never will: long addresses, zero-quantity lines, discontinued SKUs, special characters. Use volumes close to peak, not average.

Test the failure paths on purpose

Switch off the receiving system mid-batch. Send the same message twice. Change a price in both systems at once. Each should end in a state the business can explain. A proper QA and testing pass covers these cases deliberately instead of hoping they appear.

Plan the cutover and the rollback

Decide how many days of parallel running you need, who reconciles totals each morning and what triggers a rollback. A go-live without a rollback criterion is a bet. Where the ERP itself is being replaced, the system modernisation sequence matters as much as the integrations.

A concrete rollback trigger might read: if the morning reconciliation shows order totals differing by more than a set tolerance between ERP and storefront for two consecutive days, the integration is switched off and orders are keyed manually until the cause is fixed. Agreeing that number before launch removes the argument from the worst possible moment.

Our free scoping template for ERP integration services

The template is a worksheet that captures systems, objects, direction, owner, volume, failure behaviour and acceptance test for every connection. Completed, it becomes the written scope a fixed-price proposal can be built on.

What it asks you

For each integration it asks: which object, which system owns it, which way does it flow, how many records per day, what happens on failure and who signs off. It also asks what the ERP customisations are, because those are the surprises.

Who it is for

CTOs and heads of engineering comparing proposals will find that vendors who see the same sheet quote against the same facts. That makes quotes comparable, which is the point. Our enterprise software team works from this sheet in discovery, with engineering based in Mohali and an office in Markham, Ontario.

If you would rather have someone else read the result, the broken workflow assessment is the fastest way to get the template and a second opinion on your integration scope. You can also see delivered work first.