diff --git a/docs/use-cases/using-vpp-and-kata.md b/docs/use-cases/using-vpp-and-kata.md
index 495e01cd12..ea09c50f51 100644
--- a/docs/use-cases/using-vpp-and-kata.md
+++ b/docs/use-cases/using-vpp-and-kata.md
@@ -12,7 +12,7 @@ For more information about VPP visit their [wiki](https://wiki.fd.io/view/VPP).
 
 ## Install and configure Kata Containers
 
-Follow  the [Kata Containers setup instructions](https://github.com/kata-containers/documentation/wiki/Developer-Guide).
+Follow  the [Kata Containers setup instructions](../Developer-Guide.md).
 
 In order to make use of VHOST-USER based interfaces, the container needs to be backed
 by huge pages. `HugePages` support is required for the large memory pool allocation used for
diff --git a/src/runtime/virtcontainers/experimental/README.md b/src/runtime/virtcontainers/experimental/README.md
index 109724acd0..b126f68442 100644
--- a/src/runtime/virtcontainers/experimental/README.md
+++ b/src/runtime/virtcontainers/experimental/README.md
@@ -56,7 +56,7 @@ That depends.
 For the feature that breaks backward compatibility, we usually land it as formal feature in a major version bump(x in x.y.z, e.g. 2.0.0).
 But for a new feature who becomes stable and ready, we can release it formally in any minor version bump.
 
-Check Kata Container [versioning rules](https://github.com/kata-containers/documentation/blob/c556f1853f2e3df69d336de01ad4bb38e64ecc1b/Releases.md#versioning).
+Check Kata Container [versioning rules](../../../../docs/Stable-Branch-Strategy.md#Versioning).
 
 The experimental feature should state clearly in documentation the rationale for it to be experimental, 
 and when it is expected to be non-experimental,