有这样一个老项目，CS架构，通过串口给一种设备提供配置管理。客户端登录成功后，会在本地保存一份配置文件（所有的配置信息全部保存在这个配置文件中，XML格式，相当庞大），之后所有的操作都是基于这份配置文件的修改。当用户确认无误后，将配置文件上传至服务端，然后通知服务器更新配置信息。

    因为一些特殊需要，要将之前的CS架构换掉，原因就是客户端配置管理用户体验不好（好多年前的老项目，该有的联动都没有，不合理的地方也多），想换成BS架构，也就是为这类型设备提供一套新的管理系统。因为时间比较紧急等原因，服务端代码要尽量少的改动，数据格式照旧。

    管理系统使用了SSH架构，将庞大的配置按照功能模块做了划分，数据分散到不同的数据库表中。登录到管理系统后，管理员所有的操作都最终反映到数据库中。当用户确认无误后，提供上传配置按钮，后台会从数据库表中取出相关信息，装配成服务端需要的配置格式（XML），通过服务端提供的接口（HTTP协议），发送给服务端。

    当初时间紧急，只出了概要设计，就进入了编码阶段，2个星期时间，管理系统编码结束。原以为现有的管理系统要取代之前的配置工具，结果被告知，两者要共存，问题出现了：原来的配置管理在修改配置信息后，将与现有的管理系统数据不一致！

    想到的解决办法就是：每次在登录现有的管理系统时，都去向服务端取配置文件的摘要，和现有系统可以生成的配置文件摘要做对比，如果发现不一致，则向服务端下载配置信息，解析该配置文件，将所有的数据更新到现有系统的数据库中。个人感觉这样虽然可以解决问题，但是感觉上去怪怪的。

    这项更新配置操作，有可能配置文件只是改动了一个属性的值，而现有系统也得需要遍历所有的配置项，一一更新到数据库中（哪怕数据没有修改），最让人难受的 是原来的配置文件为了可读性，根本没有主键的概念，所以更新操作也是个麻烦事。而且这项配置耗时可能比较长，采取什么样的方式让用户不用去等，也是需要考 虑的。

    我的意见有下：（1）二选一，升级原来的配置管理工具，在之前的基础上完善。或者使用现有的管理系统进行管理--最简单。（2）所有的操作集中到一端，例如，由服务端提供接口（增删改查），所有的操作直接反应到服务端 --需要服务端功能细分，几乎重新设计 。（3） 就是上面那种向现实妥协的方案...。

    很想听听大家对这类型项目的看法。