I've led or worked closely on three large enterprise platform migrations now: consolidating Dell and EMC's inventory and partner-management systems onto a single platform after the 2016 merger, migrating a decade of accumulated webMethods interfaces onto Oracle Fusion Middleware after a corporate spin-off, and — earlier in my career — supporting the day-to-day operation of a global B2B/EAI estate that had been migrated, patched, and re-migrated by several teams before I ever touched it.
Every one of these projects had a clean architecture diagram at kickoff. Every one of them also had at least one production incident caused by an integration that wasn't on that diagram. That's not a coincidence — it's close to a law of large enterprise systems, and understanding why changes how you should scope a migration from day one.
The diagram is a snapshot; the system is a decade
Large enterprise landscapes accumulate interfaces the way old houses accumulate load-bearing changes nobody documented. A finance team once built a nightly extract off a database table because it was faster than asking the platform team for an API. A partner integration was wired directly into a legacy queue because that's what existed in 2014. Someone left, the knowledge left with them, and the integration kept quietly running — until migration day, when it either breaks silently or breaks loudly in front of a customer.
The practical implication: discovery is not a phase you finish before migration starts — it's a parallel workstream that runs the entire length of the project. On the Dell-EMC consolidation, we budgeted real engineering time specifically to trace live traffic patterns and database access logs, not just to interview system owners, because the interviews alone consistently missed things. Log-based discovery found integrations that no one currently at the company remembered building.
Migrate behavior, not just code
The webMethods-to-Oracle Fusion Middleware migration is the clearest example I have of this. The instinct on a platform migration is to treat it as a translation exercise: take interface A on the old platform, rebuild it as interface A on the new platform, verify it produces the same output. That's necessary but not sufficient, because platforms differ in behavior that never shows up in the interface's happy-path documentation:
- Error-handling semantics. What happens on a malformed message, a downstream timeout, a duplicate delivery? Two platforms can implement the "same" interface with completely different failure behavior, and downstream systems have often been quietly built to depend on the old behavior.
- Ordering and concurrency guarantees. An interface that happened to process messages in order on the old platform, with no explicit ordering guarantee ever documented, will break a downstream consumer the moment the new platform processes them differently — even though nothing in the "spec" changed.
- Operational behavior under load. Retry policies, backoff, dead-letter handling — this is where migrations that pass every functional test still cause incidents in week two of production, when volume patterns exercise paths the test suite never hit.
Rebuilding the interface is the visible 80% of the work. Rebuilding — or deliberately choosing not to preserve — the undocumented behavioral contract is the 20% that determines whether the migration is actually safe.
Reconciliation is the real acceptance criteria
For any migration involving data consolidation — and the Dell-EMC inventory and partner-system consolidation was fundamentally a data consolidation problem wearing an integration-architecture costume — the acceptance criteria can't just be "the new system is live." It has to be "the new system's data reconciles against the old systems' combined data, within an explicitly agreed tolerance, for an explicitly agreed period."
That sounds obvious written down. In practice, teams under deadline pressure treat reconciliation as a nice-to-have validation step rather than the actual definition of done, and cut it short when the go-live date is fixed and the reconciliation isn't finished. I've found it's worth being stubborn about this one thing specifically: agree the reconciliation approach and tolerance before the migration starts, in writing, with the business owner — not after go-live, when "close enough" becomes a much harder conversation to have honestly.
Run parallel longer than feels efficient
Every migration plan I've seen underestimates how long to run the old and new systems in parallel, because parallel running feels like waste — you're paying to operate two systems that do the same thing. But the incidents that matter on a large migration are rarely in the first week. They're the monthly batch job that only runs on the last business day, the annual reconciliation process, the trading partner who only sends a particular message type twice a year. A parallel-run window measured in weeks will miss all of those. A parallel-run window measured across at least one full business cycle — including the awkward, rarely-exercised edge cases — is what actually de-risks a cutover.
The migrations that went smoothly weren't the ones with the cleanest target architecture. They were the ones where the team accepted, from the start, that the real system was bigger and stranger than the diagram — and budgeted discovery, behavioral parity, reconciliation, and parallel-run time accordingly.