Add docs on migrating between instances.

Author: rkistner

mint.json

@@ -360,6 +360,7 @@
             "self-hosting/lifecycle-maintenance/securing-your-deployment",
             "self-hosting/lifecycle-maintenance/healthchecks",
             "self-hosting/lifecycle-maintenance/telemetry",
+            "self-hosting/lifecycle-maintenance/migrating",
             "self-hosting/lifecycle-maintenance/multiple-instances"
           ]
         },

self-hosting/lifecycle-maintenance.mdx

@@ -72,7 +72,7 @@ It is currently required to host the API container on a dedicated subdomain - we
 
 For self-hosting, [nginx](https://nginx.org/en/) is always a good option. A basic nginx configuration could look like this:
 
-```
+```yaml
 server {
     listen 443 ssl;
     server_name powersync.example.prg;

self-hosting/lifecycle-maintenance/migrating.mdx

@@ -0,0 +1,14 @@
+---
+title: "Migrating between instances"
+description: "Migrating users between PowerSync instances"
+---
+
+## Overview
+
+In some cases, you may want to migrate users between PowerSync instances. This may be between cloud and self-hosted instances, or even just to change the endpoint.
+
+If the PowerSync instances use the same source database and have the same basic configuration and sync rules, you can migrate users by just changing the endpoint to the new instance.
+
+To make this process easier, we recommend using an API to retrieve the PowerSync endpoint, intead of hardcoding the endpoint in the client application. If you're using custom authentication, this can be done in the same API call as getting the authentication token.
+
+There should be no downtime for users when switching between endpoints. The client will have to re-sync all data, but this will all happen automatically, and the client will atomically switch between the two. The main effect visible to users will be a delay in syncing new data while the client is re-syncing. All data will remain available to read on the client for the entire process.