首先根据系统的特点判断是否适合Docker化改造，如适合改造，则开始制定改造方案，改造方案会涉及系统镜像的组成、镜像的参数、镜像的启动方式以及源码改造点等基本问题。接下来就是改造环节了，即改造代码以符合Docker的要求，然后制作镜像。最后是验证阶段，由于可以在一个单机上启动多个Docker容器进行联网调测，所以单机测试验证通过以后，基本上就表明了多机分布式部署的正确性，最后进行多机部署测试，以及生产环境的上线过程。
那么哪些应用适合Docker化改造？一般认为符合以下条件的应用是适合进行Docker化改造的。
1）频繁修改和升级的系统。
2）不太稳定，容易死机或者导致CPU、内存等过度消耗的应用。
3）大量使用开源技术和中间件的系统。
4）其主要目的是用作演示的应用。
首先，很少变动的系统不适合进行Docker化改造，因为很少变动的系统意味着没有什么业务需求支撑，如果花很大代价将其进行改造，就是一种投资浪费。系统改动升级越频繁，Docker化的价值越大，因为Docker镜像后的系统部署和升级都很容易实现标准化和自动化，大大提升了项目组的工作效率，减少了重复劳动，Docker化以后，镜像都有版本，因此升级失败后的回滚也变得更容易和可靠。
其次，Docker容器因为共享Linux内核，所以那些与Linux底层密切相关的应用是不适合Docker化的，因为这些容器大量操作内核API，可能导致内核不稳定，如内核崩溃，此时其他容器都受牵连，这是非常严重的。所以这种情况是不能进行容器化的，必须要独立出去。而对于那些不太稳定、容易“自杀”或者容易导致CPU和内存过度消耗的应用，则很适合Docker化，因为Docker可以做CPU和内存的资源配额限制，例如，一个Docker容器只分配1GB的内存，则此容器内的进程如果申请超过1GB的内存，就可能会被Docker Engine“杀死”，如果该容器限定了使用0.5个CPU，那它永远不会得到超过0.5个CPU的使用量，因此Docker化以后，这种过度消耗资源的进程会被约束，不会导致系统问题。另外，如果某个进程不稳定并且容易“自杀”，则可以在容器化的时候设置它的启动策略为“restart=always”，这样如果Docker Engine发现这个容器“死了”，就会自动尝试重启这个容器。
最后，其主要目的是用作演示的应用以及项目POC也都适合Docker化。因为Docker比较轻量，很容易用Docker容器部署一个集群应用，这个集群应用只需要少量资源，如在高配置的笔记本式计算机上就能流畅演示。此外，如果演示者本身并不是很懂技术，相对于虚拟机等复杂的技术，Docker的使用还是很容易快速掌握的，稍微培训一下，很多售前和销售人员就能正确启动一套Docker的演示集群。此外，每次创建的Docker容器都是全新的、没有历史数据的，因此每次演示都能确保系统是正常可靠的。
总结下Docker化改造传统应用的关键步骤如下。
1）评估代价与可行性——评估改造的可行性及资源投入等。
2）改造方案——包括如何升级改造、对代码进行修订的指导性意见等。
3）代码修订——对前期涉及的原有代码进行修订，包括一些接口设计等。
4）制作镜像——实施阶段，制作镜像。
5）单机验证测试——对镜像做单机验证。
6）多机部署——多机环境的正常部署和应用的正常启动。