所有权与迁移：网站属于您

网站的所有权不是一个物件，而是一组容易被混为一谈的东西：让网站运行起来的软件、发布其上的文字与图像、描述业务的配置、人们输入的地址、对外提供页面的账户，以及网站连接的外部服务。在实践中，您能多自由地处置网站，取决于其中有多少掌握在自己手里。

所以「网站属于您」这句话不能只靠宣告，还需要解释。即使许可证是永久的，如果域名、托管账户和构建配置登记在他人的名下，您也搬不动。即使文件副本在您手里，如果「把文件变成可用网站的方式」不在这份安排之内，它也派不上用场。无法行使的所有权不是一种状态，而是一个承诺。

Foundation 的设计正是以这一区分为前提的：平台是开放许可证下的共有产品，而在它之上搭建的网站属于您。谁持有对外提供网站的账户，取决于您选择的方式。本页把这两者分清楚。

在 Foundation 上运营网站有三种方式。第一，完全自行运营：代码仓库、域名和托管账户都在自己手里，变更也由自己应用。第二，与您选定的开发者或机构合作：工作在自己的代码仓库和账户中进行，对方是执行者。第三，与 Provelopment 合作：按约定获得部署、维护和运维方面的协助。

这三种都不是已经固定下来的服务菜单，也不表示今天提供什么。它们是项目构建方式背后的意图：平台、配置与手册被做成让这三种方式都能成立的样子，而不是让其中任何一种成为唯一合理的选择。

三种方式中不变的是：软件授权给您，内容与品牌属于您，而是否迁移的决定权在您手里。

一个 Foundation 安装实例（Installation）并不一定对应一个网站。Provelopment 的安装实例可以包含多个 Spoke：每个公开主机名对应一个独立站点，它们共用同一套 Foundation 运行时，但各自拥有自己的配置、内容与资源。

这个区分在实践中很重要。安装实例只包含一个站点时，交接相对简单。包含多个 Spoke 时，需要把共用的部分（运行时、共享外壳、模式、构建与部署流程）与每个 Spoke 自己的部分（配置、内容、资源、域名）分开考虑。单独把某个 Spoke 移到另一个安装实例是可行的，但需要先决定共用部分如何处理，工作量比交接单个站点更大。

因此不能说「每个网站都能自动独立迁移」。能否迁移取决于该网站属于哪个安装实例、其中什么是共用的。这是制定交接计划时最先需要弄清的事情之一。

代码仓库里只有文件。里面没有域名，没有凭据，没有托管账户，也没有那些留在经手人脑子里的判断。副本可以很完整，但当托管账户的访问权被关闭的那一天，网站就停下来了。

所以有用的问题不是「我们有没有文件副本」，而是「别人能不能把它运作起来」。如果这个答案不清楚，交接就还没有完成。

更换开发方或服务商是常见的决定，工作大部分是实务性的：迁移账户与配置、改变域名与 DNS 的指向、重新写入机密信息与环境变量、在新环境执行部署，并确认页面、表单和跳转与过去一致。

也有需要如实说明的事：结果不会总是相同。能力、价格与工作质量因服务商而异，匆忙的迁移会带来暂时的故障。Foundation 能确证的只有一点——软件的任何一个部分都没有被刻意做成难以迁移的样子。

维护与运维的责任始终落在某个人身上，需要确定的是「是谁」：您自己、您指定的开发者，或按约定承担工作的 Provelopment。重要的不是答案的内容，而是它是决定而不是猜想。工作本身也很日常：更新依赖、应用安全更新、确认备份真的能恢复、监控网站是否可达、检查更新有没有造成损坏。无人打理的网站不会突然崩塌，而是逐渐陈旧，费用最后才一起显现。所以定下来的答案比想当然的答案更省成本。

这里的经营方式刻意保持朴素：把付了钱的工作做好，让结果说话。Provelopment 希望客户继续合作的理由，是自己确实有用——可靠的实施、稳定的运维，以及来自不只搭建网站、也长期运作网站的判断力。

因此两种结果对我们都是成功。把网站接回去、自己有把握地运作，是成功——项目兑现了它承诺的事。因为 Provelopment 确实更合适而继续合作，也是成功，而且是更理想的形式：比较之后留下来的，只会是这种关系。

同时如实说明两点。更换服务商并不等于相同的结果：能力、价格与质量各不相同。本页也不是对 Provelopment 未来处境的承诺——这里写下的是软件构建方式真正支撑的意图，而不是关于公司经营状况的保证。