第一代框架（以下称A）与第二代框架（以下称B）迁移
难易分析
框架实现的需求：
A框架与B框架实现融合，实现权限管理（权限、用户、角色、菜单和部门列表）、系统管理（实体账户、分账户、用户策略、策略配对、合约做市、策略限仓、白名单、数据库信息维护管理）、基础信息管理（合约、环境管理）、我的策略（策略管理、回测、模拟、仿真、实盘列表）、仿真策略管理（仿真策略审批、仿真自动启停）、实盘策略管理（实盘策略审批、实盘自动启停），在现有的功能改动不大情况下完成框架功能迁移。
A、B两个框架功能对比:
A框架是一个比较典型的web框架，前端和后端相对分离一些：首先通过url获取页面，然后前台整理好数据后通过url发给后台处理，后台接收到数据，一种情况直接逻辑判断返回页面，另一种情况与mysql或者mongodb交互，拿到信息后返回页面，然后前端跳转到响应url页面。 优点：前端相对独立，且使用大量boostrap-table控件，功能比较丰富，后台的代码也比较独立，代码逻辑整体不是很复杂，可扩展性强。 缺点：因为代码逻辑简单，所以代码量比B框架多一些，继承封装的代码较少，可以改进一些；权限操作这块没有B框架丰富，且TAB标题等一些小细节没有B框架完善。
B框架是一个用于快速搭建增删改查功能的CRM框架，前后端联系非常紧密，许多前台页面是在后台渲染后传到前台展示的:首先通过url登录，进入主页面点击左侧某一个菜单，会往指定url发送get请求，拿到数据后直接通过django的form渲染到页面上，不发生跳转。优点：可以快速开发一套CRM，封装完善，代码量小，且基础的功能比较完善，具有权限操作，许多标签是在后台完成，渲染到前台，前端工作量很小。缺点：由于代码之间联系紧密，所以扩展非常难，所有操作都是跳转完成，实现弹框等功能比较困难，最大的缺点就是在前端想实现一些功能的可能性比较低，或者各方面成本比较大。
针对上述需求，将分别从A->B和B->A两个情况分析可能遇到的问题及解决办法：
A->B:
目标就是将A框架中的所有功能，都嵌到B框架中
思路：先把A框架中所有使用Mango数据库都换成mysql数据库（难度一般），然后在B框架中加入左侧菜单（难度一般），点击菜单首先展示数据列表（难度一般），实现普通的增删改查（难度一般），实现下一步形式的新增、一键批量操作等（难度较大，需要从0开始摸索，时间成本高），实现弹框、模拟列表中的查看详情中涉及的界面展示、导入导出等（难度较大，需要从0开始摸索，时间成本高，且不确定性的东西比较多）。
B->A:
目标就是将B框架中的所有功能，都嵌到A框架中
思路：先把A框架中所有使用Mango数据库都换成mysql数据库（难度一般），然后在A框架中加入左侧菜单（难度一般），点击菜单首先展示数据列表（难度一般），实现增删改查（难度一般，但工作量会大一些），完善权限管理，增添操作权限（难度适中，对比B框架来改应该会好一些），TAB页面、超时跳转及css样式封装，简化代码量（难度适中，工作量会大一些），分层级的页面，类似于B框架的权限列表（难度适中，可以基于bootstrap，找一个类似的插件）
结论：
相对来说，由A框架迁到B框架的难度更大一些，因为有许多不确定因素，或者没有两套框架可以借鉴而需要从0开始写的地方比较多，当然主要集中在前台，但不可否认，B框架的后台代码量相对少一些，继承封装等思想用的比较广。基于此，可以在现有A框架的基础上，把B框架的实现的功能迁过来，可能会遇到的问题大概就是代码量会变多，工作量大一些，但是估计逻辑都差不多，所以应该可重复用的代码多一些，所以可以在实现功能的时候考虑封装继承等模式。前端逻辑比较清晰，所以迁移过程中，应该需要每一个页面都要单独写，但是都差不太多。
综上所述，可以由B框架迁到A框架上来，首先把需求实现，然后慢慢把可重复用代码封装起来，逐渐完善框架。