The field was called CUST_CRED_LMT, and reading it out of the client's ERP was supposed to take an afternoon. The estimate said two days, because I'd been around long enough to pad. Six weeks later I was watching a nightly flat file land in a shared drive folder named DO_NOT_DELETE_FINAL_v3, and I felt genuinely proud of it. That's what this job does to a person.
What follows is an illustrative composite of a few engagements like this, and the ERP integration case study lessons it produced apply to every old system you'll ever touch. If you've ever integrated with an ERP old enough to vote, you'll recognize the smell.
The short version, because you've got your own ERP waiting: legacy ERP integration is slow because the documentation describes a system that no longer exists, the data hides behind exports designed in another century, and the real integration surface is one tired sysadmin. Budget accordingly.
Week one: the lie
Kickoff meetings about legacy systems always start optimistically. The client, a mid-size industrial supplier, wanted credit limits surfaced in their new quoting tool so reps would stop promising terms the ERP would reject. Sensible. Their IT contact emailed over the vendor's API documentation, and the PDF's metadata said 2009.
The documentation described an XML web service. The web service returned a 404. The vendor, when reached, explained that the module had been deprecated, then un-deprecated, then folded into a "gateway product" that costs more per year than my car. We declined the gateway product.
The archaeology begins
Production lived on a machine under a desk, administered by a man I'll call Dale, who had been there since before the Y2K remediation and regarded me with the patience of someone who has buried three consultants. Dale was the integration. Everything else was paperwork.
Week two was spent learning the export rituals. There was a reporting module that could produce customer master data, but only as a fixed-width text file, and only if you ran it from a specific terminal session, and it would silently truncate rows if someone else was printing at the same time. Tuesdays were bad, for reasons nobody remembered.
The validation effort dwarfed the extraction effort, which nobody warns you about. We spent eleven days pulling records we'd already extracted and checking them against what the business believed: calling the credit desk to confirm limits, reconciling sample accounts against signed contracts, discovering that one long-retired sales director had been approving overrides by sticky note. The export code took five days to write. Proving the export was telling the truth took more than twice that, and it was the part that made the quoting tool safe to switch on.
What the schema was hiding
It gets better: the credit limit existed in three places. There was CUST_CRED_LMT on the customer master, a second value on the billing terms table, and a third tucked into a notes field that sales had been using as an override since approximately 2011. Two of the three disagreed with reality on about a fifth of accounts. The notes field, naturally, was the one the reps actually trusted.
The workaround pyramid
What we shipped, in the end, was a pyramid of reasonable decisions that looks insane from above. A scheduled job on Dale's machine ran the export nightly. A parser translated the fixed-width file into CSV, applying the override rules we'd reverse-engineered from the notes field. A validation step compared all three sources and flagged mismatches for a human. The quoting tool read the result.
Fourteen intermediate formats, by my count. Zero APIs. It worked every single night, and when I checked in months later it was still working, because boring file-based integrations are the cockroaches of enterprise software: unloved and indestructible.
One more thing made it survivable: we wrote the whole pipeline down as we built it. Every export path, every override rule, every Tuesday caveat went into a runbook that lived next to the DO_NOT_DELETE folder. When Dale took his first real vacation in three years, his understudy ran the thing solo, and nobody paged anybody. That runbook was the least glamorous deliverable of the engagement and the one the client mentions most.
ERP integration case study lessons that generalize
First: find the human API before you write a line of code. Dale knew which exports lied, which days were bad, and which field names were traps. An hour with Dale was worth a week with the documentation. Buy the Dales of the world lunch early and often.
Second: triple your estimate for "just one field." The field is never one field; it's a field, two shadow copies, an undocumented override convention, and a printing conflict from 2007. This pattern shows up everywhere legacy systems live, from the supply-chain builds I described in my ninety days embedded with a logistics client to every manufacturing floor since.
Third: the vendor docs' publication date is a vibe, not a fact. The running system is the only specification that matters. Screenshot everything. Fourth: ship the ugly thing that works. The nightly flat file outlived two of my more elegant architectures, and I've made peace with that.
What I'd do differently
I'd run a data audit on day one instead of week three: pull the field from every place it appears and compare before promising anything. I'd also set expectations with a worst-case timeline up front, because "six weeks for one field" sounds absurd until you're living it, and then it sounds like Tuesday.
And I'd plan around the calendar. Kicking off a fragile extraction project right before a client's busiest month is how integrations get blamed for outages they didn't cause; the timing lessons in building during a client's peak season apply double when the source system is old and cranky.
The sequel nobody wants
The epilogue: the client now wants write-back, so the quoting tool can update credit holds. Writing into a 2003 ERP is reading's mean older sibling, and I've already warned them about the notes field. If you're staffing a project like this with a lone in-house admin, the dynamics of working alongside a one-person IT department will be familiar reading. Somewhere out there, Dale is smiling, and the flat file is still landing at 2 a.m. sharp.