The easy 80% of any migration is well served. This is a series about the other 20% - the custom fields, cross-references, parent-child structure and attachments that get quietly dropped, and what it takes to carry them across.
A migration engine in which a new source-to-target pair is a description rather than a codebase. What the product does - schema discovery, coverage before it runs, reference resolution, resumable execution, self-verification - and what it deliberately doesn't.
Start to finish, in the order you'd experience it: connecting both systems, discovering the schemas, reviewing the coverage report, confirming the lossy fields, and what “dependency waves” means when you're watching one run.
If every source-to-target pair is its own codebase, the cost of a catalogue multiplies and the hard parts never get funded. What changes when a pair is a description instead - and what still isn't free.
Fully supported, partially supported, supported via a workaround, impossible in the target, or needing a human decision. Why every mapping carries one of these labels, and why anything short of the first one stops and asks.