diff --git a/docs/known-differences-with-cf-for-vms.md b/docs/known-differences-with-cf-for-vms.md
index 3f0a82347..280e41a7e 100644
--- a/docs/known-differences-with-cf-for-vms.md
+++ b/docs/known-differences-with-cf-for-vms.md
@@ -19,6 +19,11 @@ the API shim, the user would only be able to list and view spaces which have rol
 ### Rolling Updates
 In Kofiri `--strategy=rolling` is implemented using k8S rolling update capabilities of the scheduler. At the moment korifi uses statefulsets to run the app workloads. Rolling update for statefulsets stops the old instance before starting the new one, for ordering reasons. If the app has only one instance the udpate will cause a downtime. Apps with more than one instance won't experience any downtime, but they will have one instance less up and running during the update.
 
+### Stack Changes
+While in CF for VMs the staging process yields a droplet, which is a stripped container image without base layer/operating system.
+In Korifi a fully fledged image is created which includes the base operating system(stack). 
+This alters the behaviour in case of stack updates. CF for VMs does purposefully combine stack and droplet at container instance creation time - thus a restart of an app consumes a new stack. In Korifi only a restage of an app consumes thew new stack. One might need to detect that and dynamically rebase a droplet onto a new stack in korifi before starting the container to yield the same behaviour here. 
+
 ## Apps
 ### App Security Groups