Posts tagged "upgrade"

CQ5.5: Upgrade recommendations and information

This information will be useful if you are planning to upgrade your CQ environment to CQ5.5. This information is intended as a supplement to the official upgrade documentation:

You should read these recommendations, and then follow the steps in the upgrading documentation, applying the added suggestions here as required.

Trial migration

It’s better to first run a dry-run migration on a clone of UAT (author & publish instances) to ensure that there are no major issues in the upgrade process. Check if there are any changes needed for your code to work on the upgraded version. In this case, change the code and ensure you have a consistent process for applying those changes. Identify any high risk areas in the code and plan for extended testing time on these areas following the upgrade.  Repeat the steps from scratch on the UAT clone so that you’ll be sure to have a consistent end-to-end process for the upgrade. Then proceed to upgrade all the environments: DEV, UAT & PROD.


  • Create a clone of the instance to upgrade.  You’ll perform the upgrade on the clone. It will be easier to rollback in case of problems.
  • Perform a full consistency check on the repository early.  Fix any problems before attempting the upgrade/migration.
  • Read the extensive list of “Tips and Troubleshooting” in the upgrade documentation and apply the recommended changes to avoid these common problems.
  • The code-base has to be frozen before the upgrade process and all the existing bugs closed. In case it’s not possible to close all bugs, keep a detailed list of them and double check them on the upgraded version.
  • Only do 1:1 migrations. Only introduce new product features for editors/business later. This will let you focus on the migration itself and any regressions.
  • Try to get dedicated hardware for all environments (PROD + staging), this gives you much more flexibility.
  • Involve Adobe consulting if required.  This will ensure a smooth migration process adhering to best practices.
  • Compile a list of all connected systems and involve those teams in the migration planning.  Ensure they have a short turn-around time in case of issues.
  • Purge workflow history (this speeds up the update process).
  • Make sure all workflow tasks are finished (none are running).
  • Make sure you have at least 1024MB Heap configured during update.
  • Clean all the logs to make it easier to isolate upgrade issues.
    • crx-quickstart/logs/*
    • crx-quickstart/server/logs/*


Tests should cover complete authoring workflows and not just the correct rendering of templates.

Check ACLs and permissions (especially when updating from 5.2.1).

Check Workflow models – check if any customizations were overwritten.

Check all forms and form actions (especially when updating from 5.3 or older).

Production upgrade

After performing the upgrade process on a UAT instance, once you are ready to upgrade the production instances, there shouldn’t be any major/unexpected issues. The code-base should already be frozen and in a good state, and you should freeze out content changes also. Only urgent changes should be applied to the content and the author team will need to keep track of all updated pages. These can then be moved later with a package.

1. Follow all the steps documented in the upgrade docs.

2. Sign-off the environments.

3. Migrate the latest content changes (if needed).

4. Switch the instances.

5. Delete all the dispatcher(s) cache.

It’s better to keep the old instances available for a while in case of problems not encountered during all the documented steps.  You should plan enough time for bug fixing following the production upgrade.

reference: (35335)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 6.3/10 (4 votes cast)

LiveCycle ES: values in a LC7 SetValue expression are being lost after a process upgrade


 After upgrading a process from 7.x to 8.2 in workbench, the value expressions that existed in the 7.x SetValue activity no longer exist and appear as blank assignments in the 8.2 SetValue activity.


7.x SetValue Settings:

/process_data/myXMLVar = '<node>value</node>'

/process_data/myStringVar2 = 'test string'

/process_data/myXMLVar3 = '<node>value</node>'

8.2 SetValue Settings (post upgrade):

/process_data/myXMLVar = ''

/process_data/myStringVar2 = 'test string'

/process_data/myXMLVar3 = '<node>value</node>'

The upgrade appears to be removing XML based strings (unless escaped).


 This is a bug in LC and is caused by the loss of XML data encoding:

– encoded XML attribute values are read from the input process action template and decoded during read by Xerces

– decoded values are rewritten as XML elements (not attribute values) and never re-encoded.

– the subsequent symptom is that the unencoded XML data is (rightly) interpreted by an XML parser, but should have been interpreted as text data.


 This issue will be fixed in Workbench ES2.  There is a patch available for LC ES, so contact enterprise support if you require this patch.

reference: (181109986/2403113)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycleES: NullPointerException trying to upgrade a LC7 process in Workbench


When trying to upgrade a LC7 process in Workbench, which is working fine under the LC7 compatibility layer you may receive an internal error in the upgrade report, with the following exception in the detail dialog:

at com.adobe.workflow.template.document.AbstractRouteTemplate.copyToAction(
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.copyOutRoutes(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.copyRouteInformationToBranch(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.processBranch(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.orchestrateProcess(Unknown Source)
at Source)
at$ Source)


This will be related to a particular QPAC in the process which does not have the correct mapping file for the Upgrade Process Tool.  The report will show you on which QPAC the exception occurred, or you can remove each QPAC from the process one after the other, and re-test to isolate the problem QPAC.


Once you know what QPAC causes the issue, you should ensure you have the current upgrade mapping file for that QPAC loaded in Workbench.  If the QPAC is from another vendor, then contact that vendor for the latest mapping file, and load it into Workbench under Preferences -> Upgrade Process Tool.

reference: (180890412/2324824)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycleES: description of manual tasks after upgrading from LiveCycle 7

For anybody looking for more information about migration from LiveCycle 7.x to LiveCycle ES, there are some manual steps involved which you should know about so that you can plan your resources and testing around this.

The main manual tasks are:

  1. Upgrade process using Upgrade tool
  2. Delete init-forms
  3. Change each form variable type from ‘lc7form’ to ‘xfaform’
  4. Set render/submit service for each xfaform variable
  5. Remapping User QPAC’s input and output variables (in LiveCycle 7.x, the input can be a variable name, but in LiveCycle ES, it must be an xPath expression), if multiple User QPACs are used in a process, you have to remap the input/output one-by-one.
  6. Activate the new process version

You can find more information on each of the steps above in the LiveCycle Workbench ES documentation below.
Upgrading processes in LiveCycle Workbench:
…see the section under Creating Processes > Upgrading processes, particularly the section on Performing Upgrades.

For LiveCycle Workbench ES2.5 you should read the following documentation:

More information about the tasks involved in upgrading a process that uses an init-form bound to a schema:

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)