Habits that keep this easy
A few ways of working with Mochi that keep your configuration moving cleanly between environments.
Change configuration in one place
Pick one environment where configuration changes get made. A sandbox is the usual choice. Let Mochi carry them onward from there.
If the same item gets edited in two environments, one of those edits is going to be a surprise to somebody. Mochi spots the difference and stops rather than painting over it, but that's a conversation you'd rather not need to have.
Keep a change set to one piece of work
A change set moves as one thing, and it undoes as one thing. If you ever need to take a change back out, the whole change set goes with it. Five unrelated changes bundled together are awkward to unpick later.
Give each one a description that says what it's for. Months from now, that's what tells someone why a field looks the way it does.
Bring the whole thing, not just the piece that changed
When you pick items for a change set, Mochi collects what they depend on. What it can't do is include something you don't track and haven't chosen. If a category lists a field that isn't in your configuration and isn't already in the target, the delivery stops and names it.
It's quicker to bring the neighbours along the first time than to find out one at a time. When Mochi names something that's missing, add it and send again.
Track what your team looks after
Mochi watches the configuration items you choose, and nothing else. Some fields come with an Aprimo feature and are looked after by it rather than by your team, and a delivery carrying one of those will be held up each time.
If the same items come back run after run, stop tracking them. That changes only what Mochi watches, and stopping tracking an item never deletes anything in Aprimo.
Treat a rename as a change
Items are matched between environments by name. Rename something you track and it reads as the old one having gone and a new one having arrived, in every environment and in everything pointing at it.
So it's worth knowing that before you do it rather than after. Give a rename its own change set, with a description saying what it was called before.
Repair broken references before you move them
If a configuration item points at a field or category that isn't there any more, moving it carries that along. Mochi gathers these under broken references so you can put them right where the configuration lives, and then move a clean version.