对于任何应用程序来说，数据迁移都是事实。需求变更、功能添加或删除、服务合并或拆分。随着应用程序的发展，其背后的数据也必须随之发展。在这方面，存储在SpiceDB中的权限信息与任何其他数据库中的任何其他数据没有区别。
如果你不熟悉一般的在线迁移策略，那么网上有一些很好的资源涵盖了一般的主题；我们将只关注SpiceDB，以及如何针对它所包含的数据和模式执行迁移。
但首先，让我们重点介绍一下SpiceDB因无需迁移而大放异彩的几个场景：
如果与SpiceDB对话的服务正在被重构（即，一个整体正在被拆分为一个面向服务的体系结构），那么您可能不需要对SpiceDB做任何事情。
因为SpiceDB是作为一个独立的服务运行的，所以任何与之通信的新服务只需要连接并进行必要的查询。可以放心的是，授权（通常是在这一层改变体系结构的一个挑战部分）不会成为负担或瓶颈。
使用SpiceDB，您可以编写关系，但可以检查权限。权限是针对已存储的关系计算的。这意味着，您希望对权限计算方式所做的任何更改都可以在不进行任何迁移的情况下完成：只需更新模式即可。
定义用户{}定义组织{关系管理员：用户关系直接成员：用户权限成员=直接成员}
您可以将管理员包括为成员并创建新的“管理员”权限，而无需任何迁移：定义用户{}定义组织{关系管理员：用户关系直接_成员：用户权限管理员=管理员权限成员=直接_成员+管理员}
总会有需要迁移的情况，当这种情况发生时，您需要规划迁移步骤。以下是一些有助于在线迁移计划的模式：
所有模式写入都是完全一致的。这意味着在写入模式后发生的任何关系写入都将在该新模式下进行评估。
但是，任何关系读取都将使用与读取请求版本匹配的模式版本。这确保检查使用正确的模式进行评估，以避免新的敌人问题。
只有在没有引用关系的情况下，才能从现有架构中删除关系、权限或对象定义。
记住这些，你只需要开始使用一个合适的API客户端。
以下示例将假设这是我们开始使用的模式：
定义用户{}定义文档{关系编写器：用户关系读取器：用户权限编辑=编写器权限视图=读取器+编辑}
定义用户{}定义文档{关系编写器：用户关系读取器：用户关系所有者：用户--步骤1权限编辑=编写器+所有者--步骤4权限视图=读取器+编辑}
在更新spicedb时，创建的任何新文档都应包含新的所有者关系。
重新建立关系，就好像它从一开始就存在一样。在本例中，我们在应用程序的数据库中查找谁创建了文档，并用authzed编写所有者关系。应用程序编程接口。v1。写作关系。如果这是通过触摸完成的，那么它将不会与上一步中所写的关系冲突。
当数据已被回填、确认有效且正在写入新数据时，可以在其他权限计算中包含该关系，并更新架构。现在就开始更新模式可能是安全的；权限计算只会在回填关系时发生变化。
1定义用户{2 3定义文档{4关系编写器：用户5--步骤5:删除`关系读取器：用户`6 7权限编辑=编写器8权限视图=编辑--步骤1:删除`读取器+`9}
如果此时通过测试发现了任何问题，数据仍然存在，可以通过将更改恢复到架构来恢复权限。
在生产过程中，您可以根据需要在第2步停留多长时间，以保持回滚更改的能力。
定义用户{}定义组{--步骤1关系成员：用户--步骤1}--步骤1定义文档{关系编写器：用户|组#成员--步骤4关系读取器：用户|组#成员--步骤4权限编辑=编写者权限视图=读取器+编辑}
现在我们已经研究了一些示例，很明显，在SpiceDB中的迁移并不比在通用DBMS中的迁移更具挑战性，而且在某些情况下要简单得多。
但没有理由就此止步！我们已经看到了SpiceDB对权限计算的关注是如何消除某类硬迁移问题的。我们认为有更多的方法可以简化SpiceDB中的迁移。如果您有兴趣与我们讨论这些问题（或者您对自己的迁移有疑问），为什么不顺道拜访我们的discord并聊一聊呢？