wM upgrade approach and guideline

Hello wM Experts,

I am part of (new) webMethods upgrade team, where our day to day work activities/scope of work are 1.Development and 2. Application Support. Our webMethods environments are distributed in different wM version such as 6.5,9.0,9.8.Off very late we are planning to kick start our wM (Application) upgrade from wM version 6.5,9.0 and 9.8 to higher version wM 10.3 (first).

So as I said earlier, we planning to kick start our wM Application upgrade to higher envs to v10.3.
Here I have following questions, As a part of new wM upgrade team,

  1. Looking for details approach or planning to kick start wM application upgrade?
  2. Where I can find details a. Technical approach b. Guideline checklist for wM upgrade?
  3. What is role and responsibility of (only) wM upgrade team?
  4. I am looking for how to kick start our wM upgrade activities (most precise) What are activities as a wM upgrade team need to do follow?
  5. May I know guideline and checklist to get start step by step wM application upgrade?
  6. Where to find Do and Don’t checklist for wM upgrade?
  7. Where shall I find the Troubleshooting or best practice guideline/checklist for wM upgrade for distributed systems?

Kindly guide or provide suggestion to how to kick start wM Application upgrade.
Kindly share technical links,forums,blogs,supporting documents,KB articles and etc, which need to go through to chock down by wM upgrade approach.

Appreciate and waiting for technical suggestion here.


Well, I’ll be honest with you mate, the level of detail you’re asking for is essentially the outcome of an entire upgrade assessment exercise that takes weeks (this reply alone took me 3 hours to compile).

It’s not possible to get a 100% accurate answer to your subjective question on the forums, so you must take this with a grain of salt and rely on your own analysis - you know your environment better than anyone here.

Having said that, let me take the first stab at it and fellow members can expand thereafter -

Typical Phases - Assessment → Installation → Upgrade → Testing → Go-live → BAU Handover

Governing Principle - You will be spending a substantial time and effort on a thorough assessment, since you are dealing with unsupported versions and multiple version hops; hope for the best but always plan and prepare for the worst (i.e., backup and rollback plans).

webMethods Environment - Prepare a detailed view of the list of wM products, their versions and your business solutions deployed on them, in your landscape. You haven’t listed what products you use, so my response below is for IS instance assets.

Upgrade Paths - Define the upgrade paths for your 6.5 and 9.0 instances as there is no direct upgrade path to 10.3 for those.

If possible, I’d recommend getting your 6.5 and 9.0 assets (via their respective staggered upgrade paths, of course) to a consolidated 9.8 environment first. This way you can perform a collective upgrade of all your integrations from 9.8 to your target version 10.3, thereafter.

Here’s the guide that shows the 6.5 paths (link) and here’s the one that’s the latest (link).

System Requirements - Look at the system requirements (link); you’re going to need some temporary environments as well when you go through the upgrade path hops.

Blast Radius - Naturally, your wM instances are integrated with other systems/applications in your ecosystem. When wM instances undergo an upgrade, it is going to impact your integrations (for example, interoperability/obsolescence of TLS protocol versions, database/application drivers, JVM versions, security layer changes, and so on). Those systems/applications may also have to be upgraded in some form or the other.

This warrants a full-on risk assessment that your business stakeholders must understand and buy-in, while your partners, customers and regulatory bodies must be made aware of.

Data - Your databases are also moving to newer versions, so you need to stay abreast of database version differences and work with the DBAs to draw up a data migration plan as well. You’ll have to scope the relevant wM datasets (for example, service execution history, various logs and so on) you want to keep for historical, regulatory, retention, business-continuity and other purposes.

Test Plan - A rigorous test plan is a no-brainer, especially regression tests. You also need to track and perform a code merge, for any development or promotion activities that other teams have performed in parallel. Consider a freeze, if possible, especially once you commence testing.

Backups, Backups, Backups - Quite often, I hear people saying “I’m unsure how this feature looked like before the upgrade”. In order to differentiate what’s working vs what’s not from a business context, you need to have pre-upgrade backups of your assets, data, etc., on top of your regression test assertions. Plan an extended post-go-live warranty period, wherein your old wM instances are accessible if you need them.

Your Bibles -

  • Installation & Upgrade documentation for 10.3 is here (link)

  • Play around with Pre-Upgrade Analyzer on a Development environment and understand the report fully (link)

  • Product readme files across versions, to keep a track of what features are changing/deprecated (the Analyzer tool will also help you here, but I recommend going through the readme guides)

  • Ensure that you have/obtain access to Empower to review knowledgebase articles and to be able to reach out to the support team

Tip - I strongly recommend writing to Software AG support, to get access to the documentation for your older versions, additional guidelines, articles and recommendations. However, I’m unsure if our team will help you since you’re dealing with unsupported versions (there’s no harm in asking).

Further Reading -

Target Version - You must not stop at 10.3, as it’s going out of regular maintenance on 31st October 2021, which is 2 weeks away and it’ll be out of regular support in October 2022; check this here on Empower if you have access (link).

Future Upgrades - Introduce Command Central in your environment, so that your future upgrades are easier (link). We’ve invested in developing CCE over the years, and now it has evolved and matured across provisioning, monitoring, administration, maintenance/patching and upgrade.

Note - Our Professional Services division at Software AG is skilled at performing upgrades, having completed 100s of upgrades; message me if you want to pursue this route and I’ll put you in touch with someone.



Hello KM,

Hope your doing well!.
Thanks for providing wonderful, in details explanation.
I am still going through your post and trying to digest/ grasp information in bit by bit and taking notes.

As a solid development back ground my team has, but in upgrade area we are pretty new bee , and due to distributed systems we have and wM applications hosted in 6.5,9.0 and 9.8 env’s it’s become challenging tasks for us go-ahead due to no support on v6.5.

Our scope of project is mostly on application upgrade 6.5,9.0 and 9.8 env’s to interim 10.3 and then latest v10.7.
most of the our infrastructure upgrade setup has already taken care by our infra admin team, so our scope of work lie on pre-planning, requirement analysis and almost going to kick start our upgrade phase.

I know, we haven’t provided details env’s information about product, integrations, landscape and patterns we have in our env’s so that you can provide more guidance and suggestions going forward.

I have noted sag support contact as well and when require will do approach them but as of now we are at very early phase of our applications upgrade so in coming days I will share more inputs, data points so that you will help me to show appropriate road map and technical suggestion.

Appreciate your details technical information so far share in this thread…
Keep in touch, will be share more data points in coming days


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.