尽管示例来自于 AIX 迁移，但可以针对其他平台和系统变化来调整大部分想法。分三个阶段来考虑升级：
- 准备
- 升级本身
- 升级后的工作
平稳升级有赖于良好的准备工作。但这个过程并没有在您将系统交回用户时就结束了。升级之后，花费一些时间修订文档、看看用户是否满意并进行升级后的检查，是非常重要的。这样您便有机会弄清工作得如何以及如何做更好。
准备
管理用户期望。升级的最大困难通常并不在技术方面，更多的时候跟管理用户期望有关，以便用户不会期望系统完成不可能的事情。管理期望意味着让涉众参与更改审批过程，还意味着用户对升级带来的影响有一个合理的估计。何时会再次备份他们的系统？他们会注意哪些功能和特性？一个关键的组成部分是允许有足够的停机时间来进行升级。
不要在生产环境中进行测试，而是使用一个尽可能与生产环境接近的测试环境来测试升级的运行。在生产环境中进行测试可能会造成灾难。
阅读文档。即使您以前进行过类似的升级，也要阅读文档，因为可能会有新的先决条件和不同的过程。我发现，尤其是到 Virtual I/O Server (VIOS) 的升级，您需要了解所涉及的内容，尤其是所有先决条件。
最大程度减小对用户的影响。很难确定中断时间范围，原因之一在于中断过程太长。情况并不总是这样的。某些升级方法可能会节省大量时间。例如，使用 Network Installation Manager (NIM) 通过 nimadm 进行迁移，将允许您创建一个备用磁盘并在中断时间范围之前升级该磁盘。在停机期间，所有需要做的只是重新启动，用户就可以再次登录了。采用这种备用磁盘安装的方式还会提供一个非常快速的回滚计划（如果需要的话）。
事先下载更新。有了一个紧凑的中断时间范围，您就不再需要在下载您认为不需要的软件或固件方面浪费时间。您可以提前下载所有更新。对于 AIX，这可能是指 Power Systems 固件、适配器和设备微码，可能还包括 Hardware Management Console。
验证更新。如果您使用的是物理媒体，那么执行您可以执行的所有操作来检查它的可读性。如果程序包采用压缩格式或者位于存档中，那么有必要进行解压缩或者至少检查您是否可以读取该存档。
创建并验证备份。这听起来非常简单，不是吗？但备份实际上只是用于还原的功能。备份过程中的某些元素可能需要修订。我最近听说一个小学校，有人每天更改备份磁带，但实际上从未计划运行任何备份。检查您的备份是否包含您可能需要还原的一切内容也是非常重要的。例如，如果您使用 mksysb 命令进行 AIX 操作系统备份，则通过一些其他方法检查排除列表 (/etc/exclude.rootvg) 中的所有文件或目录是否可还原或是否不重要。
准备备用升级策略。单点故障可能会是毁灭性的。您可能有一个首选的方法来进行升级，但您仍然可以拥有回滚计划，以防万一。例如，如果您使用 NIM 进行 AIX 迁移，那么您可能希望在您的 VIOS 虚拟媒体存储库上拥有 AIX V7.1 安装映像的副本。
在升级期间
首先重新启动。如果 uptime 命令报告操作系统已经运行了几个月，那么可能需要进行一次初始的重新启动。这样将会确认操作系统本身原封未动并且能够承受住重新启动。如果由于某些原因，系统未启动、必需的过程未启动或者文件系统未装载，那么您可以直接解决这些问题，无需考虑此问题是否跟升级有关。
保留日记。简单记录每个任务的开始和结束时间将有助于您计划在将来进行更高效的升级。记下任何意外结果或问题，以及您可能使用的任何解决方案或解决办法。
建立多个回滚点。如果您的升级涉及 10 个步骤，但第 3 步失败了，那么您愿意将系统停留在第 2 步阶段，还是回滚到原始的升级前配置？
记录升级。您应该已经拥有了一些升级文档，其中包含您计划要执行的操作。那么对该文档进行一些改进以便显示您实际执行的操作是非常值得的。如果您对原始计划进行了某些改动，请记下都有哪些改动以及为什么进行改动。
通知涉众。如果在升级期间遇到问题或者您预计有一些延迟，则应该提前通知涉众。通常，他们宁愿被告知系统未按计划运行，而不愿自己最后才搞清真相。
升级之后
验证功能。如何验证升级是否成功将取决于应用程序。进行一些基本的测试是非常必要的。但重要的是在数百个或数千个用户打电话说他们无法登录之前，弄清楚数据库已关闭。
创建新备份。如果出现不幸的情况，在升级完成之后的一段时间内还必须依赖备份，那么您必须还原到升级前的备份，然后再次升级。
清理。成功完成升级之后，需要清理您可能使用过的所有临时文件和文件系统。删除备用磁盘并恢复卷组镜像（如果适用）。
减少代价
成功和平稳的升级不应该依赖幸运。良好的准备、基本的故障排除技巧以及改进过程的愿望都有助于您以最小的代价升级系统。
