越来越多的企业用内容管理系统来管理电子发票，电子文档，人力资源等结构化或非结构化数据内容，而且把这些业务外包到第三方的 IT 公司。外包公司的更换，或者现有内容管理系统不能满足业务增长，性能，兼容性等方面的需要，企业计划采用业务管理，性能以及兼容性更好的系统。 还有的企业目前根本没有采用内容管理系统，所有的发票，电子文档，人力资源信息都是以纸质文字或者档案的形式管理维护，为了提高企业的运营效率，这些企业计划采用内容管理解决方案。
如何在不干扰现有业务的基础上把这些内容数据从一个系统迁移到另外一个系统，如何做到无缝迁移，并且在迁移的过程中保证数据的完整性，兼容性以及数据的安全？这样我们就需要一个系统的迁移方案。本文着重解析和介绍了一个从分析 -> 设计 -> 实施 -> 系统切换的内容数据迁移流程。其中分析主要从源内容管理系统，现有业务逻辑，以及目标系统的分析三个方面进行。 实际包括目标系统的设计和迁移计划的设计。
实施主要包括，搭建目标数据管理系统，实施内容迁移 以及对迁移数据的清点和对账。 系统切换主要指新老系统的切换以及老系统的退役处理。
源内容管理系统分析
为了确保新系统能够完全兼容现有系统的业务需求，确保现有业务逻辑不被数据迁移所干扰，我们需要对现有内容管理系统进行详细的评估和分析。并且制定详细的文档信息，表格模版。 这些文档信息主要包括：
1. 现有内容管理系统的技术以及业务负责人，我们需要搜集整理这些负责人的职务，联系方式，主要负责的应用程序等信息。 表 1是一个简单的例子：
表 1. 联系信息
| AppID | AppName | Business | Contact Name | Phone# | |
|---|---|---|---|---|---|
| 1 | CM | BusinessProcess | Mary | mary@aaa.com | 7012111 |
| 2 | DB2 | Database | John | john@aaa.com | 7012112 |
| 3 | Scanner | Image Scan | Peter | peter@aaa.com | 7012113 |
| 4 | LDAP | Security | Candy | Candy@aaa.com | 7012114 |
2. 现有内容管理系统架构 , 如 图 1所示
图 1. 内容管理系统架构图示例
3. 现有内容管理系统的数据模型
数据模型就是企业级内容管理产品用来实现复杂和多变的元数据标准和数据结构信息。客户化定制不需要任何系统设计和编程，直接利用数据模型来实现。
图 2所示是一个内容管理系统的数据模型图，通过这个模型，可以客户化定制 Folder，Document, Item， Item attribute 等数据存储系统所需的数据类型。这个模型的特点如下：
- Folder 作为一个容器，可以容纳 Documents 或者其他的 Folders
- 用 Folder 的 attributes 用来描述这个 Folder 的信息。
- Document 也可以包含其他的子组件，比如附件等。
- 用 Document 的 attributes 来描述这个 document 的信息。
- Document 可以用 ItemType 来分类整理。
图 2. 内容管理数据模型结构图
4. 现有内容管理系统的软硬件信息，表 2中的表定义可以作为参考：
表 2. 系统软硬件信息表定义
| 列名 | 列描述 |
|---|---|
| App ID | 软硬件资源编号 |
| App Name | 软硬件资源名称 |
| App Description | 软硬件资源的描述信息 |
| App Type | 资源类型， 是软件，硬件，还是软硬件都包括 |
| App Environment | 是分布式的，还是集中式 |
| SLA | 服务质量协议 |
| Retention period | 数据保留时间，如：月，日，年 |
| AO | 资源可用度，比如大于 99.95% 的月可用度 |
| Weekend Down Time | 周末允许的变更时间 |
| Sunset Date | 退役时间 |
| TimeZone Sensitive | 软硬件资源的时区敏感性 |
5. 现有内容管理系统的安全策略
通常我们都会采用基于角色的系统安全控制方法，也就是通过分配和取消角色来授予或者取消用户权限。 通过访问权限和角色关联关系， 角色和用户的关联关系来实现用户和访问权限的逻辑分离。表 3，表 4，表 5所示是一个访问安全控制示例。
表 3. 访问权限控制对象
| ItemType | D_APInvoice |
|---|---|
| ItemType | D_HRDocument |
| ItemType | D_AP_ReadOnly |
| Process | P_AP_Process |
| Process | P_HR_Process |
| WorkList | W_AP_Index |
| WorkList | W_HR_ReScan |
| Menu | M_Search |
| Menu | M_CreateFolder |
| Report | R_WorkFlow |
| Document Function | F_Delete |
| Process Function | F_StartOnProcess |
表 4. 角色定义
| 角色 | 内容管理组 |
|---|---|
| BasicOperator | D_APInvoice, D_HRDocument, P_AP_Process, P_HR_Process, W_AP_Index, M_Search, M_CreateFolder, R_WorkFlow |
| TeamLead | D_APInvoice,D_HRDocument,P_AP_Process,P_HR_Process,W_AP_Index,W_HR_ReScan, M_Search,M_CreateFolder,R_WorkFlow,F_Delete,F_StartOnProcess |
| ReadUser | D_AP_ReadOnly, M_Search |
| SupportUser | D_APInvoice, D_HRDocument, P_AP_Process, P_HR_Process, W_AP_Index, W_HR_ReScan, M_Search, M_CreateFolder, R_WorkFlow, F_Delete, F_StartOnProcess |
表 5. 用户定义
| 用户 | 角色 |
|---|---|
| John | TeamLead |
| Robert | ReaderUser |
6. 现有内容管理系统的业务流程
对现有系统业务逻辑的分析和深入了解是内容迁移至关重要的一个环节。通过分析我们需要获取如下的信息：
- 客户的业务逻辑需要什么级别的可用性要求。例如，业务发票处理， 人力资源信息，金融信息，不同的业务逻辑对系统的可用性要就是不一样。
- 业务峰值时间段。
- 历史业务数据量，以及未来业务数据量的估计。
- 业务可容忍的数据丢失量。
- 如何弥补业务丢失的业务数据。
通常情况下我们用业务流程图来记录和分析现有业务逻辑。
图 3. 流程定义图
我们用 表 5所示的表来记录来描述年或者月或者季度业务数据量， 其中 source location 是指内容数据来源，Debit Memos,Expense Reports,Invoice Intercompany,Invoice Non PO,Invoice PO 是指 5 个不同的数据类型， Grand Total 是数据汇总。
表 6. 业务数据量统计表
| Source Location | Debit Memos | Expense Reports | Invoice Intercompany | Invoice Non PO | Invoice PO | Grand Total |
|---|---|---|---|---|---|---|
| DemoA - Czech | 150 | 167.65 | 3185.35 | 3503 | ||
| DemoA - Denmark | 0 | 0 | 0 | |||
| DemoA - Finland | 0 | 0 | 0 | |||
| DemoA - France | 852 | 1500 | 3600 | 1026.9 | 5819.1 | 12798 |
| DemoA - France/Iberia | 3210 | 2457 | 1365 | 0 | 7032 | |
| DemoA - Germany | 7734 | 150 | 883 | 524.4 | 2097.6 | 11389 |
| DemoA - Italy | 375 | 5000 | 300 | 700 | 6375 | |
| DemoA - Norway | 0 | 0 | 0 | |||
| DemoA - Russia | 1726 | 0 | 1726 | |||
| DemoA - Sweden | 0 | 0 | 0 | |||
| DemoA - Switzerland | 719 | 940 | 0 | 1659 | ||
| DemoA - UK | 1649 | 0 | 3465 | 0 | 5114 | |
| DemoB - Denmark | 75 | 423 | 488 | 0 | 986 | |
| DemoB - Finland | 75 | 539 | 455 | 0 | 1069 | |
| DemoB - France | 412.5 | 5240 | 3313.12 | 63.8797 | 9029.5 | |
| DemoB - Germany | 150 | 859 | 70 | 0 | 1079 | |
| DemoB - Italy | 300 | 0 | 2000 | 0 | 2300 | |
| DemoB - Netherlands | 187.5 | 0 | 47 | 0 | 234.5 | |
| DemoB - Norway | 317 | 488 | 0 | 805 | ||
| DemoB - Sweden | 300 | 918 | 3887 | 1001 | 6106 | |
| DemoB - UK | 225 | 922 | 4803.11 | 1078.89 | 7029 | |
| Grand Total | 14878 | 3937.5 | 22094 | 31240.6 | 14183.4 | 86333.5 |
7. 现有内容管理系统的服务质量，问题或缺陷
如 表 7，表 8所示，可以用 SERVQUAL 来评估服务质量， 以及问题和缺陷。
表 7. 业务数据量统计表
| SERVQUAL Dimension | Weight Score |
|---|---|
| Tangibility | 11 |
| Reliability | 32 |
| Responsiveness | 22 |
| Assurance | 19 |
| Empathy | 16 |
表 8. 问题和缺陷总结
| 列名 | 列描述 |
|---|---|
| ProblemID | 问题编号 |
| Category | 问题类别 |
| Description | 问题描述 |
| Priority | 问题的优先级 |
| Impact | 问题的影响 |
目标数据管理系统分析设计
如同源内容管理系统分析一样，我也需要对目标内容管理系统进行详细的评估，分析和设计。并且制定详细的文档信息和文档，表格模版。 这些文档信息主要包括：
- 目标内容管理系统的技术以及业务负责人，我们需要搜集整理这些负责人的职务，联系方式，主要负责的应用程序等信息。联系表的设计可以参考 表 1
- 目标内容管理系统架构，内容管理系统架构图可以参考 图 1
- 目标内容管理系统的数据模型，数据模型的设计可以参考 图 2
- 目标内容管理系统的软硬件信息，可以参考 表 2
- 目标内容管理系统的安全策略，可以参考 表 3, 表 4, 表 5
- 目标内容管理系统的业务流程设计可以参考现有系统的业务逻辑，并进一步分析业务需求对现有业务逻辑进行升级改进。业务流程图和数据量分析可以参考 图 3和 表 6
- 目标内容管理系统的服务质量，问题或缺陷，可以参考现有系统。
迁移实施计划
在对源内容管理系统和目标内容管理系统进行了详细的分析和设计后，我们就需要着手创建详细的迁移实施计划，一个迁移项目的成功与否，关键在于确保迁移前后业务产品的持续性和可用性。 因此在制定计划前，我们需要进行一些深入的调查工作，如：
- 调查应用程序之间的系统依赖性。
- 调查数据的类型，以及类型之间的数据依赖关系
- 源内容管理系统和目标管理系统的时区关系
- 调查源内容数据和目标数据的映射关系
- 调查源内容管理系统和目标内容管理系统的文件系统以确保合理的数据迁移包的大小
- 根据数据的映射关系和业务逻辑创建相应数据迁移包
- 调查源内容管理系统和目标内容管理系统的数据传输参数
- 调查源内容管理系统和目标内容管理系统的安全策略
当获得所有的调查信息后，接下来我们需要计划迁移的阶段以及时间线。 表 9是一个迁移阶段定义的示例。
表 9. 迁移阶段定义
| 阶段 | 描述 |
|---|---|
| 分析 | 分析数据容量，数据结构，数据有效性。 |
| 迁移前数据清洗 | 在数据导出之前，基于源内容管理系统对数据进行清洗，塑形。 |
| 导出 | ParternerA 将源内容的图像，源文件以及元数据从源内容管理系统导出并且用加密硬盘运送给 IBM。 |
| 加载前的数据转化 | 重新分析元数据并对源文件进行排序分类。 |
| 数据传输加载 | 步骤 1 – 把加密硬盘上的数据上传到目标系统 SFTP 上。 步骤 2 – 将数据从 SFTP 拷贝到目标内容管理系统文件系统上。 步骤 3 - 通过目标内容管理系统的接口将源内容加载到目标内容管理系统，并进行详细的日志记录。 步骤 4 – 加载过程中的异常处理和日志分析 |
| 加载后数据转化 | 在目标内容管理系统上，对加载后的数据进行更详细的数据分类整理。 |
| 对账 | 用报表系统对迁移前后的内容进行对比，并产生详细的报表数据。 |
在具体的计划中每一个阶段都有详细的文档描述输入，输出及其处理工具流程。除了迁移计划，我们还需要制定详细的回滚计划，如果数据加载失败，如何进行回滚，回滚的步骤，以及回滚数据的粒度。
搭建目标数据管理系统
根据对源和目标内容管理系统的分析设计文档，首先我们需要搭建目标数据管理系统安全策略，数据模型，数据模型是整个内容管理系统的基础。接下来我们需要建立整个内容管理系统的安全模型。最后建立内容管理系统的业务流程。
搭建完系统后，我们需要进行单元测试，系统整合测试，系统性能测试，用户接收测试。
实施迁移
根据制定的迁移计划实施迁移，最主要的实施过程就是从老系统里导出数据，然后导入到新系统中。
数据迁移过程中最重要的环节是对迁移过程中的信息处理日志管理。
数据清点和对账
对比迁移前后的内容数据，并产生对比报表。
表 10. 对账报表定义
| Report | Description |
|---|---|
| 数量统计 | 根据日期的数量统计 更具文档类型的数量统计 |
| 异常情况 | 根据业务逻辑列出所有的异常情况，并对异常情况下的内容进行统计。 例如：在一个 HR 的内容管理系统中，每个员工都必须有身份证复印件的内容文件。 这样在报表中我们就需要统计出没有身份证复印件的记录。 |
| 随机检测 | 在新系统中随机抽取一定数量的内容，和老系统的图片，文档，元数据进行比较。 在老系统中随机抽取一定数量的内容，和新系统中的图片，文档，元数据进行比较。 |
系统切换
为了减少对业务的影响，保证业务系统在迁移过程中的服务质量，我们还需要选择最适合系统业务的系统切换方式。
通常我们有 3 种系统切换方式：
- 直接切换： 在确保新的内容管理系统运行准确无误时，在某一时刻终止源内容管理系统，启用目标内容管理系统。这种转换方式费用低，方法简单，但风险大。
- 并行切换： 源内容管理系统和目标内容管理系统并行工作一段时间，在确保目标内容管理系统运行准确无误时，替代源系统。这种转换方式有利于减小切换压力、安全性较好，但费用高。
- 分段切换： 即直接转换和并行转换的结合，分阶段将目标内容管理系统的各个子系统替代源系统。这种转换方式安全性较好，但费用高。
通常我们采用分段切换作为内容管理系统的切换方式。图 4所示是分段系统切换的时序图 .
图 4. 系统切换时序图
结束语
本文按照分析 -> 设计 -> 实施 -> 系统切换的内容数据迁移流程，针对内容管理系统的特点和实现方式，作者通过项目实践，总结了 8 个步骤，具体分析内容数据的迁移方案。
- 源内容管理系统分析 - 创建详细的文档信息和模版
- 业务逻辑分析
- 目标数据管理系统分析 - 创建详细的文档信息和模版
- 迁移实施计划
- 搭建目标数据管理系统 - 创建详细的文档信息和模版
- 实施迁移
- 数据清点和对账
- 新老系统切换策
并介绍了系统迁移过程中各个步骤中的具体活动以及所需获取的信息，给出信息整理的文档模板，以及以图片，表格形式整理的信息示例。希望能对您的工作提供帮助。
原文地址：http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1211wangr/index.html?ca=drs