源服务器上跑着Tomcat 9，台服JDK 8，台服Ubuntu 20.04。台服迁移这件事，台服听起来像复制粘贴，台服实际坑都在细节里。台服

先干最实在的台服——打包。别用zip，台服tar更稳。台服进入Tomcat的台服webapps目录，把整个ROOT文件夹和你的台服业务war包一起打包。命令就一行：tar -czf app_backup.tar.gz ROOT/ your-app.war。台服顺带把conf目录里的台服server.xml、context.xml也塞进去，台服别漏了。台服我见过有人只拷war包，结果数据库连接池配置全丢了，启动直接报错。

新服务器上，Ubuntu版本可能不一样，但别慌。先装JDK，版本必须对齐。检查java -version，如果新机器是OpenJDK 11而你原来跑的是8，那大概率会碰到类加载问题——不是代码错，是兼容性差异。老老实实装回8，用apt或者直接解压tar.gz都行。

接着解压Tomcat。别用apt装，那玩意儿版本太老。去官网下二进制包，解压到/opt/tomcat，权限设好。chown -R tomcat:tomcat /opt/tomcat，不然启动时写日志都费劲。然后把你打包的app_backup.tar.gz传过去，解压覆盖webapps目录。这一步有个小陷阱：如果新服务器上已经存在同名目录，tar解压会覆盖，但不会删掉多余文件。保险起见，先rm -rf webapps/ROOT再解压。

配置文件是重头戏。server.xml里的端口，如果新服务器防火墙策略不同，8080可能要改成8081。更关键的是数据库连接——你的项目里如果用了绝对IP地址，比如jdbc:mysql://192.168.1.10:3306/db，那这个IP在新环境可能不可达。要么改hosts映射，要么直接改配置文件里的连接串。我上次迁移就栽在这，应用启动成功但登录页转圈，查了半天才发现是数据库地址指向了旧网段。

环境变量也别忽视。检查/etc/environment里有没有设置JAVA_HOME或CATALINA_HOME。有些脚本依赖这些变量。新机器上没配，启动脚本会报"Neither the JAVA_HOME nor the JRE_HOME environment variable is defined"。直接编辑/etc/environment加上：JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64，然后source一下。

启动前先跑一遍bin/configtest.sh，它能帮你检测配置语法错误。没问题了再bin/startup.sh。启动后别急着看日志，先ps aux | grep tomcat确认进程活着。然后curl一下http://localhost:8080/your-app，看返回码。200就基本稳了，404可能是应用没解压对，检查webapps目录结构。

最后说个容易忽略的点——日志路径。原服务器上catalina.out可能被logrotate管理，新机器没有这个配置，日志会无限增长。手动加上logrotate规则，或者至少写个cron定期清理。别问怎么知道的，我见过磁盘被日志塞满，整个服务挂掉的惨案。

迁移完记得跑一遍核心业务接口，别只测登录页。数据连接、文件上传、第三方接口回调，这些最容易出问题。整个过程半小时能搞定，但检查得仔细。