当谈到商业应用时，供应商持有这个王国的关键因素，而且停止供应商维护计划对于任何中端市场组织可能是可怕的。但是，据分析师讲，失败的风险可以缓解，特别是对已经可靠地运行的商业应用。

　　Gartner公司分析师、Grant Thornton LLP财政和人力资源系统前建设者和经理Pat Phelan说：“如果它已经运行了5年，还没有发生故障，你冻结了这个环境，且不改变它，那么有可能它将恰好保持继续运行。”

　　她说，通过了解你对商业应用的访问权限，了解它适应你的IT 基础设施的方式，检查整个应用程序堆栈的事故历史——首要的是——确保变更保持绝对最小，这样你可以保持应用远离伤害。

　　在这里，我们列出了Gartner关于如何正确关注，并处理供应商支持项目中终止的商业应用的七个步骤。

　　列出你拥有或者没有的工具、脚本和源代码清单。

　　据Phelan讲，在打包应用的早期，厂商不出售维护服务，因此，就出现了包括源代码副本和维护副本的编译器的客户合约，或者作为交易的一部分，或者在供应商倒闭的情况下由第三方托管。今天，这种情况很少发生，但她说：“仍有包含源代码副本的有效合约。”例如，PeopleSoft公司和Siebel系统公司，公布了源代码和编译器作为交易的一部分。

　　供应商也提供（付费的）诊断工具。它可以通过识别出现得错误，帮助调整和管理应用。最后，还有一些工具，作为许可协议的一部分，旨在让用户修改应用的展现层。

　　底线？在你撤销维护以前，你应该知道你对应用的哪几层有访问权限，以及许可协议允许你或代表你的某人对应用做哪些技术变更。

　　检查系统相关性，并确定基础设施涉及的所有元素。

　　对数据库、操作系统和各种工具所做的修改可能会导致你已经脱离供应商维护的商业应用失效。如果应用程序运行在较老的数据库版本上，并且企业突然决定升级或改变已有的数据库，例如，从Oracle改为IBM的DB2，Phelan说：“你也许想知道关于数据库升级和替换的可行性。但你也许不得不冻结环境，因为你不能使脱离维护的应用工作在DB2上。”

　　这同样适用于以友好的收购获得的软件工具。例如，如果SAP AG决定在不同的方面采用它的新的 BI工具——BusinessObjects，Phelan建议，你不希望一直升级到BusinessObjects不能在脱离供应商维护工作的这个点。

　　考虑回滚支撑服务（操作系统、数据库和应用服务器）到以前支持的版本。

　　Phelan说：“偶尔，我会让已经冻结操作系统或者数据库系统的旧版本的客户，为已经脱离维护的应用保留环境。”

　　但是，通过升级直到应用中断，许多组织将商业应用推到尽可能远的地方。然后，他们终止恢复到某个版本。她说：“那样做，不是一件坏事情，但每次你这样做的时候，它正好引入了风险。我们的建议是稳定、保留环境和最小化变更。”

　　实施保护层以减少安全问题。

　　Phelan说：“这意味着在环境周围放置围栏，以便你可以最小化任变更。”你隔离应用越彻底，引入新的安全保护可能性就更少。

　　她说：“我们还建议在系统前面放置一系列可信赖的域名代理。”这样，应用不再需要与不断进化的危险相关的新安全措施了，而是需要保护层。

　　只允许少数几个管理主数据的系统管理员访问应用程序栈的所有部分。

　　Phelan说，这是很难，因为今天的打包应用设计是允许用户“对配置、主数据或者一切进行基于打包的变更。”告知所有员工，变更要得到管理层的批准，管理层可以是CIO或具有领导角色的某个人。

　　她说：“你不希望人们进去引入配置变更，或者开始在应用的部署方式上胡闹，因为这也算作变更。”

　　考虑修改事件管理流程和监视规则，便于尽早识别不能容忍的性能问题。

　　Phelan说：“你的环境已变得僵化，因此任何事情都可能是潜在的问题，你需要尽早识别它们，因为你为解决这一问题的选择已经潜在地缩水了。”

　　有事例吗？数据库开始变得不堪重负，你必须经历数据库重组。否则你将经历一次功能性事件，像年终处理。你必须监视性能。Phelan说，这对旧应用是很严肃的建议，即使它们在供应商的维护计划中。在这些情况下，一个供应商无论如何也不可能为你做很多。

　　Phelan说：“如果您有容量或性能问题，他们不会为那个旧版本制定修补措施。”最后，你只为供应商介入、分析和解决问题的时间和专家建议向供应商支付费用，——如果你仍然有供应商的维护合同，这也是类似的。

　　通知用户应用将停滞，便于管理用户的期望。

　　Phelan说：“坦率地说，用户对此非常满意——‘哦，感谢上帝！你不会每周都变更。’”

　　然而它的另一面是用户群不断地要求可定制化和变更。CIO们需要定期跟踪应用，以衡量在冻结的应用中可用的以及业务想要的之间的差距。Phelan说，如果分歧过大，就是继续前进的时候了。