Most migration tooling treats a field as a boolean: it maps, or it doesn't. Mapped fields move. Unmapped fields are skipped, usually quietly, and you find out which was which weeks later when somebody goes looking for something.
Boolean is the wrong resolution. Between arrives intact and cannot exist here there are several genuinely different outcomes, and treating them as one outcome is how migrations lose data without anyone noticing.
So every field in a proposed mapping carries one of five labels.
01Fully supported
The target has a field of the same type that means the same thing. The value arrives, and reading it back gives you what you put in.
This is the only label that does not require a decision. Everything else stops and asks.
02Partially supported
The value arrives, but something about it is diminished. A field with a fixed set of allowed values maps onto a target set that is close but not identical. A precise timestamp lands somewhere that stores dates. Rich content lands somewhere that keeps the words and loses some of the formatting.
The distinction that matters: the information is still there and still useful, but it is no longer exactly what it was. Someone who knows what the field is for should decide whether the reduced version is acceptable, because that judgement depends on how the field is used, and the engine cannot know that.
03Supported through a workaround
The target has no native equivalent, but the value can be carried in something that isn't its natural home - folded into a description, held in a general-purpose property, appended to content as structured text.
This is the most dangerous label, which is why it is separate from the one above it rather than folded into it. Nothing is lost, so a report counting fields would call it a success. But the data is now somewhere it will not be found by anyone who doesn't know to look, and it will not behave the way the original did - it won't filter, sort, or drive automation. Accepting a workaround should be a deliberate choice with the destination stated, not a silently applied convenience.
04Impossible in the target
The target has no concept that could hold this, and no workaround that wouldn't be a lie. The field cannot come across.
This label exists to be stated plainly rather than avoided. Some loss is genuinely unavoidable - systems differ, and a migration that pretends otherwise is worse than one that admits it. What is avoidable is finding out afterwards. An impossible field is named, with the reason, before anything runs, and someone accepts it on the record.
05Needs a human decision
There is more than one defensible answer and no basis for preferring one automatically. Two target fields are equally plausible homes. A source concept splits into several target concepts, or several collapse into one. The right answer depends on how your organisation intends to work in the new system - which is a question about you, not about either product.
This is not the engine failing to decide. It is the engine declining to guess, which is a different thing and the correct behaviour.
Why the labels are the product
A migration that reports done is telling you about itself. A migration that reports these forty-one fields arrive intact, these six arrive diminished and here is how, these two go somewhere unnatural, this one cannot come at all, and these three need you to choose is telling you about your data.
The second one can be reviewed by someone who was not involved in building it. That is the whole point. The labels are what turn a migration from something you hope worked into something you can sign off.
Where they appear
The labels are assigned during schema discovery, when both systems have been read live and every source field has been matched against what the target actually offers. They are the substance of the coverage report you read before the run starts - and the run does not start while any field short of fully supported is still unanswered.
After the run, the same labels frame the verification pass. A field marked partially supported is expected to differ in a specific, predicted way; a discrepancy that matches the prediction is not a fault. One that doesn't is.
Loss is sometimes unavoidable. Silent loss is a choice, and we made the other one.