Ninety Days to Unify Five Legacy Systems: A Sequencing Note

The first plan someone drew up for this project — five siloed platforms, a WMS, a TMS, separate procurement, order management, and customer tracking systems, all needing to talk to each other — was the technically tidy version: design the target-state unified data model first, then migrate each system into it one at a time. It looked good on a slide. We killed it in the first planning meeting, mostly because someone asked the obvious question: what does the operations team see in week four? The honest answer, under that plan, was nothing. A design document. That's not something you can hand someone who's currently reconciling inventory across three spreadsheets by hand every morning.

So we flipped it. Instead of designing the general model first, we picked the single question that was costing the most manual reconciliation time right then — what's our actual current inventory position, across warehouse and in-transit, without someone pulling three reports and cross-checking them — and built only the pipe that answered that one question. Two weeks, not six. It wasn't elegant. It didn't generalize to the other four questions we knew were coming. It also meant that by week two, someone in operations had a number they trusted and used every morning instead of a spreadsheet, and that changed the tone of every conversation after it, because the project stopped being a promise and started being a thing people were already relying on.

What surprised us was how much of the "real" unified model got built anyway, just not as a planned deliverable — it emerged as a byproduct of answering the next few questions in sequence, because cost-to-serve and exception handling turned out to share most of their underlying entities with the inventory question we'd already solved. By week six we had something that looked a lot like the original tidy design document, except every piece of it had already been used by someone before it was considered "done," which is a very different kind of validated than a design that's only been reviewed on paper.

The part we almost got wrong was putting the reconciled view somewhere people would actually use it during a live exception, not just in a report. Our first pass shipped it as a dashboard, and for about two weeks usage was disappointing — people were still falling back to old habits during actual disruptions, because checking a dashboard mid-crisis wasn't yet a reflex. We had to go sit with the ops team during a live exception to see why, and the answer was almost embarrassingly simple: the dashboard didn't show the one thing they needed in that exact moment, which was slightly different from what it showed on a calm day. We rebuilt the exception view specifically around that, and usage during real disruptions is where it finally stuck.

By week thirteen, when we sat down to plan the next quarter, the actual usage data told a different story than our original scoping conversation had — a smaller, more specific list of what people opened daily than the wishlist we'd started with. We built against that instead of the wishlist, which is probably the single decision from this project I'd repeat first if we started over.