邮件系统信创改造之数据迁移策略

本文主要阐述电子邮件系统在信创改造中的数据迁移策略，邮件源系统包括Exchange、Domino及国产非信创系统（自建模式），而目标系统则是以Coremail为代表的国产信创邮件系统（自建模式）。

1. 面临信创改造的邮件系统类型

1.1 国外邮件系统

在初期的邮件系统信创改造试点项目中，核心举措聚焦于将未达到信创包合规要求的邮件系统全面升级为符合信创标准的国产系统，这一过程尤其针对原采用如Exchange Server及Domino等国外品牌邮件系统的环境进行替换与升级。

1.2 未达到信创标准的国产邮件系统

对于已在使用但未达到信创标准的国产邮件系统及其运行环境，同样需实施信创改造。这包括两方面：

同一国产品牌系统内部的升级，如将非信创版本的Coremail系统升级为符合信创标准的Coremail信创版本。
将现有系统替换为其他符合信创标准且性能优异的国产邮件系统品牌，以实现全面的信创合规化。

1.3 邮件信创改造涉及迁移的数据类型

在邮件系统信创改造过程中，可能涉及如下几方面的数据迁移：

邮件数据：包括邮件服务器端邮件文件夹、邮件数据等。
用户和组织架构信息：包括用户姓名、手机号、部门、职位等数据。
用户日程信息：包括日历本、日程列表等。
用户自定义配置：如过滤器规则、黑名单、白名单等。
系统配置：如系统级别的黑名单、白名单、监控规则、反垃圾规则等。

注意：上述列出的数据并非全部需要迁移，需要根据项目的实际情况进行评估。

2. 数据迁移技术可行性分析

在小编所接触到的众多信创改造案例中，原系统大部分是自建模式，所以这里主要分析传统自建邮件系统迁移到信创自建系统的技术可行性。关于托管邮件系统（企业邮箱）的信创数据迁移，后续我们在其他文档单独讨论。

2.1 Exchange系统

Exchange系统架构相对复杂，它集成了多个核心组件，包括但不限于邮件服务器、客户端访问服务器、统一消息服务器、边缘传输服务器以及管理工具等，这些组件协同工作以提供全面的电子邮件、日历、联系人和任务管理等功能。但是，由于Exchange在业界广泛的应用基础和成熟度，针对Exchange数据的迁移技术方案反而显得相对简单和成熟。通过信创邮件厂商开发的迁移工具，可以对Exchange的如下数据类型进行迁移：

邮件：可以基于EWS协议（推荐）、IMAP协议来迁移邮件及用户文件夹数据。Exchange有完善的授权机制，可以授权特权用户迁移所有用户的邮件数据，不需要用户提供邮箱密码。
用户和组织架构：Exchange的用户和组织架构数据存储在AD（Active Directory）中，信创邮件系统可以通过LDAP协议迁移这部分数据。不过，用户密码无法直接通过LDAP协议迁移，可以考虑通过LDAP协议到AD上进行用户身份认证。
日程：在实际迁移案例中，日程数据的迁移往往面临相对较多的挑战，这主要归因于日程信息本身所包含的复杂细节以及缺乏跨平台或系统间统一的迁移规范。例如，可能遇到循环日程、国际时区等存在不兼容的情况。除非有强烈的需求，否则不建议迁移这部分内容。
用户个人通讯录：迁移这部分数据在技术上可行，可以根据实际需要决定是否迁移。
用户个人过滤规则：迁移这部分数据在技术上可行，但可能存在一些兼容性问题。除非有强烈的需求，否则不建议迁移这部分内容。

2.2 Domino系统

Domino产品系列使用被称为NSF（Notes Storage Facility）的面向文档的数据库来管理半结构化数据，如富文本（Rich Text）及文件。数据以文档的形式被储存，并且视图可以使查找特定文档十分高效。面向文档的数据库是Domino架构的核心部分。迁移Domino数据一般需要通过Domino的开放API进行，可以针对NSF文件进行直接迁移，也可以模拟Notes客户端的请求迁移Domino服务器端的数据。通过信创邮件厂商开发的迁移工具，可以对Domino的如下数据进行迁移：

用户和组织架构：通过迁移工具导出这部分数据，然后经过格式转换后导入信创邮件系统。
用户个人通讯录：这部分数据也可以迁移，不过由于Domino系统的邮件地址未遵循开放标准，在迁移过程中需要对邮件地址进行转换。
邮件数据：通过迁移工具，可以对邮件数据进行迁移，需要注意Domino邮件信头中发件人、收件人地址格式不是user@domain形式，需要根据实际需求决定是否对信头内容进行格式转换。

对于Domino的其他数据，不建议做迁移。

2.3 国产非信创邮件系统

如果原系统和新系统均隶属于同一个国产厂家的产品，这种情况下数据迁移过程通常会相对简单且高效。以Coremail邮件系统为例，当需要从其非信创版本迁移到信创版本时，由于两者在底层架构、数据格式及接口设计上具有较高的兼容性和一致性，因此数据一般可以实现无缝、完全地迁移到新系统。一般涉及迁移的数据如下：

数据库数据：对于结构化数据，如用户账户、组织架构、用户个人设置、个人通讯录、过滤器规则等，这部分数据存储在数据库中（如MySQL、Oracle等）。一般可以通过信创数据库厂商提供的迁移工具，对数据库进行迁移，将这部分数据迁移到符合信创标准的数据库中。
文件数据：邮件、邮件索引等数据是以文件形式存储在文件系统中，这部分数据可以直接拷贝到信创系统中，一般无需特殊处理。

如果原系统与新系统并非出自同一厂商，那么在进行系统迁移时，就需要根据双方系统的兼容性、数据结构、安全协议等具体情况进行深入的分析与评估。通常情况下，尽管存在一定的技术挑战，但通过合理的数据转换工具、专业的迁移服务或定制开发接口，可以确保关键数据如邮件数据、用户账号信息等得到有效迁移。

注：在数据迁移过程中，其可行性、迁移效率以及最终效果，均与信创邮件厂商技术实力、解决方案成熟度有关。建议在选择合作伙伴时，对厂商的技术创新能力、项目经验进行全面评估。如需了解更多关于邮件信创的信息，可以本站邮箱品牌相关介绍。

3. 数据迁移策略

在数据迁移前，必须进行细致的需求分析、数据分类与评估，确保迁移策略符合组织的要求。根据小编在项目中的实际经验，通常有下面几种迁移策略供选择。

3.1 上策

将旧系统保持在线但不进行全面数据迁移，而是设定一个过渡期仅用于提供邮件查询服务，这一策略巧妙地平衡了资源利用与用户需求。在此期间，建议用户通过其邮件客户端将重要邮件自主存档至个人电脑，作为个人数据的备份措施。这种策略可以显著降低信创改造过程中所需的存储成本，有效缓解新系统上线初期可能面临的存储压力。同时，它也为项目团队节约了宝贵时间，这些时间可以用来处理项目推广、用户培训指导等更加重要的工作。

3.2 中策

采取选择性迁移的策略，即仅迁移用户账号及部分关键邮件数据，而对于其他非核心数据，如日程、个人通讯录等，则暂时不予迁移。这种策略能够显著降低项目整体的复杂性和风险，通过减少需要迁移的数据量，可以聚焦于核心数据的准确性和完整性，避免因数据迁移过程中的错误或遗漏而引发的潜在问题。这种策略也同时兼顾了用户的使用体验，加快了项目进度。整体来看，这种策略是一个在风险控制、项目进度和用户满意度之间寻求平衡的明智选择。

3.3 下策

在数据迁移的过程中，将重要的与不重要的数据无差别地全部迁移，这种做法往往缺乏效率与针对性。如果采取这种不加区分的策略，那无疑将是一场管理上的灾难。它不仅会极大地增加迁移过程中的复杂性和成本，还可能因为冗余数据的处理而延误关键数据的迁移进度，进而影响业务连续性。一般来说，采用这种非优化策略的项目，在资源利用、时间管理以及最终成果上都难以达到理想的预期，往往导致项目延期、成本超支，甚至可能对数据的安全性、完整性和准确性构成潜在威胁。

文章来源：邮件系统信创改造之数据迁移策略