当涉及到数据迁移，你从专家那得到的大多数建议听起来就像是，你在孔子开的餐厅收到的幸运饼干。
得到明显的意见很容易，就像 “找到那个能相信的人” ，或者 “避免停机时间和减少风险” ，或者 “找到可以自动做一切事情的工具”。但是实际且特别的建议可能更有帮助些。孔子是一个明智的人，但是对于数据迁移，我们就应该自己去发现时代的智慧。分析我们参与的企业级迁移项目，发现成功案例都有一些共同的特点。大多数可以归结在下列问题的答案：
正在迁移哪种类型的数据？
确定所迁移的数据的类型是很重要的，因为有不同的迁移类型。
- NAS-based – 网络共享从一个系统迁移到另一个
- LUN-based – 磁盘（LUN）以块级别从一个存储迁移到另一个
- VM-based – 整个虚拟主机从一个虚拟机管理程序迁移到另一个
- Application-specific – 其中一组数据库或对象，从一个主机迁移到另一个
此外，整体迁移的类型有哪些？
- 本地迁移 – 同一数据中心内
- 远程迁移 – 从一个数据中心到另一个
- 云迁移 – 到云提供商 (例如, AWS, SoftLayer, Azure, Google Cloud)
当前的存储环境是怎样的？
同样重要的是有对当前的存储环境的合理理解。用 SAN 来举个例子，就操作系统而言，哪些主机和应用程序参与了？FC 交换机和 RAIDs 呢？ 最重要的是，SAN 的复杂性到底有多大和多紧密？操作的复杂性是指数增长的，并不直接关系到系统的大小。能轻易的理解图片的含义可以避免大量复杂的问题和消除灾难。
有多少数据正在被迁移？
不能足够强调一个正确且清晰的数据量估算必须被做出。此外，主机，LUN和存储系统的详细数目必须确定。通常情况下，所需要的努力不能仅仅由所需要迁移的字节量来判定。即使知道LUN的数量仍然只是故事的一半，在数据被迁移之后，主机的数量在确定所需的割接的时间和精力上可能是最大的因素。当然，数据量和数据速率将确定所需要迁移的绝对时间，但同样也存在别的影响因素。
总共将分配给该项目多长时间？
这几乎是显而易见的，它不可能是那么简单的问题。通常数据量是预先设定的，所有唯一的参数就是迁移速率。这再次凸显了理解数据，应用程序和环境的重要性，因为了解数据是否能被分割迁移对制定战略有帮助。 – 不仅要满足时限，而且要控制操作的复杂性，以及潜在的成本。
数据有多活跃和有多少可用的停机时间？
如果迁移能及时完成数据的积极性要怎样决定，或根本不能。这立即引发了一个问题 – 在迁移中多大的影响可以被容忍？此外，在割接过程中，可以允许多长停机时间？提前知道这些可以使得在迁移之前制定好协议和战略，也有助于在切换过程中减轻压力。
迁移最佳的工具是什么？
数据迁移工具的选择关系到该项目的成败。但是什么是特定的评价标准？
同样，以 SAN 迁移为例，一个迁移工具应该能：
- 尽量减少用于查找每个 WWPN，主机，存储目标，和每个 LUN 的 GUID，从而节省大量艰苦、枯燥而且容易出错的工作时间。
- 对生产环境无中断的完美安装，可使在准备和执行迁移的时候大大地减少风险。
- 为自动发现 SAN 配置提供一个清晰且直观的显示，完成主机所有的身份，状态验证和 I/O 数据，准备迁移的LUN(不被接触的也要)，这样，就有信心使迁移被正确有效的执行。
- 智能性和灵活性可以减少影响，甚至可以消除迁移过程中对产品的影响。例如，迁移在非生产时间段，或者自动产生生产业务，调节亮度/节流。
- 显示器，报告，和警报在迁移操作中以一个集中的方式，通常也包括有价值的状态和统计信息的产品贸易活动。
- 在切割之前执行终结图像的数据完整性检查，避免在生产被切换到新的存储器之前发生任何事情。
- 在数据被成功迁移出来之后，允许数据磁盘擦除，尤其是存储器出租后被返还。擦洗水平应变量，以允许高效的速度，或具有多遍安全擦洗模式，以确保数据被安全擦除。
- 提供一个清晰，准确，完整得迁移报告，详细说明在迁移过程中的每一步到底发生了什么，下至各个 LUN 的活动。
- 对给定类型的迁移，展示一个成功且客户满意度良好的跟踪记录（例如通过案例研究和参考的帐户）。
当然，符合上述描述的正是我们 Cirrus Data 的产品 DMS。因为这些功能和特征正是我们在用其他工具迁移时所想要有的。因为没有这样的产品存在，所以我们创造了它。
谁是适合这项工作的人？
现在我们又回到了孔夫子的智慧：首先，找到合适的人 — 无论是否使用内部人员或者外部专业服务伙伴 — 谁可以相信，谁有相关类型迁移项目的经验？你怎么知道他们是否真的合格？ 其实很简单：他们谁对以上问题给出了具体的答案，他们中谁又给了你一堆幸运饼干？
