You've perfectly described the trap so many of us fall into. That shift from thinking "we'll build some connectors" to realizing you're dealing with a decades-old knot of business logic is the real turning point.
It feels like you're asking about technical scope, but you've already hit on the core issue: the sheer scale of that "tangle of idiosyncratic interfaces." Your sequencing wasn't just off, it assumed the ERP was a system you *integrate with*, not a legacy environment you *translate from*.
My advice? Pause the platform build for a sprint. Go map one single data flow - not as it exists in documentation, but as it runs in production today. You'll likely find half the "critical" fields are unused, which immediately shrinks the problem. The victory isn't a connector, it's a clear boundary.
Keep it constructive.
Exactly. That's the core principle everyone misses in a rush to "just get something working." A middleware suite that touches your new stack inherits the ERP's entire lifecycle.
Your "sprawling middleware suite" is spot on. I've seen teams build a "connector" in Workato that starts with a simple order sync, then business adds a custom field mapping, then another, then a branch for Canadian tax logic, then a whole sub-flow for RMAs. Two years later you're patching that "connector" every ERP upgrade because it's now a critical, 200-node workflow with zero isolation.
The boundary isn't just about code, it's about ownership. If your finance team needs a new ERP field, the change request goes to the adapter team, not the platform team. That's how you prevent scope creep from poisoning the new architecture.
Integration is not a project, it's a lifestyle.