Hay recursos del sistema cuya migración no se produce nunca (marcos de página, procesadores, etc.). Hay otros donde esta migración resulta natural, como puede comprobarse por analogía con un sistema multiprocesador (Shuttles, DTLBs, etc.)
En un DAMN, todos aquellos recursos de naturaleza dinámica que son susceptibles de cambiar de nodo deben poder hacerlo. Así, en Off, tanto shuttles, como portales y DTLBs puede ``moverse'' o migrar de un nodo a otro.
Hay dos modelos de migración que deben tolerarse un DAMN: la implícita y la explícita. En una migración explícita es el usuario el que toma la iniciativa ejecutando alguna primitiva que causa la migración del objeto considerado. En una migración implícita el objeto migra sin que el usuario tenga necesidad de invocar primitiva alguna.
La migración implícita es importante en un DAMN puesto que permite que
los usuarios que así lo deseen utilicen de manera transparente los
recursos disponibles (tales como procesadores) con independencia de su
posición en la red. Lo que es más, la migración implícita permite
tolerar interdependencia entre varios recursos (p.ej. un shuttle
necesita una DTLB para ejecutar) puesto que en todos aquellos casos
en que se requiere de un recurso (p.ej. una DTLB) para emplear otro
(p.ej. para ejecutar un shuttle en un procesador) el 
kernel tomará la
iniciativa efectuando una migración implícita del recurso
correspondiente (p.ej. la DTLB empleada por el shuttle). La
explícita permite a aquellas aplicaciones más sofisticadas tomar
control de la migración implementando sus propias políticas.
En Off, las tres abstracciones básicas soportan las primitivas freeze (que congela el estado del objeto) y melt (que lo reanima, potencialmente en un nodo distinto). Estas dos operaciones permiten la implementación de diversos sistemas de migración en área de usuario.
La implementación de freeze y melt se apoya en la posibilidad de leer el estado del kernel desde área de usuario [165]. En realidad freeze se limita a mantener la validez del identificador del recurso a congelar y a bloquear todas aquellas peticiones dirigidas a dicho recurso. Cuando un recurso está congelado se opera igual que el caso de recursos remotos. Cualquier petición dirigida al mismo origina entonces una excepción de ``objeto ausente'' que el kernel envía al portal especificado por la aplicación. El manejador de dicho portal puede descongelar el recurso al vuelo, abortar la petición causando un error en el proceso de la llamada original o tomar cualquier otra acción pertinente. La primitiva melt se ocupa principalmente de recrear el objeto congelado recuperándose su identificador, protección y estado; esta primitiva podría usarse en el manejador mencionado anteriormente.
Cuando una petición al sistema requiere la presencia de un objeto de otro nodo (como ocurre cuando se instala para ejecución un Shuttle que anteriormente ejecutaba en un nodo distinto), Off inicia implícitamente la migración del objeto involucrado, elevando una excepción que tratará la aplicación. Esta utilizará las mismas primitivas que en el caso anterior y un protocolo de transporte de su elección.
Como puede suponerse, la persistencia es un efecto lateral de la
capacidad de migración de los objetos del sistema; basta migrar el
objeto hacia memoria no volátil
.
Existen dos aspectos que conviene detallar en este punto: la protección y autenticación de los objetos congelados y la posible heterogeneidad de los sistemas origen y destino de una migración.
Como expondremos en los dos apartados que siguen, en Off se resuelven dichos problemas con el uso de aplicaciones escogidas por el usuario al arrancar el sistema y la definición de una excepción de autenticación y otra de traducción (tratadas estas por las mencionadas aplicaciones).