Upgrades

Aspenware offers releases approximately every 4 weeks. For the latest release information, see Aspenware Release Notes.

Upgrade Guidelines

• To ensure optimal performance and continued support, customers should maintain their production code within four releases of the latest version. Running outdated versions may result in unresolved bugs, errors, and other issues affecting Aspenware products.

  1. Version Support: 

     1. One month after a new release is stable and widely adopted (e.g., version 3.7), Aspenware will discontinue support for versions and associated hotfixes two releases and older (e.g., version 3.5). 

     2.  Addressing bugs for unsupported versions will require upgrading to the latest supported version. 

     3. Supported versions will be listed on our Support Policy page and in Routine Maintenance Update in the Support Portal.  

  While Customer Success will continue to assist with questions, development fixes will only be available for supported versions. 

• Production environments will not be updated without first notifying and seeking consent from the customer. This raises the importance of customer contact availability - see the customer expectations section below.

• Before scheduling a release to production, customers are expected to smoke test and approve the code version for their production environment. All functionality that is unique to the customer and not widely adopted should be tested by the customer with each upgrade. For example, if you use subscriptions, these should be specially tested with each upgrade.

• We offer scheduled release timelines within business hours and do not offer routine releases outside of Business Hours or on Fridays.

• Customers must request upgrades using the Aspenware Freshdesk Ticket Portal. All communication regarding the upgrade will flow through the ticket that is created through this portal. See Aspenware Ticket Portal for more information.

• If you are integrating with Aspenware’s Headless Commerce APIs, your development team may be required to coordinate during upgrades. This should only be true if breaking changes are introduced with a version. If there are no breaking changes, you should follow the same processes outlined here. Your Aspenware representative will provide guidance on whether an upgrade has a breaking change to the APIs.

• Legacy Features: 

  • Legacy PDPs: Starting with Commerce version 3.9 (Fall 2025 release), we will no longer regression-test or develop fixes for legacy PDP features that are also supported by Cloud PDPs. Cloud PDPs have shown a 6% increase in conversion rates (through A/B testing), making them a superior option for your business. Please enable the Cloud PDPs before setting up spring, summer, or winter products. 

  • Identity v2 / Standard Login: While no end-of-support date is set at this time, we recommend migrating to our improved Identity v3 (Powered by Auth0) platform before winter 2025/26. This new platform has increased sign-in success rates by 23%.

  • Other Legacy Features: Feature retirement may be carried out alongside a Commerce version. Aspenware will provide alternative product or feature recommendations whenever possible. However, some capabilities may be removed without an alternative if they are rarely used or no longer align with strategic goals. 

Customer Expectations During Upgrades

To ensure that Aspenware has the ability to reach out to customer contacts in the case of emergencies and for code upgrades, customers must provide Aspenware with the following emergency contacts:

These defined contacts are determined as release decision-makers and stakeholders. Permission to turn sites from maintenance mode to live mode following a deployment must be granted by one of these contacts, otherwise, the site will remain under construction until permission has been granted.