帮助估计数据迁移

Question

我们的客户有一个完全自定义的CMS，内置在ASP 1.1中，后来升级到2.0。该数据库有200多个表格，不幸的是，没有关于ASP代码或数据库的文档。原始开发人员无法提问，我公司也没有人熟悉该设置。

大多数数据库表没有时间戳列，所以很难从检查中确定哪些表正在使用中，哪些不在。增加任务的复杂性是，对于CMS中的每个门户站点，已经开发了使用单独数据库表的定制功能，并且偶尔存储过程用于处理单个客户端站点的数据。

在这个项目上工作的最初的开发人员已经不在了，它已经被意外地放在了我的盘子上。我负责将现有CMS中的所有数据（包括每个模块和每个客户端站点的数据）转移到我们正在开发的定制模块的DotNetNuke安装中。我上交的估计是三周。

如果有人曾经尝试过这样的任务：这是三周内可行吗？我以前从未尝试过如此大规模的数据迁移，并且任何策略帮助都将有所帮助。

Answer 1

从坏消息开始：可能不是。 （我没有想到3个日历周：不是140个工作时间在更长的时间内传播）。

原因是你没有任何有点'不寻常'的文档 - 程序中的奇怪行为，修复错误的黑客，数据中的不一致性，数据污染等等。鉴于事实上没有文档，你不能期望顶尖的数据验证或模型。 （它可能存在：它只是不能保证）。

而这只是技术上的原因：当你说'我们正在开发的自定义模块'时，警钟正在熄灭。你的项目过于流行，需要各方进行太多谈话。对于策略：我将确定每个系统核心的80％通用功能，并且只需要20％的努力进行转换。你有代码和数据库：把它放在测试服务器上，让一些用户通过常见的操作来运行。在你的代码中添加跟踪/日志记录，看看有什么命中。在表上放置时间戳列或审计线索，并查看数据库中的更改。

祝你好运！

Answer 2

几年前，我一直在类似的项目。最初的时间表是三个月，但最终在我们投入生产之前需要六个月。 该系统是一个公共网站前端的关键订单处理应用程序。大约40名后台用户从旧系统切换到新系统。

大部分延迟都是由于“自定义模块”应用程序开发部分所致，但迁移时间绝对超过3周。 源数据库有一个体面的标准化设计与外键约束，甚至一些文件。最后，迁移中不到50张表格。但是对旧系统进行逆向工程还需要一段时间。在这个过程中，数据库中使用的视图定义帮助了很多。

除了提取阶段，它也花费了相当多的时间来发展到目标的转变。在项目期间，目的地所需的转换有所改变。如果您的目标架构现在大部分已经修复，它肯定会有帮助。上线后还需要对数据迁移进行多次更正，当目标中已经有新数据并且无法完全重新加载时。

我会建议任何技术，您正在使用的迁移，发展它，这样的过程是自动，容易重复。我在我的项目中使用了SSIS。在您投入生产之前，您可能需要多次初始化并重新加载测试系统的目标数据库。对于应用程序测试来说，在大多数情况下测试系统中都存在一些真实数据，即使只有少数几个表已被迁移也是有帮助的。