What a Simple Data Migration Usually Hides

"Move our inventory records from the old system to the new one." As requests go, it sounds like a weekend of work. The data is right there. The new platform is waiting.

A multi-location dealership group brought us exactly that request: retire an aging on-premise dealer management system and move inventory to a modern cloud platform. Straightforward, by every appearance.

The scoping work said otherwise. System and log audits, run in Blueprint alongside stakeholder interviews, found seven downstream systems reading from the legacy inventory tables. Finance reconciliation. Compliance reporting. Incentive claims. Others. None documented during the original implementation or at any point since. Every one of them would have gone quietly wrong the day the tables moved.

The data held a second trap. One status code carried different meanings depending on which location had entered it. Migrate it literally and the new platform inherits a field that lies, location by location, in ways nobody catches until the reports stop reconciling.

So the build changed shape before it began: a mapping layer to resolve the code by source location, and a phased cutover so each dependent system moved deliberately instead of breaking silently. The client shipped without disruption, and by their own estimate, the incentive claims process alone would have bled tens of thousands of dollars a month had the dependencies surfaced after cutover instead of before.

The pattern repeats everywhere: the systems most likely to have undocumented dependencies are the oldest ones, and the oldest ones are exactly the ones being retired. Nobody knows what reads from a twenty-year-old table, because everyone who built against it has moved on.

The question to ask before any migration: what reads from this system that nobody has written down? If the honest answer is "we're not sure," that is not a reason to delay the project. It is the first item in scoping it properly.