.net 帮助评估数据迁移

我们的客户有一个完全定制的CMS，它是在ASP 1.1中构建的，后来升级到2.0。该数据库有200多个表，不幸的是，没有ASP代码或数据库的文档。最初的开发人员无法提问，我的公司也没有人熟悉这个设置

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

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

---

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

从坏消息开始：可能不会。（我不认为是3个日历周：在更长的一段时间内不会有140个工时）

原因是您没有任何“有点不寻常”的文档——过程中的奇怪行为、修复bug的黑客、数据中的不一致、数据污染等。鉴于没有文档，您也不能期望一流的数据验证或模型。（它可能存在：只是不能保证）

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

至于策略：我将确定80%的通用功能，这是每个系统的核心，只需要20%的努力就可以转换。您有代码和数据库：将其放在测试服务器上，让一些用户运行常见的操作。将跟踪/日志记录放在代码中，查看命中的内容。在表上放置时间戳列或审计跟踪，然后查看数据库中的更改

---

祝你好运

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

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

除了提取阶段外，还需要相当长的时间才能实现目标转化。目标所需的转换在项目期间发生了一些变化。如果您的目标模式现在已经基本固定，这当然会有所帮助。上线后，当目标中已有新数据且无法完全重新加载时，还需要对数据迁移进行多次更正

我建议您开发用于迁移的任何技术，以使迁移过程自动且易于重复。我在我的项目中使用了SSI。在投入生产之前，您可能需要多次初始化和重新加载测试系统的目标数据库。对于应用程序测试来说，即使只迁移了几个表，测试系统中大部分时间都有一些真实数据，这也很有帮助。

3周？至少可以说，做出这一估计的人是一个乐观主义者。至于这个问题，这完全取决于你必须在DotNetNuke上重新编码的“特性”的数量。如果有那么多“定制功能”，这可能需要几个月的时间。