In order to stay on point executing on the premise of the dotCMS vision, we want you to benefit from the latest and greatest product capabilities and upgrade your dotCMS Cloud environments. The following upgrade process will be performed by dotCMS to achieve that goal.
1. Scheduling an Upgrade
The Upgrade team will reach out when your environments are becoming due for a full release upgrade. If at any time you are interested in upgrading and have not been contacted, you can put in a ticket on Helpdesk.
During a full upgrade, a parallel environment will be created for each of your current environments, to allow you to fully test the upgraded sites while maintaining your current live site as well.
It is important to review the ChangeLog for the version you are upgrading to ahead of your upgrade. These contain specific information on both the changes that have been made in the new version and how this may affect your individual dotCMS installation.
2. Upgrade Environments Created
The dotCMS upgrade team will create a new parallel environment for each existing environment that you currently have.
The dotCMS upgrade team also takes a snapshot of the current customer content repository, including any OSGi plugins, so all of this can be migrated to the new environment(s) - please note that static plugins are no longer covered.
Once these parallel environments are created, they will be delivered to you for testing.
3.Customer Testing Process
This is the step that requires the most work from a customer.
Environment Delivered
Once the upgraded environment(s) are delivered to the customer for testing, the customer will work with dotCMS support as needed to troubleshoot and research fixes for any issues discovered during customer testing (bugs, velocity code changes, content modernization, etc.).
Custom code work must be completed by the customer (e.g. dynamic plugins), unless the customer has additional contracted support. Be sure to document any code changes/VTL files that are applied to the upgrade site as future data refreshes prior to the cutover will cause these changes to be lost.
Please note: support issues related to upgrade environments will receive a response within 48 hours, but do not apply to the SLA.
Parallel environments may only be available during business hours (typically 6am - 6pm local time where the instance is hosted).
If the upgrade takes longer than 6 weeks, you may incur additional fees. dotCMS typically allows for 6 weeks of customer testing of the parallel environments, at which point the Cutover date will be scheduled.
Important: Review the ChangeLog for the version that you are upgrading to
The ChangeLog contains specific information on both the changes that have been made in the new version and how this may affect your individual dotCMS installation.
Importantly, the ChangeLog for the new version may suggest additional upgrade steps you need to take, based on your individual dotCMS configuration.
Make sure to apply fixes / modifications to sites and content to be compatible with the target version of dotCMS.
Test and evaluate high risk sites and content in the upgraded enviroment
There are many areas where issues could occur after an upgrade, and there for should be evaluated.
Some things to evaluate on parallel upgrade environments include:
- Front-end Logins
- Forms
- Code that pull relationships
- Graphql queries
- [Pushing publishing](https://dotcms.com/docs/latest/push-publishing-best-practices)
- Integrations:All integrations with dotCMS should be tested. The following integrations often show issues:
- SAML/IDP
- OSGI
- Graphql
Please see our Customer Testing Checklist for a more comprehensive list of items that may need to be checked prior to cutting over to the new site.
4. Cutover
Once testing is completed, a ‘go-live’ date will be scheduled and a temporary shared slack channel will be set up to ensure a seamless transition. Cutovers are scheduled Tuesday-Thursday 9:00 am ET - 3:00pm ET.
A content freeze on the environments is required for 24 hours before the environments ‘go-live’.
Customer should backup any new changes/updates in their upgrade environments as these will be wiped out by the data refresh.
dotCMS team will migrate the most recent snapshot of the customer content to the upgraded environment(s) 24 hours before scheduled cutover for final check.
Customer should apply backup bundle to environment(s) and confirm upgraded environments are ready to go live.
At the scheduled time, the dotCMS team will make changes in AWS to point the proper URLs to the new & upgraded dotCMS Cloud environments. This may also need to be coordinated with your IT dept. We typically use Amazon Load Balancers (ALBs) with newer systems and we will provide a DNS URL for you to map any customer-owned domains to the ALB URLs via CNAME. Original EC2 instances will be terminated approx. 2 weeks post upgrade to give the customer time to ensure all data migrated to the new environment(s).
Allow dotCMS users to access the system backend to edit content again.
DNS Entries
If you depend on your own IT staff for DNS entries, be prepared to coordinate with them as your new systems may have a different public endpoint.
