Contact Us

← Back to blog

Five practical rules for integrating legacy ERP with .NET

By Eva Lin

Who this article is for

  • Operations / IT leadership: Deciding between big-bang ERP replacement and gradual .NET integration—and how to prioritize investment.
  • Architects / developers: .NET teams responsible for orders, inventory, production scheduling, and legacy ERP interfaces.

The problem

Manufacturing ERP systems often run for a decade or more, with deep customization and reporting tied to month-end close—a full replacement carries unacceptable downtime and migration risk. Meanwhile, e-commerce orders, custom quotes, and real-time stock lookups must ship. The common shortcut is dual writes: update the new system and patch the old ERP.

Dual writes may pass weekday tests, then fail at month-end, shipping peaks, or promotional windows: order states diverge, inventory is deducted twice, or a shipment exists in only one system. Staff reconcile by hand while IT answers “which system is wrong?”

Executive summary: Integration failures are rarely about .NET being “too old”—they come from unclear write ownership and boundaries. Define rules before code; it costs less than emergency fixes after go-live.

Rule one: single writer—avoid dual writes

Decision-makers care about: If two systems can change order status, nobody owns the final truth—audits and customer complaints do not converge.

Engineering focus:

  • Assign a single writing system per entity (order, inventory movement, shipment); others read or request changes through defined commands
  • .NET services that update ERP must use one integration channel (API, queue, or batch)—not parallel manual edits in two UIs
  • Document state machines (confirmed → scheduled → shipped) and which system triggers each transition

Common trap: Letting a new storefront write ERP tables directly for a “fast launch”—every ERP patch risks breaking the storefront.

Rule two: wrap legacy ERP with a .NET API layer

Decision-makers care about: Legacy touchpoints may be COM, stored procedures, or nightly files—baking those into every new module copies the debt forward.

Engineering focus:

  • Build an Integration API (ASP.NET Core): stable REST or gRPC inward, ERP mapping and validation outward
  • Centralize field mapping, unit conversion, and custom rules; new features depend only on the contract
  • Where ERP lacks real-time APIs, use queued polling and status write-back instead of cross-database writes
  • Version API contracts; validate mapping tables in staging before production cutover

Related work: Manufacturing ERP and order integration

Rule three: define clear system boundaries

Decision-makers care about: “Wire everything together” sounds integrated but turns every small change into a three-vendor negotiation.

Engineering focus:

  • Draw a boundary map: what stays in ERP (close, costing) vs. .NET (order capture, tracking, external APIs)
  • Cross boundaries only with validated DTOs or events—no shared DB connections or mystery staging tables
  • Document master data ownership: customer in ERP or CRM? Which item master wins?
  • Separate batch close from daytime order APIs—they should not share one connection pool
Boundary Suggested owner Why
Financial close, cost allocation ERP Compliance and existing reports
B2B/B2C orders, logistics tracking .NET services Faster change, external APIs
Inventory balance (authoritative) One designated system Prevents dual writes

Rule four: async and event-driven decoupling

Decision-makers care about: Synchronous ERP calls that time out during peaks stall the entire order path—lost revenue exceeds the integration budget.

Engineering focus:

  • Make order capture async: persist locally with outbox, background workers push to ERP
  • Use message buses for domain events (OrderCreated, StockReserved)
  • Implement outbox pattern so DB commits and event publish stay consistent
  • ERP write-backs notify downstream via events or webhooks—not every module polling the same table
  • Idempotency keys so retries do not duplicate shipments

Practical sequence: API for reads first; queued writes second; evaluate real-time bidirectional sync only when justified.

Rule five: observability—every integration is traceable

Decision-makers care about: When shipments slip, “the system is down” is not enough—you need to know ERP vs. network vs. new module.

Engineering focus:

  • Correlation / trace IDs from the storefront through ERP calls and queue messages
  • Log payload summaries, response codes, latency; mask sensitive fields
  • Dashboards for API error rates, queue depth, pauses during ERP maintenance
  • Daily reconciliation: .NET shipped vs. ERP posted counts; gaps open tickets automatically
  • Circuit breakers and degradation: when ERP is down, orders queue with a clear ETA

Pre-launch checklist

Item Pass criteria
Write ownership Documented single writer per entity
API contract Versioned with staging sign-off
Peak drill 2× order volume within SLA
Retries Idempotent backoff, dead-letter, manual playbooks
Reconciliation Automated compare with traceable gaps

Next steps

If you are planning new storefront or e-commerce without replacing ERP, start with a boundary workshop and single-writer rules, then scope the .NET integration layer. We have delivered manufacturing order, inventory, and e-commerce integrations—contact us through the site to discuss phased rollout.

Related articles