帮助评估数据迁移

Question

我们的客户有一个完全自定义的CMS，它是在ASP1.1中构建的，后来升级到了2.0。该数据库有200多个表，不幸的是，没有关于ASP代码或数据库的文档。最初的开发人员无法接受询问，我的公司也没有人熟悉这种设置。

大多数数据库表没有时间戳列，因此仅通过检查就很难确定哪些表正在使用，哪些表没有使用。增加任务复杂性的是，对于CMS中的每个门户站点，都开发了自定义功能，该功能使用单独的数据库表，有时还使用存储过程来处理单个客户端站点的数据。

原来负责这个项目的开发人员已经走了，它出乎意料地被放到了我的盘子里。我的任务是将现有内容管理系统中的所有数据，包括每个模块和每个客户端站点的数据，移动到我们正在开发的带有自定义模块的DotNetNuke安装中。我得到的估计是三个星期。

如果有人以前尝试过这样的任务:这可以在三周内完成吗？我以前从未尝试过如此大规模的数据迁移，任何有关策略的帮助都会有所帮助。

Answer 1

首先是坏消息:可能不会。(我不是在考虑3个日历周:不是大约140个工时分布在更长的时间内)。

原因是你没有任何文档来处理任何有点“不寻常”的事情--过程中的奇怪行为，修复bug的黑客攻击，数据中的不一致，数据污染等等。鉴于没有文档，你也不能指望顶级的数据验证或模型。(它可能存在:只是不能保证)。

这只是技术上的原因:当你说“我们正在开发的定制模块”时，警钟就会响起。你的项目有太多的变化，需要各方进行太多的讨论。

至于策略:我将确定80%的公共功能，这是每个系统的核心，只需要20%的努力就可以转换。您有代码和db:将其放在测试服务器上，并让几个用户运行常见的操作。在你的代码中加入跟踪/日志记录，看看会发生什么。在您的表上放置时间戳列或审计跟踪，并查看数据库中的更改。

祝好运!

Answer 2

几年前我也参与过一个类似的项目。最初的计划是三个月，但最终我们花了六个月才投入生产。该系统是一个具有公共网站前端的关键订单处理应用程序。大约40名后台用户立即从旧系统切换到新系统。

大多数延迟是由于“自定义模块”应用程序开发部分，但迁移肯定花了超过3周的时间。源数据库具有良好的规范化设计，带有外键约束，甚至还有一些文档。最终，迁移过程中只需要不到50个表。但对旧系统进行逆向工程仍然需要一段时间。在这个过程中，数据库中使用的视图定义帮助很大。

除了提取阶段，还需要相当长的时间才能将转换发展到目标。目标所需的转换在项目过程中发生了一些变化。如果您的目标模式现在基本上是固定的，那么它肯定会有所帮助。在数据迁移上线后，当目标中已经有新数据并且不能完全重新加载时，还需要对数据迁移进行多次更正。

我建议无论您使用哪种技术进行迁移，开发它的过程都应该是automatic和easily repeatable。我在我的项目中使用了SSIS。在投入生产之前，您可能需要多次初始化和重新加载测试系统的目标数据库。测试系统中大部分时间都有一些真实的数据，即使只迁移了几个表，这对应用程序测试也很有帮助。