Migration Is Translation

A system migration looks mechanical from far away. Export the data, clean the fields, load the new platform, and keep the business moving. The real work is usually quieter. You have to understand how the old system described the operation, where the record had drifted from reality, and what the new system will assume when it reads the same information.

That is why I think of migration as translation. The source language is not just NetSuite, Excel, or a proprietary platform. It is the way a team made decisions, worked around exceptions, named vendors, recorded purchases, and remembered the context that never fit cleanly into a field.

After the Compass Coffee division moved into Odeko, the useful question was not just whether the data could be moved. It was whether the moved data would still help people operate. Supplier records, purchase history, pricing discrepancies, inventory context, and workflow notes all had to be made legible enough that the next system could support the team instead of creating a new layer of doubt.

A clean migration starts by separating three things: what is known, what is wrong, and what is missing. Known data can move. Wrong data needs a correction path. Missing context needs an owner, because otherwise the new system inherits the old uncertainty and makes it look official.

The spreadsheet stage matters for that reason. It is not a downgrade from a real system. It is a working table where assumptions become visible before they harden into production records. You can see duplicate vendors, mismatched prices, odd descriptions, stale categories, and transactions that need a human explanation.

The goal is not to make the migration look clean on day one. The goal is to make the operation trustworthy on day two, day ten, and day thirty. A good migration does not just preserve records. It preserves the team's ability to make decisions from them.