The real horrors, of course, are serious changes to the layout or proportions of the skeleton. These happen for a lot of reasons: a change in the game design, a fatal flaw in the existing skeleton (like an unavoidable gimbal lock that snuck through testing), or an anatomical problem that has to be fixed. When these sorts of situations arise, fixing them is going to be costly. The only question is how much.
The basic strategy for coping with serious skeleton changes is to retarget your existing animations onto the new skeleton, in much the same way that you might apply animations from a mo-cap actor onto a monster. If you already have in-house expertise in motion retargeting, you've got a huge leg up on the problem. Experienced MotionBuilder jockeys can be particularly useful when the bones start going haywire.
Of course, as those old MotionBuilder pros can tell you, retargeting isn't free. It's better than fixing animations by hand, but it's hardly free.
The primary goal of retargeting animation is to get something that looks like the original motion transferred onto a new skeleton. But looking alike is not the same as sharing animation curves and keyframe data, or fancy control rigs.
If you have to do major surgery on your skeleton during production, retargeting will help you preserve the look of your animations. But the odds are high that you'll end up with files that look like they were produced using motion-capture: dense, keyframe-by-keyframe data on every channel of every bone in the skeleton, whether you need it or not.
If your animators have spent days carefully tweaking the tangents on their f-curves, they're not going to be happy when they open a retargeted file and see a graph view that looks like the army ant horde from Indiana Jones and the Kingdom of the Crystal Skull. The only consolation is that without retargeting, they'd have to open an empty file and start all over from scratch.
If you don't have an in-house expert who knows mocap retargeting, you can build your own retargeting system in MaxScript, Mel, or Python. It would take years to build a homebrew system that can match the sophistication of dedicated motion-editing software, but a basic version should be well within the capability of any good rigger or technical animator. A good suite of retargeting tools is one of the best investments you can make for your character department.
Figure 1: A Basic retargeting setup. The original skeleton (blue) drives a set of world space constraint objects (green). These, in turn, drive the new skeleton (brown) even if it has different orientations or proportions.
The essence of all retargeting systems is the old rigger's trick known as "faking and baking." (See Figure 1, above.) The "faking" step involves creating a world space recording of the original animation. You create dummy nodes for every bone in the skeleton and glue them to the original animation using parent constraints.
The "baking" step consists of baking the transforms of the constrained dummies so they're independent of the original bones (that's "collapsing controllers" for Max folks, just as capable, though it doesn't sound as snappy). Baked dummies in hand, you can load up the new skeleton and reverse the process, constraining the new bones to the existing dummies and then baking the constraints down to keys. (See Figure 2, below.)
Figure 2: The animation from the original skeleton is captured on the world space locators. First they are constrained to the original bones, and then the results of those constraints are "baked" or "collapsed" into ordinary keys.
The system automatically accounts for the kinds of changes that make it impossible to simply transplant animation curves. Different rotation orders or re-oriented parents don't affect the outcome, and the results are as close as the differing skeletons will allow. With the constraint's ability to maintain initial offsets, you can even compensate for minor changes in position and orientation of the new bones.
Although the results of a fake-and-bake retarget are a bit oversupplied with keyframes, they should at least resemble the original animation pretty closely. (See Figure 3, below.) It's not MotionBuilder, but it's a handy hack that doesn't require a PhD in animation.
Figure 3: The world space dummies now constrain the new skeleton. If the new skeleton is physically similar (say the rotation orders or joint orientations are the only difference) the animation transfers exactly (top). If the proportions are different, the animation will be similar but not identical to the original -- in the bottom example, the third bone’s animation is constrained by the locator from the fourth bone in the original skeleton -- this ensures the two chains are parallel, but the three-bone chains is slightly displaced from the original.