老旧系统如何迁移上云，尤其是那种重新部署难度较大的，有没有专用的迁移工具？

没有见到通用性的工具。
应用的容器化改造遵循一些规范，可比较快速迁移到容器云上。

总体步骤：
应用的容器化改造分为两个部分：一、应用整体容器化，二、应用配置容器化。
应用整体容器化是指把编译以后的应用程序包.war或者其他程序包，加入到运行服务环境（tomcat）等的过程，能够让应用初步容器化，并且容器化的应用，能够通过已经配置好的端口直接进行访问，且服务正常的过程。
应用配置容器化是在应用整体容器化的基础上，把配置信息抽象化，例如jdbc的链接地址：jdbc:192.168.1.218:3306可以抽象为jdbc:${MYSQL_SERVER_IP}:3306的方式，类似这样完成应用配置容器化，同时打包成新的image

多环境问题处理：
多环境问题是基于已经容器化的应用，针对于不同的运行环境，赋予不同的 value 值的问题，从本质上讲是对容器化的配置赋值的问题，简单的做法，可以直接通过环境变量赋值的方式进行，不同环境中共同存在的 key 值可以提升到环境管控的级别进行。在应用部署时赋予对应环境的 value 值。

容器化配置变更 ：
容器化配置变更是指存在特殊使用方式的配置，例如测试环境为了保证测试简单进行会忽略默认配置信息进行，而生产环境为了安全，可靠的考虑会额外添加一些参数信息。可以在部署的时候，针对于不同的环境做特殊配置处理完成

容器化应用之间关系管理：
单体应用的部署相信对于绝大部分使用容器技术的人来说都不是问题，问题是如何能够部署复杂的应用系统，即使容器化以后，也希望能够对不同组件之间做简单配置完成应用子系统的构建。这里面有几个关键点：
1) 依赖关系，初始化数据，配置信息
2) 依赖关系可以在应用特点分析中得到，但是容器技术在几个同时并行的时候由于不会按照严格的先后顺序，因此需要自定义脚本，实现等待关系。
3) 初始化数据更多指mysql的初始化数据，可以在运行容器组件的时候指定要执行的sql脚本完成数据初始化工作。
4) 配置信息指第三方服务组件，缓存组件的集群配置等内容。
以上问题，无论是基于docker-deploy还是k8s的编排工具都能够完成。