Upgrade Go-Live Checklist

This checklist is intended as a guide, to help you ensure that you’ve fully tested your site and ensure it works properly before you “go live” with the site.

This checklist can be used to help both when you create a new site with dotCMS, and when you upgrade your site from one dotCMS version to another. This checklist may also help you to set up your own internal testing process when you make large changes to your site, such as when rolling out a major site redesign.

The items in this list are neither complete nor detailed; these are merely guidelines to help you identify areas of your site to test before you switch over to a new site.

Back-end

1. Authentication: SAML / Oauth
   • Verify that authorized users can login to the dotCMS back-end.
   • Verify that you can login to the dotCMS back-end using a native administrator account (using the ?native=true flag).
2. Relationships
   • Verify that relations on content display properly in the back-end (when viewing related content in the content editing screen).
   • Verify that all pages containing relationship code display correctly, and display the correct related content.

Front-end

1. Authentication
   • If front-end logins are enabled, verify that existing front-end users can login properly.
2. Page Display
   • If possible, display and verify the operation of every page on the front-end of the site.
     1. If you have front-end pages that require authentication, perform this run-through twice: Once as an authenticated user, and a second time as an unauthenticated user.
   • If there are too many pages to test all pages, test at least:
     1. All top level pages.
     2. All pages directly accessible through navigation menus.
     3. Any pages containing custom Velocity or Javascript code.
     4. 3 pages of each page type (including 3 pages using each different page Template, 3 pages of each URL mapped Content Type, etc.).
     5. Any pages or areas of the site with restricted access.

Forms

1. Display and use (submit content through) at least one instance of each front-end form. Verify that:
   • The form can be submitted by all users it should be (anonymous users, authenticated front-end users, etc.).
   • When a form is submitted, the content is created within dotCMS properly.
   • The user receives confirmation or redirection as expected after submission.
   • Incorrect/disallowed values in form fields cause appropriate behavior (messages to users, redirection, etc.).

Push Publishing

Due to the nature of Push Publishing, all these validation steps should be performed on each dotCMS environment which acts as a Push Publishing sender. Generally, this means all dotCMS environments except for your production environment. On each Push Publishing sender, check the following for each receiving endpoint:

1. Endpoint Configuration:
   • Verify that the authorized users and Roles set on the Push Publishing endpoint configuration are correct.
2. Filters:
   • Verify that all custom Push Publishing filters on your site display in the Push Publishing popup window.
3. Integrity:
   • Run the Integrity Checker, and verify there are no conflicts.
4. Pushing Content:
   • Separately push a single content item of each Content Type using the “Only Selected Items” filter - and verify that it pushes without delays and without errors.
   • Create a bundle of several content items of each main Content Type used, and verify that the bundle pushes without delays and without errors.
5. GraphQL:
   • Display all pages containing Graphql queries.

Integration Testing

1. REST API:
   • Verify that any external applications or sites which use dotCMS APIs can retrieve the proper values from dotCMS.
2. Sass, Velocity, and other code that executes or compiles on the backend
3. Plugins:
   • Ensure static plugins are transferred (if a binary installation utilizing them) and OSGi plugins are functional (OSGi plugins may require some development against changes in dotCMS)

Site Accessibility

1. Vanity URLs, rewrite rules, or other redirect rules
2. Certificates - are the correct certificates being served if requested (may require local DNS or hosts file changes for effective testing)
3. White lists where applicable
4. Index pages - i.e. is default index page index.html, index.htm, index.dot, etc.
5. Home pages - is the customer’s home page not located in the root directory (often found with legacy customers using /home instead)?
6. Are there any noticeable time issues? Check whether there are any dependencies on a specific time zone within code.
7. Ensure there are no hardcoded dependencies to old resources that will not migrate - i.e. hardcoded DNS names or IP addresses of old hosts, load balancers, etc.