Process Migration¶

Relocate an executing or suspended operating-system process by capturing its computational state, transferring it across an execution boundary, repairing external bindings, and resuming one logical continuation at the destination.

Version: v2 · 2026-09-06 · History
Domain-specific #: 2546
Origin domain: distributed operating systems
Subdomain: process mobility and state transfer
Aliases: Process Relocation, Migrating Process

Core Idea¶

Process migration relocates one executing or suspended operating-system process from a source execution environment to a destination while preserving enough computational identity and state for execution to continue there. It is not the movement of a program file or the assignment of work that has not begun. The load-bearing claim is stronger: the destination resumes the same logical computation from an admissible cutover point, with memory, registers, control state, and required relationships reconstructed or redirected, while the source no longer executes a competing continuation.

Milojičić and colleagues define the field as transferring a process between two machines and survey its uses for dynamic load distribution, fault resilience, system administration, and data-access locality.^[1] Powell and Miller's DEMOS/MP implementation makes the continuity commitment explicit: a process can move during execution, continue on another processor, retain access to resources, and keep receiving messages through location repair.^[2] Those sources establish an autonomous operating-systems abstraction rather than a loose metaphor for “moving work.”

The structural invariant is one live logical process at source -> establish a migration cut -> encode transferable execution state + account for external dependencies -> transport and reconstruct at destination -> redirect names, channels, and resources -> resume exactly one continuation. A successful migration changes placement without intentionally resetting computation. Some external objects move with the process; others are reacquired at the destination; still others remain at the source and are reached through forwarding. The mechanism chosen for each binding determines transparency, performance, and failure dependence.

This draft uses the historically central cross-machine sense. Moving a runnable thread from one CPU core to another inside one shared kernel is ordinary scheduler migration unless the operation must rebuild a process-level execution environment. Similarly, sending a not-yet-started job to a remote node is initial placement or remote execution. These may share policies with process migration, but they omit the defining problem of preserving accumulated process state across an environment boundary.

Structural Signature¶

A literal process migration has these roles:

Logical process. A particular executing or suspended computation is identified across the relocation. Its identity may be exposed through a stable process identifier, job identifier, runtime handle, or system-maintained correspondence.
Source environment. The kernel, processor, machine, namespaces, runtime, and local resources currently hosting the process are known.
Destination environment. A compatible environment accepts the process and can represent its instruction set, address-space semantics, operating-system objects, credentials, and resource requirements.
Migration decision and admission. A policy or operator selects the process and destination; the destination has authority and capacity to accept it. Load balance is a common motive, not part of the identity.
Cutover boundary. The system identifies a consistent instant or logical cut. Execution is stopped briefly or its changing state is tracked while bulk transfer proceeds.
Process image. The transferable state includes code identity, address-space contents, registers, program counter, stacks, thread states, signal state, scheduling/accounting metadata, and other runtime-specific data needed for continuation.
External-binding inventory. Open files, sockets, pipes, device connections, IPC endpoints, shared memory, locks, timers, credentials, and kernel objects are classified for transfer, reconstruction, remote forwarding, or explicit rejection.
State-transfer protocol. Stop-and-copy, iterative pre-copy, lazy/post-copy, checkpoint-copy-restore, or another protocol carries the image and coordinates mutations during transfer.
Binding repair and location repair. Peers and services continue to reach the process, and the process continues to reach its resources, through stable names, rebinding, forwarding, proxying, or co-migration.
Single-continuation invariant. At commit, exactly one authoritative execution continues. The protocol prevents both dual execution from one state and loss of all executable copies.
Resumption test. The destination restores the process in a state equivalent under the migration contract and verifies that required channels and resources remain usable.
Cleanup and residual-dependency record. Source state is retired or retained only as an explicit forwarding/proxy service; any continuing dependence on the source is visible.

The abstraction does not require complete user-level transparency. Cooperative migration may ask an application to quiesce or reconnect. What it requires is continuity under a declared equivalence: the destination represents the same logical process history rather than a fresh run that merely repeats some inputs.

What It Is Not¶

Not initial scheduling. Choosing where an unstarted task will run transfers a description of work, not accumulated execution state.
Not copying an executable, package, or container image. Static artifacts can create a new process but do not carry the old process's memory, register, channel, and in-flight state.
Not ordinary CPU affinity or thread scheduling. A shared kernel can move a runnable entity between cores without reconstructing cross-machine resources; that local case lacks the hard boundary the abstraction organizes.
Not checkpointing alone. A checkpoint records recoverable state. Migration additionally transfers it to a different execution environment, restores bindings, selects one continuation, and completes a placement change.
Not restart from an application-level save file. Reloading a document or domain checkpoint may be functionally adequate, but it is not transparent OS-process continuation unless the process identity and execution contract are the migrated unit.
Not virtual-machine live migration as such. VM migration transfers a whole guest machine and its devices; process migration transfers one process or process group under a host/runtime contract. Container migration occupies an intermediate layer and counts only when its live process state is captured, not when an image is redeployed.
Not data migration. Moving records or files changes data placement without preserving an executing instruction stream.
Not failover by starting a replica. A replica may have independently maintained state and a different identity. Process migration transfers a particular continuation.
Not integrated-circuit process or layout migration. Retargeting a chip layout to a new fabrication node is a separate engineering homonym.
Not guaranteed fault tolerance. Migration can evacuate a degrading host, but a stop-and-copy transfer may itself fail, and residual dependencies can leave the destination vulnerable to source failure.

Scope of Application¶

The abstraction originated in distributed operating systems and cluster computing. DEMOS/MP moved executing processes among loosely coupled processors and used location-independent message links plus forwarding to preserve communication.^[2] Sprite later explored transparent process migration for workstation pools, including eviction when a workstation owner returned; Douglis and Ousterhout analyze design alternatives and the Sprite implementation rather than treating relocation as a simple memory copy.^[3] The ACM survey compares MOSIX, Sprite, Mach, and Load Sharing Facility, demonstrating recurring identity across materially different systems.^[1]

Modern checkpoint/restore tooling reuses the structure for applications and containers. CRIU's official live-migration procedure separates dump, image copy, destination restore, and source cleanup, while calling out network-address availability, TCP socket restoration, frozen-task downtime, iterative transfer, and diskless or lazy variants.^[4] These implementation details are not universal requirements, but they instantiate the same state/binding/cutover roles.

Applications include dynamic cluster load balancing, moving computation toward large data, evacuating machines for maintenance, consolidating hosts, recovering from predicted degradation, and continuing long-running computation across administrative or hardware changes. Suitability depends on state size, dirtying rate, communication locality, external-device bindings, destination compatibility, security policy, and the duration of permitted pause.

The core is cross-machine or cross-runtime relocation. A system may extend it to process groups when members share memory or IPC state; the migration unit must then expand so that the declared invariants remain representable. Heterogeneous migration is possible only with a translation layer for instruction state, data representation, system calls, and ABI semantics. A raw memory image from one incompatible architecture is not a portable continuation merely because bytes arrived.

Clarity¶

Use an eight-gate diagnostic:

Was the process already executing or suspended with accumulated state? If not, classify the operation as placement or remote execution.
What is the identity warrant? Name the process/job handle and the equivalence under which destination execution counts as the same continuation.
Where is the consistent cut? Identify how threads, signals, pending system calls, and concurrent memory writes are frozen or tracked.
What enters the image? Enumerate memory regions, registers, thread metadata, credentials, timers, and other local state.
What remains external? Classify files, sockets, shared memory, devices, IPC, locks, namespaces, and services.
How are names and bindings repaired? Specify transfer, reacquisition, forwarding, proxying, DNS/address movement, or coordinated peer updates.
How is single continuation committed? Show when the destination becomes authoritative and when source execution is disabled.
What residual dependence remains? Record source proxies, remote file access, forwarding chains, shared storage, or management services whose failure can still break the migrated process.

A claim that lists only “serialize memory and copy it” fails gates 5–8. Memory contains pointers and user data, while the kernel holds open-file tables, socket state, credentials, wait queues, signals, and object references. The source may also be the only route to a device or peer. Migration correctness is therefore a relation among the image, kernel reconstruction, and the external environment.

Manages Complexity¶

Process Migration turns an apparently indivisible live computation into a migration inventory. It separates portable local state, reconstructable state, remotely reachable dependencies, and nonmigratable bindings. That classification exposes why some processes move cheaply while others do not. A CPU-bound process with private memory and shared network storage may be easy; a device-bound process sharing memory and locks with local peers may require co-migration or rejection.

It also separates policy from mechanism. Load balancing, maintenance, locality, and fault avoidance decide why and where to move; capture, transfer, rebinding, and cutover decide how. A brilliant scheduling policy cannot compensate for a migration mechanism that loses pending messages. Conversely, a transparent mechanism can be uneconomic if it moves a memory-heavy process whose working set changes faster than the network can copy it.

Finally, the abstraction gives performance a small set of quantities: total state volume, transfer bandwidth, memory dirtying rate, number and remoteness of dependencies, preparation time, stop time, resume time, and post-migration access cost. These quantities support admission decisions without pretending every byte or binding has the same migration cost.

Abstract Reasoning¶

The structure licenses bounded deductions:

If state is modified faster than an iterative pre-copy phase can converge, repeated rounds cannot make the final dirty set small; the system must tolerate a longer stop, throttle writes, use lazy transfer, or decline migration.
If a binding cannot move, be recreated, or be reached through a proxy, transparent migration of that process under the stated contract is impossible.
If peers address a machine-local process identifier directly, changing hosts requires a forwarding or naming update; location-independent handles reduce that repair surface.
If source cleanup occurs before destination acceptance is durable, a failure can lose the process. If destination execution begins before source authority is revoked, a failure can create two divergent continuations.
If shared memory or tightly coupled IPC crosses hosts without co-migration, remote access can dominate execution and erase any load-balancing gain.
If the destination lacks compatible architecture, ABI, kernel features, credentials, namespaces, or resource policy, byte-level transfer is insufficient.
If a destination still depends on a source proxy for files or messages, relocation has succeeded but source-failure independence has not.
If only static code and initial arguments move, the event creates or places a new process; it does not migrate the old one.
If observed pause is small, that does not prove total migration cost is small; pre-copy traffic and post-resume demand paging can move cost outside the downtime window.
If migration changes externally visible semantics—duplicate writes, reordered messages, lost locks—the state may have been copied while the process contract was not preserved.

Knowledge Transfer¶

Literal transfer occurs among distributed operating systems, HPC runtimes, cluster schedulers with checkpoint/restart integration, application live-migration frameworks, and container checkpoint/restore systems. All recognize executable state, source and destination runtimes, a consistent cut, external bindings, and a single resumed continuation.

The portable skeleton is broader: capture a rich state, encode it for transport, reconstruct it under an equivalence criterion, repair references, and resume. Serialization owns the encode/transport/reconstruct component; Indirection explains stable handles and forwarding; Identity Test explains why the resumed instance is treated as the same process; State and State Transition explains the cut and resumption; Load Balancing is one selection policy. None alone closes the computing identity.

Human job transfers, patient handoffs, moving organizations, and relocating physical machinery may preserve state across a boundary, but they do not have process images, registers, address spaces, kernel objects, sockets, or exactly-one executable continuations. Calling those “process migration” is metaphor unless “process” means an OS process or a runtime-defined equivalent. The integrated-circuit homonym must remain separate.

Examples¶

DEMOS/MP relocation. The kernel marks a process as migrating, establishes destination state with the same process identifier, transfers process state, forwards queued and arriving messages, leaves a forwarding address, then restarts the process in its prior state. The paper's location-independent links make resource and message continuity explicit.^[2]
Load-driven migration. A cluster detects one host's sustained CPU overload and selects a CPU-bound process whose private memory is modest. The process is quiesced, state is copied, file handles are reopened through shared storage, network identity is repaired, and it resumes on an underused host. The event instantiates migration; the selection objective instantiates Load Balancing.
CRIU checkpoint/copy/restore. A running application is dumped to checkpoint images, those images are made available on a destination, network prerequisites are established, and CRIU restores it. Iterative migration reduces frozen time by sending memory before the final dump; lazy variants defer some transfer until demand.^[4]
Residual dependency. A migrated process retains an open device or file service through a source-side proxy. Execution continues, so migration succeeded, but the source remains a failure and latency dependency.
Co-migration case. Two processes share memory and synchronization primitives. Moving only one would convert local references into unsupported remote relationships, so the migration unit expands to both processes and their shared segment.
Negative: scheduler placement. A queued batch job has code and inputs but has never executed. Assigning it to node B is remote placement, not migration, because no accumulated process state crosses.
Negative: container redeployment. An orchestrator starts a fresh container from the same image on node B and terminates the old one. Unless live process and binding state cross under a continuation contract, this is restart/replacement.
Negative: copied checkpoint with both copies running. Restoring a checkpoint at B while A continues without a replication protocol produces two branches. It violates the single-continuation migration invariant.

Structural Tensions¶

Transparency vs. cooperation. Kernel transparency minimizes application changes; application quiescence can make complex resources migratable and failures legible.
Downtime vs. transfer volume. Stop-and-copy sends one stable image but pauses longer; pre-copy reduces the final stop by sending pages repeatedly.
Pre-copy vs. dirtying rate. Iteration converges for stable working sets; write-intensive processes can retransmit indefinitely.
Source independence vs. residual dependency. Forwarding avoids reconstructing every resource; it preserves the source as a latency and failure point.
Fine migration unit vs. coupled state. Moving one process maximizes placement freedom; shared memory, IPC, and locks may force group migration.
Stable identity vs. location-aware naming. Persistent handles make movement transparent; embedded host identifiers spread repair work across peers.
Heterogeneity vs. fidelity. Broad destination choice improves utilization; architecture and ABI translation enlarge the state contract and verification burden.
Availability vs. single continuation. Keeping the source ready aids rollback; insufficient commit discipline risks simultaneous divergent execution.
Performance gain vs. migration cost. Better balance or locality may amortize transfer; large state, cold caches, and remote dependencies can make movement net harmful.

Structural–Framed Character¶

Process Migration is framed, aggregate 0.93. Its general skeleton resembles state transfer and identity-preserving continuation, but literal recognition is deeply constituted by operating-system objects: processes, address spaces, registers, kernel tables, file descriptors, IPC, namespaces, sockets, scheduling states, and destination ABI. Its major failure modes arise from those constructs. The term transfers well inside computing and poorly outside it without metaphor, so it is not a prime.

Structural Core vs. Domain Accent¶

The core is state-bearing entity -> consistent cut -> transportable representation -> destination reconstruction -> reference repair -> one continuing identity. The domain accent specifies that the entity is executable computation and that correctness includes instruction state, memory, kernel-managed bindings, peers, and exactly-one execution.

Remove the accent and the pattern decomposes among Serialization, Indirection, Identity Test, State Transition, and Handoff. Preserve it and an engineer can distinguish migration from redeployment, checkpointing, scheduling, and replica failover; predict whether a process with device or IPC bindings can move; and estimate downtime versus total cost. That residual reasoning justifies a domain-specific node.

Serialization is the minimal structural parent: process-local runtime state is converted into a transportable image and reconstructed. Migration then adds external binding repair and cutover, so Serialization does not cover the whole node.
Indirection supports location-independent process handles, resource proxies, and message forwarding. It is a common implementation strategy, not mandatory when all peers can be explicitly rebound.
Identity Test supplies the criterion under which destination execution is the same logical process rather than a replacement or replica.
State and State Transition describes the source-running, migrating, destination-running protocol states but not their OS-specific contents.
Load Balancing is a frequent policy motive. Migration can instead serve maintenance, locality, or fault avoidance.
Controlled Reentry is an analogy for monitored resumption, but ordinary migration need not use staged return or rollback checkpoints.

Only Serialization is proposed as a DAG parent. The other relations remain prose to avoid confusing mechanisms, correctness criteria, and motives.

Relationships to Other Abstractions¶

Current abstraction Process Migration Domain-specific

Parents (1) — more general patterns this builds on

Process Migration is a kind of Serialization Prime

Serialization is the minimal structural parent: process-local runtime state is converted into a transportable image and reconstructed.

Hierarchy path (1) — routes to 1 parentless root

Process Migration → Serialization → Transformation → Function (Mapping)

Neighborhood in Abstraction Space¶

Process Migration sits in a sparse region of the domain-specific corpus (97^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Checkpoint/restore can be a migration mechanism, but a checkpoint stored and restored on the same host is not relocation. Live migration emphasizes low service interruption; a process can migrate with visible pause and still satisfy the identity. Remote execution and batch placement decide an unstarted computation's location. Load balancing chooses distribution; migration is one actuator. Failover may activate a replica rather than transfer one process. VM migration moves a machine abstraction; container migration counts only when live runtime state crosses.

Do not conflate process image with executable image: the former contains accumulated runtime state, while the latter can launch a new run. Do not conflate persistent process identity with an unchanged numeric PID: translation can preserve logical identity, while reusing a number without state continuity does not. Finally, integrated-circuit process/layout migration is a different domain identity involving fabrication-node retargeting.

References¶

[1] Dejan S. Milojičić, Fred Douglis, Yves Paindaveine, Richard Wheeler, and Songnian Zhou, “Process Migration,” ACM Computing Surveys 32(3) (2000), 241–299. Authoritative field survey defining machine-to-machine process transfer, motivations, design issues, and implementations. registry ↩a ↩b

[2] Michael L. Powell and Barton P. Miller, “Process Migration in DEMOS/MP,” Proceedings of the Ninth ACM Symposium on Operating Systems Principles (1983), 110–119; archival author copy. Primary implementation source for executing-state transfer, stable identity, resource continuity, message forwarding, commit, restart, and source cleanup. registry ↩a ↩b ↩c

[3] Fred Douglis and John Ousterhout, “Transparent Process Migration: Design Alternatives and the Sprite Implementation,” Software: Practice and Experience 21(8) (1991), 757–785. Primary implementation and design-analysis source for workstation process migration. registry ↩

[4] CRIU Project, “Live Migration”, official project documentation. Operational source for dump/copy/restore/cleanup, network prerequisites, socket restoration, iterative migration, lazy migration, and downtime tradeoffs. registry ↩a ↩b