我们的客户有一个完全定制的 CMS，它内置在 ASP 1.1 中，后来升级到 2.0。该数据库有 200 多个表，不幸的是，没有 ASP 代码或数据库的文档。无法询问原始开发人员，我公司中没有人熟悉设置。
大多数数据库表没有时间戳列，因此仅通过检查很难确定哪些表正在使用，哪些未使用。增加任务的复杂性是，对于 CMS 中的每个门户站点，已经开发了使用单独的数据库表的自定义功能，有时还使用存储过程来处理单独的客户端站点的数据。
从事这个项目的原始开发人员已经走了，它意外地被放在了我的盘子里。我的任务是将现有 CMS 中的所有数据（包括每个模块和每个客户端站点的数据）移动到带有我们正在开发的自定义模块的 DotNetNuke 安装中。我收到的估计是三周。
如果有人以前尝试过这样的任务：这在三周内可行吗？我以前从未尝试过如此大规模的数据迁移，任何有关策略的帮助都会有所帮助。
首先是坏消息：可能不是。（我不是在考虑 3 个日历周：不是 140 个工时分布在更长的时间段内）。
原因是您没有任何有点“不寻常”的文档 - 程序中的奇怪行为、修复错误的黑客行为、数据不一致、数据污染等。鉴于没有文档，你不能指望一流的数据验证或模型。（它可能存在：只是不能保证）。
这只是技术原因：当您说“我们正在开发的自定义模块”时，警报就会响起。你的项目太不稳定了，需要各方之间进行太多的交谈。
至于策略：我会确定每个系统核心的 80% 通用功能，并且只需要 20% 的努力来转换。你有代码和数据库：把它放在一个测试服务器上，让一些用户运行常见的操作。将跟踪/日志记录到您的代码中，看看会发生什么。在您的表上放置时间戳列或审计跟踪，并查看您的数据库中的哪些变化。
祝你好运！
几年前我参与过一个类似的项目。最初的计划是三个月，但最终我们花了六个月的时间才投入生产。该系统是具有公共网站前端的关键订单处理应用程序。大约 40 名后台用户同时从旧系统切换到新系统。
大多数延迟是由于“自定义模块”应用程序开发部分造成的，但迁移肯定花费了 3 周多的时间。源数据库具有良好的规范化设计，带有外键约束甚至一些文档。最终，迁移所需的表不到 50 个。但是对旧系统进行逆向工程仍然需要一段时间。数据库中使用的视图定义在此过程中提供了很大帮助。
除了提取阶段之外，开发到目标的转换也需要相当长的时间。目的地所需的转换在项目期间发生了一些变化。如果您的目标架构现在大部分已修复，那肯定会有所帮助。上线后还需要对数据迁移进行多次更正，因为目标中已经有新数据并且无法再完全重新加载。
我建议您使用任何技术进行迁移，开发它，以便该过程是自动的且易于重复。我在我的项目中使用了 SSIS。在您投入生产之前，您可能需要多次初始化和重新加载测试系统的目标数据库。测试系统中大部分时间都有一些真实数据，即使只迁移了少数表，这也有助于应用程序测试。