I have created a complex animation where the camera moves relative to a target object which does not move. Now I would like to keep the same relative movement between camera and target object. But the target object should move relative to the camera and the camera should not move.
You can do that by copying and manipulating the F-Curves in the Graph Editor.
Essentially, you need to copy the f-curves relating to Location (you can do this with Ctrl+C when you have selected them) and paste them into the F-Curves for the object (using Ctrl+V) (you'll need to add a keyframe first to create the curves for the object).
Once you've copied the f-curves you can add a Generator modifier with a 1st order polynomial in the format
y = c + mx, setting
m to '-1' (so as to 'flip' the curve) and 'c' equal to an offset matching the difference between the coordinate of the Camera and your object at the start of the animation.
Once you've done this you should get the same (but opposite) motion between your camera and object - so all that's left is to remove the keyframes from the camera so that it remains static while the object moves in the opposite way to which the camera previously animated.
Essentially, you need to transform everything else by the inverse of the camera transform, and then stop moving the camera. You can do this with a bit of set-up and a bake action operation.
Start by making two empties in the same orientation at frame 1. Parent one to the camera with keep transform. Give it a copy transforms constraint, world->world space, targeting the second. Bake the action on the constrained empty ("bake action" operation), with visual keying + clear constraints. This empty's animation data now contains the inverse of the camera's animation. You can now delete the second empty.
Go to frame 1. Unparent the empty with keep transform. Parent all of the scene's root level objects to this empty with keep transform. Delete all animation data for the camera. Play the animation.
There are things to be careful of. World space constraints or drivers are now being evaluated differently-- you've created a new space in which to evaluate everything, the old camera space. Cameras can have scale data, which gets propagated to their children, even though it doesn't have any effect on the render (ie, make sure you're not scaling your camera, natively or inherited or constrained, before doing all that.) FoV changes won't be transferred to the scene objects, and cannot be. If you're switching active cameras, it's just giving you the inverse transform of one camera, not keeping track of the switch. Subframe interpolation isn't guaranteed, so don't try to remap frame rate or use motion blur after the bake. Physics are now being evaluated in a different reference frame, and so won't be the same. Of course, one or more of these differences is probably why you want to do what you want to do, so at least one of those is a good thing, not a drawback.