In general programs, doesn't have to be functional, the environment is stateful and often has abstract, black box processes. This can be transferred as well, by copying some things, transforming others, and in general where necessary using a two-way pipe of some kind. By analogy, imagine creating a WebSocket at the same time as making a JSON-RPC call.
Except for the black boxes, this kind of transfer can be taken further to make a general distributed system. Think things like Paxos, Raft, CRDTs. If the data is also mobile to where it is used, this performs well for many tasks. When that is done, in some ways everything comes back to messages and state again and doesn't need specific pipes. That's more robust then the simple form of transfer.
The resulting architecture is often much faster than the non-distributed version for many tasks, and robust, but it takes a lot of tricky parts to make a general purpose architecture with those qualities and stay high performance.
You can copy them in a pure functional program if the function AST you're transporting is sufficiently expressive, because the values of the unbound free variables in pure FP are available at the point where the function is defined, so can be inlined into it, and included in its hash.
But when it's not pure FP, then indeed you can't copy the values into the function AST, because the environment at the point of each call to the function is what matters.
(The pipe stuff is just for making it more efficient, and handling black boxes which sit outside the paradigm of concrete values, things like I/O monads and devices).
Here's a trivial example:
\f -> \y -> (runRemotely (\x -> f y x))
For this trivial minimalist example you might cook up a one-off hack like lambda-abstracting the free variables in the runRemotely expression and then reapplying to the returned value, but there are much more complicated and insidious examples where these workarounds don't work.
It's a free variable, not a variable bound by a lambda.