base package in every migration, we can drastically cut down the amount of data that needs to be transferred, and in turn reduce the service downtime and overall migration time.

We extend this *two-layer* approach further, by splitting out the application from the instance layer into an intermediate *application layer* that contains an idle version of the application and any application-specific data. The instance layer now only needs to contain the running state (i.e., in-memory state) of a service. When we want to migrate a service, the application layer can be migrated first whilst the service is running, then the service is suspended and the instance layer is transferred to the destination. A running service can be reconstructed from a combination of the base layer, instance layer, and associated application layer. By doing this, we are able to transfer the majority of an encapsulated service’s program and data before suspending the service, leaving only the running state transfer to count towards the service downtime. This three-layer setup is shown in Figure \[fig:threeLayerModel\], and is referred to as the *three-layer model*.

The intermediate application layer of the three-layer model has advantages other than improvements to service downtime. A distinct application layer 