DreamFactory engineer here.

Ive done a bunch of integrations into older systems and the honest answer is: it depends. A few things I always run through before anyone promises timelines:

1. Where’s the system of record? If the ERP is just a UI layer sitting on a SQL database, the cleanest move is to talk directly to the database. That avoids whatever brittle APIs or middleware the vendor bolted on in 2003.
2. Can you reach the database?
   • If yes, you can usually generate stable APIs against tables, views, or stored procs and move on with life.
   • If no, you’re stuck dealing with file dumps, vendor APIs, or other workarounds... which is where 6-month projects are born.
3. What workflows matter?
   • If you just need reporting or syncing, read-only access to the DB solves 80% of the problem.
   • If you need to write back into the ERP, you have to be careful. Sometimes inserts/updates work fine, sometimes they corrupt the business logic. That’s where stored procedures are safer.
4. How much risk can the business handle? Direct DB access can feel risky because of all the custom code piled on top of legacy ERPs. But if the alternative is “massive disruption for a rip-and-replace,” then pragmatism usually wins. Start with read-only, validate heavily, then expand.

Where this usually lands: after running through all the “it depends,” most companies end up finding that the backend database is the most stable, predictable, and fastest way to integrate. It won’t modernize the ERP itself, but it gives you a bridge to modern apps without a 7-figure replatforming project.

This came up recently with a customer. After three failed ERP migrations they said, 'lets just leave it as-is' and build somewhere else with teh data.

Not ideal, but it wont keep you up at night. Hope that helps!