我们都知道，数据在临床试验中是非常重要的，必须确保数据的安全、准确。但为了满足EDC实际的使用需求，有时不可避免地要进行EDC的变更，那么必然要做的就是——数据迁移。
迁移的过程更需慎重，对迁移你了解多少？
Rave所有的数据迁移都需要做Migration吗？答案很明显，当然不是。我们知道做Migration是最花时间和精力的迁移方式，那么哪些情况可以让我们避开Migration，更快速准确地完成迁移呢？数据迁移工作又是如何展开的？
下面小编就带你了解Rave 的3种数据迁移方法，让你可以根据具体情况、选用最适合的方法去做迁移。
在RAVE中数据迁移的分类：
Quick Publish
Migration
Push
Quick Publish
Quick Publish进行的改动不会更新Prod数据库的Version name
应用情况：
l Folders - Folder Name
l Forms - Form Name, Form Help Text, View and Entry restrictions
l Fields - Header Text, Field Label, SAS Label, SAS Format, Help Text, Entry Restrictions, and View Restrictions
l Edit Check，Derivation, Custom Function
在上述内容需要改动时，可以直接用Quick Publish进行变更，不需要 Migration。
修改步骤：
1. 新建Draft(copy自prod的version)，在此Draft下根据变更需求表修改数据库，在最新Draft下，新建Version(一般以_Quick Publish结尾)，并Push到测试使用的Site，进行测试，直到没问题；
2. 告知DM进行测试，然后根据DM反馈修改数据库，直到DM测试通过;
3. 收到签署完成的《数据库上线批准表》，进行正式数据库变更；
4. 如果正式库Subject存在Publish Check失败的，需查找原因，再执行以上修改，测试（需注意：Publish Check操作是没办法测试的）；
5. 不管Publish Check结果如何，都需要在正式库版本中查看需要修改的内容是否已按照要求修改。
6. 确认修改无误后，导出相关文件，并通知DM此次Publish Check已完成。
Migration
此操作会更新Prod数据库的Version name
应用情况：
l 涉及Quick Publish之外的改动，例如field增删，matrix结构的变动，会使用Migration
修改步骤：
1. 新建Draft(copy自prod的version),在此Draft下根据变更需求表修改数据库，在最新Draft下，新建Version(此Version name为DM确认过的重新上线Version)，并Push到测试使用的Site，进行测试 ，直到没问题；
2. 告知DM进行测试，根据DM反馈修改数据库，直到DM测试通过;
测试迁移：
l DBD准备两个数据库环境（MIG-Pre，MIG-Post），创建迁移计划，将正式库的数据复制到MIG-Pre，执行迁移计划；
注意点：
1. 修改数据点的OID，需要在Migration时作手动映射；
2. 修改变量的Dictionary选项，增加/修改选项直接改即可，删除选项需要对已有受试者执行do not migrate；
3. Checkbox改为Radiobutton，已有值无法migration到新版，执行migration plan 对变量勾选do not migrate；
4. Log变量修改为非Log变量：最好inactive log变量，新增非log变量;如果不新增，在原变量上修改，需要对已存在受试者选择do not migrate；
5. 在特定访视默认出现的表单进行新增/删除，需要写Rule；
6. 对Check , CF, Derivation的修改同Publish Check；
l 将MIG-Pre的受试者数据迁移到MIG-Post中；
l DBD导出Pre、Post环境的数据集，进行迁移前后数据集比对；
l DBD导出测试迁移报告(CRF Difference Report, Migration Audit Trail Report, Subject CRF Versions, Sas Compare Result)并配合EDC数据进行迁移结果确认，没问题则将测试迁移报告给到DM审阅；
l DM查看测试迁移报告和EDC数据，确认迁移测试没问题后，通知LDBD收到签署完成的《数据库上线批准表》后即可根据项目组约定的迁移时间，执行正式数据库迁移。
正式迁移：
l DBD、DM分别导出正式迁移前正式环境的数据集；
l DBD将上线版本Push到正式环境，并截图保存；
l DBD执行迁移计划，将正式库数据迁移到目标版本；
l DBD rebuild & refresh clinical view；
l DBD、DM分别导出正式迁移后正式环境的数据集；
l DBD导出正式迁移报告(CRF Difference Report, Migration Audit Trail Report, Subject CRF Versions, Sas Compare Result)并配合EDC数据进行迁移结果确认，没问题则将迁移报告给到DM审阅，同时附上线截图，告知正式库已经完成迁移；
l DM查看迁移报告和EDC数据，没问题则通知项目组迁移完成。
Migration过程中若发现问题，则解决问题，并重新执行相应的步骤。
Note：
正式迁移前DM需通知项目组在正式环境migration期间不可以进入EDC进行操作；
DM需告知DBD上线版本/DBD需向DM确认上线版本。
Push：
如果数据库上线后需要EDC的变更，此时还没有受试者入组的话，那么就可以选用Push方法。
此操作会更新Prod数据库的Version name
修改步骤：
1. 新建Draft(copy自prod的version)，在此Draft下根据变更需求表修改数据库；
2. 在最新Draft下，新建Version(此Version可为再次上线使用的Version)，并Push到测试使用的Site，随后DBD根据变更申请单的要求修改数据库，完成后告知DM进行测试;
3. 直到测试通过，并获得DM上线新版本通知后，将更新后的版本，直接push到正式库site即可（需提供Push成功截图给到DM）。
OK，今天的内容就到这里啦，更多关于Rave数据迁移知识，欢迎留言补充与讨论。
