迁移指南
迁移至 SIAX Platform
具体的步骤、现实的时间预估，以及哪些环节真正棘手，我们坦诚列出。这些迁移没有一个是单击按钮即可完成——我们直接说明，而不是让您自己踩坑。
来自 Vercel
从 Vercel 迁移到 SIAX
如何将 Next.js 应用从 Vercel 迁移到 SIAX：容器化、没有 1:1 对应物的功能，以及无停机切换。
对于一个只是普通应用的应用来说，需要半天。如果依赖 ISR、Edge Middleware、Vercel Blob 或 KV，则需要一到两周。
来自 Heroku
从 Heroku 迁移到 SIAX
从 Heroku 到 SIAX：将应用容器化、逐个替换 add-on，并以最短停机时间迁移 Postgres。
一个带一个 web 进程和一个 Postgres 的应用需要一天。如果你有五个以上 add-on、后台任务和定时运行，则需要一到两周。
来自 Microsoft Azure
从 Microsoft Azure 迁移到 SIAX
把 App Service、虚拟机和 Azure Database 迁移到 SIAX。哪些直接迁移、哪些留在 Azure，以及迁移实际花费多少。
按工作负载来算，而不是按小时。单个 App Service 应用需要一天。带有几台虚拟机、一个数据库和 blob 存储的典型配置需要三到六周的日历时间，其中大部分花在数据传输和验证上。
来自 GitHub
从 GitHub 迁移到 SIAX Git 和 CI
把仓库、issues 和流水线从 GitHub 迁移到 SIAX Git 和 CI 的实用指南，包括那些实际上无法原样运行的部分。
对一个带简单流水线的仓库来说，半天。对 20-30 个带活跃工作流的仓库：预计两到三个工作日，其中大部分用于测试工作流，而不是迁移代码。
来自 Google Workspace
从 Google Workspace 迁移到 SIAX 邮箱
如何把电子邮件、日历和联系人从 Google Workspace 迁移到 SIAX 邮箱。Docs、Drive 和 Meet 不会一起迁移，请为此规划。
大约十个邮箱需要两到四小时的主动工作，再加上 imapsync 在后台需要的时间，对旧档案来说往往要一天或更久。50 个用户以上：预计一个工作周的日历时间，其中大部分是等待时间、客户端配置和支持问题，而非技术工作。
来自 AWS S3
从 AWS S3 迁移到 SIAX 对象存储
用 rclone 把对象从 AWS S3 迁移到 SIAX 对象存储。复制本身很简单，IAM 策略和预签名 URL 流程则必须重写。
对一个几百 GB、对象数量正常的存储桶来说，一个下午。复制很少是问题所在，费时间的是访问和预签名流程的重写，通常取决于代码中有多少处在与 S3 打交道，需要一到三个开发日。Glacier 中的已归档对象还会增加数天的等待时间。