When people map a data estate, they are diligent about two things. They map where the data comes from, and they map where it goes. The inputs and the outputs. The parts you can see.
What sits in between gets a single box on the diagram, usually labelled something reassuring like "processing" or "ETL". That box is where most of your migration risk lives, and it is the part almost nobody documents until they are forced to.
The Transform zone is where data is cleaned, joined, deduplicated, enriched and reshaped. It is where the business logic lives. Not the obvious logic that someone wrote down, but the accumulated decisions of years. The filter someone added to exclude test accounts. The join that quietly drops records with a null region. The currency conversion that assumes everything is in one timezone. The rule that treats a refund as a negative sale, except in the one case where it does not.
None of that is on the diagram. Most of it is not written down anywhere. It lives in the transformation code, and often in the head of whoever wrote it, who may well have left.
This is fine, right up until you migrate. The moment you rebuild the pipeline on a new platform, you have to recreate the transformation. And you cannot recreate what nobody documented. So one of two things happens. Either the migration stalls while someone reverse-engineers logic nobody understands, or, worse, the new pipeline runs, produces numbers that look plausible, and quietly gets them wrong because a rule got dropped in translation.
The second failure is the dangerous one. A migration that breaks loudly gets fixed. A migration that silently changes what the numbers mean can run for months before anyone notices the revenue figure drifted, and by then the trust is gone.
This is why I assess the Transform zone first and in the most detail. Not the inputs, which are usually documented by whoever provides them. Not the outputs, which the business already scrutinises. The transformation in the middle, because it is the part carrying the most undocumented assumptions and the most migration risk per line.
The discipline is simple to describe and tedious to do, which is exactly why it gets skipped. Every transformation gets documented as a defined step, with its inputs, its logic, and its reason, before anyone touches the migration. Not the code, the intent. Why does this filter exist. What is this join protecting against. What happens to a record that does not match.
Do that, and the migration becomes a rebuild of understood logic. Skip it, and the migration becomes an archaeology project with a deadline.
The inputs and outputs are where the attention goes. The Transform zone is where the risk is. Assess accordingly.