一位潜在客户希望我为构建一个自动化解决方案进行定价，该解决方案将从他们的电子邮件系统中提取数据（包括电子邮件附件），并将这些数据移动到我们的数据库应用程序中。
过去，他们使用电子邮件 (Outlook/Exchange) 来跟踪和整理重要文档、照片和信件。他们将文件放在共享文件夹中，以便进行协作。他们已经厌倦了使用电子邮件来管理工作，并决定购买我们的应用程序，但希望将所有这些数据作为附件移动到我们的应用程序中。
现在，如果这些是物理文件而不是电子邮件，这将不是问题，但是，我以前从未做过从交换中提取电子邮件的任何工作。
我应该问客户什么问题，以便我可以自信地为他们定价？
答案1
除了常见的环境问题（有多少个 Exchange 服务器、操作系统/Exchange 的版本等）之外，我还想知道大约有多少条消息、包含要导入的消息的邮箱数量以及每个邮箱的大小。这些信息应该可以通过系统管理器（如果是 2003）或 Exchange 控制台（如果是 2007 及以上）轻松获得。
至于技术，这实际上取决于邮箱数量和预算：
如果用户少于 10 人，而且预算有限，您可以在他们的场所（或远程）设置一个开源 DoveCot IMAP 服务器，并指导他们向每个 Outlook 配置文件添加一个 IMAP 账户，然后只需将邮件拖放到 IMAP 账户中即可；IMAP 以几种可选的方式将其邮件存储在文件系统上，这是相当合理的。有据可查，并且（正如您所说）将文件导入到您的应用程序中“不是问题”。
如果有很多邮箱（并且预算可能较大），我会使用 EXMERGE 批量导出每个邮箱的 .PST，然后您可以使用 Zimbra 的 PST 导入向导将所有邮件导入 Zimbra 服务器，我相信该服务器将邮件存储在文件系统或 MySQL 上（需要仔细检查，但可能是可行的）。
还有不少选择第三方商业或开源 PST 转 $someFormatorMediaryFormat 工具，有些需要大量或少量的代码来编写。
好消息是，这并不像您现在想象的那么奇怪；有很多 Exchange 替代品需要有一种可靠的方法从 Exchange 导入数据，否则没有人会转换。
我倾向于采用像 IMAP/Maildir/MIME 格式这样有据可查的路线：一旦您可靠地将其转换为该格式，您选择的语言中可能会有很多开源解析工具可以帮助您将其导入到您的应用程序中。
无论您选择什么，我都会先做一个“切片”：决定什么是可行的，从客户端获取一组样本数据进行测试运行（或者如果这不起作用，请了解他们存储了什么样的文档，是否在子文件夹中，他们使用什么样的“元数据”来组织消息，并创建您自己的样本集），然后推断完成所有操作所需的时间，并根据您的舒适度进行相应的填充。