最近，一位同事发给我一篇行业文章，关于一个被健康保险困扰的供应商 (“Medibank 仍在与头痛的数据迁移做挣扎着”)。我告诉你残酷的细节，足以说明，当你的CEO公开说你的最新数据混乱的 “ 不可接受 ”，你可能后悔早点花你的圣诞奖金。

我没有 Medibank 项目的具体细节 (很显然，他们不是我们公司的客户)，但是他们出现的问题是我们之前见过很多次的：由（可能）严重计划的迁移造成的意外中断。 在Medibank的案件中作出判决之前，充分规划像数据迁移这样复杂的东西并不容易，尤其是当你使用传统的方法来做到这一点。例如，使用传统工具（如基于主机的镜像或将灾难恢复/恢复工具推入服务）需要为每个主机手动详细映射，跟踪每个磁盘对每个SAN结构和存储帧的依赖性，并重复主机到存储的过程。混合这些问题，不同的操作系统平台和存储系统都有自己独特的发现过程。你需要是一个专家，只是为了正确地进行预测规划发现，即使你确定了发现和规划阶段，事故和人为错误仍可能破坏该过程。

Golden Spreadsheet or Fool’s Gold?黄金电子表格还是傻瓜的黄金？
由于数据迁移中固有的复杂性，IT 部门经常要寻求快捷的方法。“黄金电子表格”就是一个很好的例子。每个IT部门都有一个：据称是权威的电子表格，它包含所有的存储到主机的分配。然而，IT 部门很快意识到，并不是所有闪烁都是黄金的。一组 LUN（逻辑单元号）丢失或迁移到错误的 SAN 结构，突然导致一个“不可接受”的问题，甚至可能导致最可怕的迁移方案，数据丢失。

综上所述，我们在 Cirrus Data 中建立了新的黄金数据迁移标准：数据迁移服务器（DMS）。 DMS 的自动发现功能可自动生成关于企业的 SAN 拓扑结构，LUN，FC 端口，交换机（无论网络设计有多复杂）及其之间的所有连接的准确且详细的信息。DMS 减少了复杂的预迁移发现的问题，并计划到一个简单的目测发现资源和对黄金电子表格的快速比较。（它还会在别人指出之前纠正您的黄金电子表格中的错误，这是它发光的地方。）

我可以飞快说出任何数量的案例研究来向你展示 DMS 是如何的不同，不需要去说比我们第一位客户更远的了。这是在9月的一个星期六，我们只是拖着一对 DMS-4000s来到客户的码头（实际上，在当时而言，它们已经很小了）。 我们早上10:00到达，在所有迁移会话完全建立之后，中午1:02离开。在这182分钟之间，101 分钟等待客户创建和分配新的目标 LUN（尽管事实上我们已经要求他们提前这样做，但你知道怎么回事…），剩下的32 分钟识别和标记自动发现的 LUN （如果他们能预先准备文本文件，将只需要几秒钟，但是和我们其他的请求一样没有得到回应），然后大约8分钟左右的寒暄和坐电梯时间。所以，事实上只花费了 41 分钟的时间来安装DMS-4000s，打开电源，连接电缆，更新软件，插入客户的光纤通道结构，并创建迁移会话。至于 LUN 的迁移，DMS 只需要五分钟的切换时间 — 但是花了客户几周才找到这五分钟。当割接完成后，应用程序所有者表示惊讶; 他们甚至不知道迁移过程什么时候开始的，更不用说完成了。

这是四年多前。我们刚刚完成将DMS版本4发布到市场，并进行了一些重要的增强。例如，记得在上面的示例中提到需要 101 分钟来创建和分配新的 LUN 吗？ DMS v4的自动分配功能现在可以在几秒钟内自动完成。最新版本的 DMS 还支持将数据迁移到云中，包括 Amazon Web Services，Microsoft Azure 和 IBM 的 SoftLayer。

所有我所要说的是，任何公司都不应该经历 Medibank 正在经历的痛苦的过程。使用正确的工具，发现和计划的过程可以大大被简化，执行过程自动化，减少错误。因为数据迁移不应该意味着以假定的别名迁移到世界的另一部分，来逃避愤怒的客户。