A strong answer. “My default assumption is that consolidation is the wrong first move, because migrations of this size stall and you end up carrying both plus a half-finished migration, which is worse than either.

So the first question is why we have both. If it is an acquisition, or two org units that each chose correctly for their workload, then coexistence is a legitimate architecture and the work is to make it cheap rather than to end it. If it is drift with no owner, that is different.

What I would do regardless, and quickly: one storage layer in an open table format and one place where conformed entities are defined, with both engines reading it rather than each holding a copy. That removes the failure that actually costs us — two customer tables with two definitions of active, so every number depends on which engine you asked. Iceberg and Delta interoperability make that genuinely possible now.

Then attribution before optimisation, because I would expect that today nobody can say what each platform costs per team, which means nobody owns it.

Then, only if consolidation still looks right, I would fund the finish before starting — including the long tail, and with a decommission date I intend to hold. And I would be honest with the board that the saving is real but slower than the business case will claim, because these business cases always assume the last 30% happens.”