脚本是最常见的工作用具。写脚本的好处在于它们是针对特殊环境、存储、服务器、应用程序、供应商和基础架构定制的。坏处在于它们一般来说很少记录、进行质量测试、打补丁、或者随环境变化更新；必须为了每一个SAN存储数据迁移项目重新编写。
对于使用外置SAN存储虚拟化设备简化SAN存储数据迁移的期望很高，而且宣传也很多。它之所以做到这一点是它允许在虚拟化设备/系统后端的存储系统，在完全不用触及虚拟化设备/系统前端的服务器或者架构的情况下迁移。与之相来的代价则是它添加了相当可观的成本，从而增加了总体拥有成本。同样管理该虚拟化设备/系统和后端的存储阵列也增加了相应的复杂度。另外，所有的设备/系统都有着扩展性上的局限，受限等同与或者稍大于位于前端的存储系统。在需要更新换代时，有些甚至增大了数据迁移复杂度（虚拟化设备/系统和后端的存储系统都需要迁移）。
VMware公司的存储vMotion正成为另一个流行的工作区。它把所有指派给VMware服务器的物理SAN存储阵列的LUN迁移到新SAN存储阵列的LUN上。指派给单独的虚拟服务器的虚拟LUN不发生变化，屏蔽了事实上在存储阵列中发生的物理改变。缺点在于它仅仅适用于运行在VMware架构中的虚拟机。它也没有提供任何SAN路径纠正或VMware虚拟服务器纠正。它也不能够迁移没有指派特定VMware服务器的LUN，同样也没有数据迁移测试或者检验功能。
另一个工作区是由SANpulse提供将软件、脚本和服务打包在一起的SANlogics。SANlogics可以自动完成27个SAN存储数据迁移步骤和另外2个半自动步骤。它能够减少很多步骤中的人为错误；然而，今天它只能在EMC公司和HDS公司的存储系统上工作，也需要EMC、HDS或者赛门铁克公司的数据迁移工具。
SAN存储数据迁移一直是一个让人畏惧的工程。这也是为什么中小型企业一般会选择他们的SAN存储供应商提供的数据迁移专业服务。当然，这项服务非常昂贵。但它能让你的存储供应商负起责任。然而即这种工作区也有问题。它也不会自动化任何这些过程，相反的，它只是把相应的责任外包出去而已。
数据迁移中决定成败的是你的选择、计划、行为准则，专注和对细节的注意。
TAG: 时间
