Hi Senor!
One of the things that is sometimes hard to understand about MongoDB is that there IS NO "at the server". :-)
As a general design principle, MongoDB does not support any operation which cannot be efficiently performed on a sharded cluster. If you think about it, once you're running in a sharded cluster, the very concept of *THE* server goes away -- you have multiple servers. Dozens of them, in the most general case, even if you only consider Primary nodes.
As a result, many operations which would be simple or trivial to perform "at the server" become intractable, since distributed operations are hard to perform efficiently with full generality.
A rhetorical question for you -- how do you know that pulling things across the wire and pushing them back will be a bottleneck? Have you measured how long it takes? Or are you just relying on your intuition? Maybe -- just maybe -- it isn't as big of a performance penalty as you think it is.
To answer your direct question: the only way in MongoDB to move a document from one collection to another at the "server-side" is via stored Javascript. This is not recommended -- it will take the global lock and block all other operations, and it Simply Will Not Work if you have to shard either one of the collections.
As others have said, it's probably most efficient to change your schema so that all of these documents are in one collection.
If you choose not to change your schema, and If your measure network latency turns out to be significant (50 ms or more) then you can optimize this process by having a dedicated client program running on the same machine as your 'mongod' (or one of your mongos) which performs the find()/save()/remove() operation.
Let me know if you have further questions.
-William