The brief sounds simple: the client changed the character, so move the animation onto the new rig. Then you open both files and discover the new rig names its controls differently, parents the arms under a different node, and uses a rotation order nobody documented. The "quick" transfer eats your afternoon.

Copying animation between rigs is one of those tasks that is trivial when the two rigs match and genuinely difficult when they do not. Knowing which situation you are in before you start is most of the battle.

Why the transfer usually fails

Four things break animation transfers, and they are almost always structural rather than artistic:

  • Different control names. L_arm_ctrl on one rig and arm_l_CTRL on the other means nothing matches automatically. Every tool that transfers by name stops here.
  • Different hierarchies. If a control sits under a different parent, the same local values produce a different world result. The pose looks right in the channel box and wrong in the viewport.
  • Mismatched rotation orders. Identical rotation values in XYZ and ZXY are not the same rotation. This is the source of most mysterious flipping after a transfer.
  • Different proportions. Longer arms or a taller spine mean translation values that were correct on the source rig now over- or under-reach on the target.

Notice that only the last one is really about the character. The first three are naming and setup problems, which is why they are solvable in a repeatable way.

The order that actually works

  1. Compare the two control sets first. Before transferring anything, list the controls on both rigs and see how many names match exactly. That number tells you whether this is a five-minute job or a mapping job.
  2. Build a mapping for the names that differ. Source control to target control, once. Every subsequent transfer between these two rigs reuses it.
  3. Check rotation orders on the main limbs. Shoulders, wrists, hips, ankles. If they differ, fix the target to match the source before transferring rather than debugging flips afterwards.
  4. Transfer rotations first, translations second. Rotations usually carry over cleanly regardless of proportion. Translations are the ones that need scaling when the characters are different sizes.
  5. Fix contacts by hand. Feet sliding, hands passing through props, hips floating — these need an animator, not a script. Budget time for it.
  6. Clean the curves. A transfer often leaves redundant keys and small noise. A cleanup pass keeps the graph editor workable, as covered in cleaning animation curves in Maya.

The Maya commands that do the copying

Maya has two built-in ways to move keys from one rig's controls to another's.

Copy and paste keys. For a handful of controls: select the source control, choose Key → Copy in the Animation menu set, select the matching target control and choose Key → Paste. The paste options decide where the keys land in time and whether they replace what is there. It is one control at a time, which is why it only suits small fixes.

ATOM files. For a whole character, Maya's ATOM format saves the animation to a file and loads it onto another hierarchy:

  1. Select the source controls and choose File → ATOM → Export Animation. The options let you include baked animation, static values and animation layers, and set the time range.
  2. Open or switch to the target rig, select its controls in the same order, and choose File → ATOM → Import Animation.
  3. Set the Match Method. Hierarchy matches by position in the hierarchy. String matches by name and gives you Search and Replace and prefix/suffix fields, which is the fix when the rigs differ by a naming pattern such as L_arm versus arm_L. Map File takes an explicit source-to-target list for rigs whose names have nothing in common.

Autodesk documents both halves: Export .atom animation and Import .atom animation. A map file is the saved mapping the next section keeps coming back to: build it once and every later transfer between those two rigs reuses it.

To check a control's rotation order before transferring, select it and look at Rotate Order under Transform Attributes in the Attribute Editor.

Should you bake first? Only if you must. Baking flattens the curves into a key on every frame, which transfers reliably but is painful to edit afterwards. Transfer the keys themselves when the rigs allow it.

Copying versus retargeting — not the same job

It is worth separating two things people call by the same name:

Copying moves keys between rigs that share a similar structure. The controls correspond, so the work is mapping names and matching rotation orders.

Retargeting moves motion between fundamentally different skeletons — most commonly library motion capture onto a production rig. That needs a skeleton mapping and usually some re-proportioning, which is a different process; we walk through that case in getting Mixamo animation into Maya.

Using a copy workflow on a retarget problem is why some transfers produce a character that looks broadly right but wrong in every joint.

Doing it repeatedly without losing your afternoon

If you transfer between the same two rigs regularly — a hero and a stand-in, a game rig and a cinematic rig — the mapping is worth saving rather than rebuilding. With ATOM that means keeping the map file or the search-and-replace strings next to the rigs. That is the difference between a task you dread and a menu item.

Where AnimKit fits, and where it does not

Disclosure: AnimKit is my own paid Maya toolkit, so here is exactly what it does for this job.

Its Constraints tab has Export Anim and Import Anim. Export writes the keys and tangents of the selected controls to a JSON file. Import reads that file and sets the keys on controls with the same names, skipping any it cannot find and telling you how many it skipped. That covers the common easy case: the same rig in another scene, or an updated version of a rig whose control names did not change.

It does not remap names. For two rigs that name their controls differently, use ATOM's String or Map File matching above. For motion from a different skeleton, such as Mixamo, AnimKit's Retarget tab is the right tool, and that is retargeting, not copying.

If you reuse individual poses across shots rather than whole performances, that belongs in a pose library instead — the trade-offs are in the Studio Library alternatives guide.