As you already know, the Massiv divides all nodes into three groups: client nodes, simulation servers and data service nodes. Because data service nodes do not participate in the simulation, they can never be destination of migrations and thus will not be mentioned in the following sections.
Migration among server nodes is the the basic principle the entire communication among remote objects is built upon. There is no restriction on this type of migration because server nodes are always trusted so you can migrate any object to any server node at any time.
Because server nodes can't trust any data from client nodes, there are many restrictions on object migrations from client to server nodes:
Only one object can migrate from a client node to a server node at once i.e. any migration group sent from client nodes to some server node must consist of only one object. If a client node sends two or more objects as a part of one migration message, the server node discards the message away and the client is disconnected from the simulation.
Only objects of explicitly selected classes can migrate from client to server nodes. When you create a new class, you can specify in its IDL description whether the class is allowed to migrate from client to server nodes (see client_server_migrate attribute in Section 10.9.3, “Class Attributes”). If the client node sends an object which is not allowed to migrate from client to server nodes, the server node discards the message and the client is disconnected from the simulation.
The destination of the object which is being sent from a client node to a server node must be an account object of the client (see Chapter 14, Special Objects). Its up to account's logic to process the object and optionally forward the message to another objects in the simulation. Again, if the client is trying to communicate directly with an object different from its account object, it is disconnected from the simulation.
Of course the data itself of the object which is being sent from the client node to the server node is verified as well.
Once the object is successfully verified by the server, new ObjectId is generated for the object because its current ObjectId, generated by the client, is not persistent and can't be used as a valid ObjectId inside the simulation. Having new ObjectId, the object can be finally delivered to the account object of the client.
Similarly to migration from client to server nodes, also the migration from server to client nodes have some specifics. First of all, there are no restrictions on which and how many objects can migrate to client nodes. But you should have in mind that the client nodes don't support all classes supported by the Core on server nodes but only a subset.
Because object owned by client nodes are not part of the simulation and the client nodes can't be trusted, once an object is migrated from servers to a client node, it can't ever return back in the simulation. The server nodes also loose track of the object and don't monitor the object any more.