I recently moved a large set of business-critical metrics off a Power BI semantic model and onto a cloud data warehouse. The model had outgrown the tool. People wanted to connect to the numbers from more than just a Power BI report, and the semantic layer had become the bottleneck for everything else they wanted to do.
I architected both ends. The original model was mine. The destination warehouse was mine. Same person, same definitions, same intent, both sides of the move.
The numbers still didn’t match.
Not wildly. Not in a way that broke anything obvious. But when I put the old figures next to the new ones, they did not reconcile cleanly, and these were numbers leadership watched closely. “Close enough” was not an acceptable answer for them, and it should not have been.
So I did the unglamorous work. I went metric by metric and found where each difference came from. A measure that resolved one way inside the semantic model’s engine resolved slightly differently in SQL. A default that the BI tool applied silently had to be made explicit in the warehouse. A filter context that Power BI handled implicitly had to be written out by hand, and the act of writing it out exposed an assumption I did not know the original model was making.
None of these were bugs, exactly. They were the consequence of two systems computing the same idea through different machinery. The machinery leaks into the number. It always does.
Here is the part I want operators and the people who answer to executives to sit with.
I built both systems. I knew every definition. I had every advantage a person could have going into a reconciliation, and it was still intense. I still had to document the differences in plain language and explain them in a way that was acceptable to leadership, because the people relying on these numbers needed to trust that the new figure meant the same thing the old figure meant.
If the architect of both ends has to do that work, what happens during a migration where nobody built either end?
That is the situation almost every manufacturer is walking into right now with Epicor on prem to Kinetic Cloud. A migration vendor moves the data. They confirm it loaded successfully, which is true and worth confirming. Then they leave. Nobody on that project built the old calculation logic, nobody is responsible for the new calculation logic, and the question of whether your most watched operational metric still means the same thing it meant last quarter is simply nobody’s job.
The number looks fine. It populates. It charts. It sits in the leadership deck exactly where it always sat. And underneath it, the machinery changed, and no one checked whether the machinery still produces the same answer.
“Loaded successfully” is a statement about rows. It is not a statement about meaning.
The two are easy to conflate because the data is right there and it looks right. But a metric is not its rows. A metric is a definition computed over those rows, and the computation lives in the system, not in the data. Move the system and you have quietly moved the computation, whether you meant to or not.
The metrics most exposed to this are the calculated ones, the ratios, anything with a denominator. A simple count tends to survive a move. OEE, on time percentage, scrap rate, utilization, anything where the answer depends on how both the top and the bottom of the fraction get derived, those are the ones where the machinery change shows up. And because the single number stuff around them looks fine, the ratio drift hides in plain sight.
What I learned reconciling my own migration is that the deliverable is not “they match.” That is rarely true on day one, even under ideal conditions. The deliverable is a documented, defensible account of where they differ and why, written so the people who depend on the number can decide whether the difference is acceptable.
That is the actual work. Not asserting that everything is fine. Establishing what each metric truly means, to a recognized standard, and proving, in writing that an executive will accept, whether it survived the move.
I do that work as an independent third party now, because the one thing I could not give my own migration was independence. I was the architect. I had to certify my own homework. The whole value of an outside check is that it is outside, and that is the one thing the person who built the system structurally cannot provide about their own work.
If you are heading into a Kinetic migration and your most watched numbers need to still mean what they meant, that is the conversation I am set up to have.