A mapping is a CONTRACT between two schemas, expressed as expressions rather than code. That framing decides how you approach every one you build.
THE SHAPE OF THE TARGET DRIVES EVERYTHING. You are not transforming a source; you are FILLING a target, and the target's structure decides what questions you have to answer. Work target-first, element by element, asking of each: what fills this, and what happens when the source has nothing for it. Working source-first produces a mapping that transfers what happened to be there and leaves target elements nobody thought about.
MAPPING IS A DESIGN TASK BEFORE IT IS A BUILD TASK. The build is dragging; the design is deciding what each target element means, where its value comes from, what the default is, and which mismatches between the two schemas are real business questions rather than technical ones.
And there are always real business questions. The partner file has one address line and Fusion has four. The source has a status vocabulary nobody has mapped. Those are decisions for somebody who knows the business, and a consultant who resolves them silently in the mapper has made a policy decision inside an expression nobody will ever read.
So produce a written mapping specification before opening the mapper: target element, source, rule, and what happens when the source is absent. It is a table, it takes an hour, and it is what the client signs — and it is the artefact that survives when the integration is rebuilt three years from now.