Accelerator upgrades are project changes, not routine maintenance updates. Assess each upgrade individually. The required effort depends on the accelerator type, the installed version, and the scope of project-specific customizations.
What Accelerators Are
Pricefx Accelerators are prebuilt configuration templates that help teams implement common pricing and sales processes faster. They provide a tested starting point based on Pricefx best practices, but project teams can still configure and customize them for customer-specific requirements.
After an accelerator is installed, configured, customized, tested, and accepted, it becomes part of the implemented project solution.
Key Principle
Treat an accelerator used in a customer project as part of the project code and configuration. If the customer accepted the implemented solution during user acceptance testing (UAT), they accepted the accelerator behavior as delivered for that project. A later accelerator upgrade is therefore a change to an accepted solution.
Plan, estimate, implement, and test that change in the same way as other project changes.
Why Each Upgrade Needs Assessment
Accelerators are not isolated plug-ins that you can always replace without impact. They use standard Pricefx project objects and deployment mechanisms. During deployment, the upgrade can overwrite some objects with matching names, while other configuration stays unchanged and may still need manual updates.
Because of this, the actual upgrade effort depends on the specific project setup.
Factors That Affect Upgrade Complexity
|
Factor |
Why It Matters |
|---|---|
|
Accelerator Type |
Different accelerators have different structures, release notes, upgrade packages, and upgrade procedures. Analytical accelerators are usually easier to upgrade than business process accelerators. |
|
Current Version |
A larger gap between the installed version and the target version usually means more changes to review. |
|
Customizations |
Project-specific changes can conflict with the new accelerator version and may need to be reapplied. |
|
Type of Customization |
Simple configuration changes or label updates are usually easier to carry forward. Changes to standard logic usually introduce more risk. |
|
Project Documentation |
Clear documentation of project changes makes the upgrade easier to analyze and execute. |
Project-level modifications to accelerator code can increase both technical and organizational upgrade complexity.
Recommended Approach
Use the upgrade as a controlled project change.
-
First, analyze the current solution and the target accelerator version.
-
Then plan the work, perform the upgrade in a non-production environment.
-
Reapply or adjust customizations.
-
Run regression tests, and validate the result with the customer before production deployment.
Summary
Accelerators help teams start faster, but once they are part of a customer project, they are part of the implemented solution. An accelerator upgrade is not only a package deployment. Assess each upgrade individually, especially when customizations are present.