企业中的IT很苦，软件有问题要处理。 软件一升级，往往面对的是更多的问题。于是有人叫出“不可升级”、“不可轻易升级”。。。
如何面对软件升级？
下面我就和大家说说“软件升级那点事儿”
0.什么是升级(what)
软件升级一般有两种：小版本升级、大版本升级
小版本升级一般不会有大的模块、技术架构更新，往往是bug修改或局部小的功能调整，一般对原有系统产生的负面影响不大，一般不需要对原有数据做额外处理（有些厂商直接规定小版本升级不能修改表结构）。
大版本升级则一般修改较大，会伴随有模块增加、流程修改、作业重新规划、数据库调整、技术架构变化、新技术应用等，可能会影响到原有已经规划的流程、功能、二次开发的使用，伴随数据库的调整还会产生数据的转换，有外部系统接口的系统还可能会涉及到外部接口的重新调整。大版升级对企业来说是有风险的、有成本的，需要慎重考虑。
1.为什么要升级(why)
对软件厂商来说，由于行业发展、产品成熟度、开发进度等因素，一般产品都会依版本进行规划，所以一般来说版本越高的越成熟，功能更完善，销售更有价值。而且软件厂商的维护能力是有限的，不可能维护产品自产生以来的所有版本（比如修正BUG），所以促进客户升级就成为必然的需要。将客户使用的版本限定有一定的范围内，有利于统一维护，统一管理，降低成本。
对企业来说，小版升级一般是解决潜在的BUG，也许企业用不到，但随时升级还是一个良好的习惯（就象windows系统一直在推出的补丁包），良好管理的补丁包不会给小版升级带来什么风险。前提是也就是这个“良好管理”，如果小版升级要手动，或无回溯机制，或无介绍说明。。。不要考虑了，反正影响也不大。已经在使用中存在的BUG，经厂商修改后确认问题解决，则必须要升级。
对企业来说，大版升级有较高风险，为什么要升级？第一，目前版本功能不够用，需要新版本的功能。如旧版没有高级成本模块，而新版有这个模块；旧版没有GSP，而新版则有；第二，目前版本技术有问题，严重影响使用。如效率低、不支持WEB、不支持移动等，而在新版本中对这些提供了更佳的支持（如支持oracle数据库，则可以将原SQLSERVER迁移到oracle以解决效率问题，PS：我不认为也是解决效率问题的根本，根本应该是设计问题，但现在没有办法，许多企业就是这样解决的，让厂商修改设计也不容易）；第三，由于种种原因，目前版本应不效果不好，可能是产品原因或实施原因。希望可以通过升级创造一个重新梳理的机会。第四，从软件厂商的角度来看，企业升级还可以获得更好的服务支持。这个尤其适用自身IT能力不足的企业，需要软件厂商帮忙维护系统，解决使用中的问题，进行二次开发等，这些企业最好保持软件版本在软件厂商的主流版本上。
所以，升级有时还是必要的，主要看你“痛”不“痛”。
2.什么时候升级(when)
关于升级的时机，要从产品与企业自身的业务周期来考虑。
小版升级，影响不大，可随时进行，但尽量避免在月末、月头进行月结的时候进行。小版升级需要的时间一般不多，可以选择在晚上或是周末进行。
大版升级，从产品考虑，要评估大版更新产品的成熟度。尽量不要做厂商的小白鼠，不要成为第一批升级客户，可以选在大版升级推出后6-12个月，错过第一波升级试验阶段，一般来说，经过一波升级，应该出现的问题应该会出现了，厂商也有了针对问题的处理方法或产品经过修改成熟度有提升。所以，这个部分是越晚越好。希望跟随软件厂商主流版本的，可以在厂商下一个大版本推出之前升级到当前版本。
大版升级，从企业自身业务周期考虑，尽可能选择企业业务较少的时候进行。一般企业经营都有淡旺季，尽量选择经营淡季进行。此时升级各部门有时间配合，即使出现问题，对经营影响也不大。
大版升级需要整体规划，尽可能列入年度IT规划，争取高层与业务部门的支持，进行统一评估、统一安排时间。
3.由谁升级(who)
升级的执行者可以是企业IT部门或软件厂商来实施。
一般来说，小版升级由企业IT部门实施。
大版升级，如果是小白鼠，一定要由软件厂商现场服务，IT部门与业务部门成立项目组配合。从这方面来说，软件大版升级需要列入IT年度规划。
成熟的大版升级，在有足够完善的升级工具的情况下，可由IT部门实施，由软件厂商提供远程协助。
4.如何升级(how)
有了前面的准备，升级变得不再难。
小版升级，选择好时间，提前准备好测试环境，进行测试升级，测试升级没有问题，再到正式环境升级。
大版升级，提前准备工作就更多，与上线一个新系统差不多。大致可以按以下步骤来：
（1）建立项目组织。不仅仅是IT部门，还有业务部门和软件厂商。
（2）制度项目计划
（3）准备测试环境。将现有正式环境复制一份，作为升级测试环境。
（4）在测试环境中升级，然后调整配置、流程、二次开发、外接接口等，并做所有业务的测试。这个就是要业务部门人员参与的部分。这个部分可能需要很多长时间，相当于系统并行。
（5）针对测试环境的问题进高配置、流程、软件的调整，并调整系统操作手册。
（6）确认测试环境升级没有问题，打正式升级报告给高层，选择合适的时间进行正式升级。
（7）升级后操作培训。在测试环境中进行人员操作培训。
（8）正式环境升级。将测试环境中的配置、流程、二次开发、外接接口、数据转换规则/工具应用在正式环境上。此时正式环境需要面临一段时间的停机（几天到1周），尽量在1周内完成。
（9）正式使用与问题处理。1个月的时间内，完成一个经营周期的工作，收集与处理问题。及时发现，及时解决。
（10）升级完成。总结升级过程，上报升级效果。
总体来说，升级要慎重，尤其是大版升级，是一个系统工程。
同时，也建议IT进行选型的时候，将大版升级作为非常重要的一个环节来评估软件厂商的服务支持能力。
最后，祝各位“升级快乐”！
