Before planning to upgrade from Classic Cloud to Cloud Next, ensure that you see the information in the following sections:
- Key benefits of Cloud Next
- Changes to Cloud Platform features
- Cloud Next limitations
- FAQs and troubleshooting in Cloud Next
- Additional changes for Cloud Next readiness
Upgrading to Cloud Next
The upgrade process starts with your non-production environments and consists of the following steps. Acquia owns most of the upgrade process for your application. However, there are a couple of steps that might require your team’s action.
| Step # | Description | Customer action |
|---|---|---|
| 1 | Acquia notifies the customer team through a Support ticket that the application is ready to be upgraded to Cloud Next. | Based on Acquia’s update, make the changes to make your platform compatible to be upgraded to Cloud Next. For more information, see Additional changes for Cloud Next readiness. |
| 2 | Acquia updates the existing Support ticket to share the upgrade scheduling details for the non-production environment. Typically, this happens 2 weeks prior to customer’s non-production environment upgrade. | NA |
| 3 | Acquia upgrades the non-production environment on the scheduled date and time. Acquia triggers automated processes that deploy your code, databases, files, and environment settings to the Cloud Next infrastructure. This ensures that your infrastructure can be tested by Acquia’s automated tooling. During this process, your file system and databases are placed in the read-only mode to prevent the possibility of data loss. However, your site might appear to be online to unauthenticated traffic if cached content is available through Varnish or your CDN. After Acquia’s automated tests are complete, Acquia cuts over traffic to the Cloud Next version of your environment and restores full access to your files and databases if the upgrade is successful. Otherwise, Acquia restores access to your files and databases on your Cloud Classic infrastructure and reschedules the upgrade for a later date and time. | NA |
| 4 | Acquia updates the Support ticket to confirm that the upgrade was successful. | NA |
| 5 | Customers must test the non-production environment. | Test the non-production environment to ensure everything works as expected. For information on what to test after the upgrade, see Testing your environments upgrading to Cloud Next |
| 6 | Acquia creates a new Support ticket to share the upgrade scheduling details for the production environment. Typically, this happens 2 weeks prior to the production environment upgrade. | NA |
| 7 | Acquia upgrades the production environment on the scheduled date and time. Acquia follows a similar process to that of non-production. However, environments with larger file systems and databases might require the use of advanced upgrade tooling. In such cases, there is a pre-sync process prior to the start of the testing and cutover process. Similar to the upgrade on your non-production environment, no visible impact to you or your end users is expected until the final process begins. | NA |
| 8 | Acquia updates the existing Support ticket to confirm that the upgrade was successful. | If you face any technical issues after upgrading to Cloud Next, file a Support ticket. For more information, see Technical issues after upgrading to Cloud Next. |
Testing your environments upgrading to Cloud Next
Acquia strongly recommends that you immediately test your non-production environments as soon as they are upgraded to Cloud Next. This not only ensures that any technical issues can be investigated and resolved quickly with the help of the Acquia Support team, but it also reduces the risk of delays or undesired behavior with your production environment upgrade.
When testing your environments through automated tests or manual inspection, review the application behavior that depends on the following:
Custom logic in htaccess files
Image software such as ffmpeg, ImageMagick, or webp
System libraries
Shell scripts or tools such as curl or wget
Scheduled tasks or cron jobs
Cloud hooks
Custom scripts or commands that run on the SSH pod
In addition, you must monitor application performance in New Relic after the upgrade and compare that with prior performance.
When testing your environments, the following practices are recommended:
- Ensure that you note down any anomalous behaviors on each environment’s sites prior to the upgrade so that you can clearly differentiate between existing bugs in your application and new bugs introduced since the upgrade.
- After upgrade, load your sites on each environment and verify that they are behaving the same after being upgraded to Cloud Next as they were before the upgrade took place.
- Test any custom functionality, focusing on the most critical behaviors of your application, including custom modules, reports, scripts, cron jobs, CI/ CD automations, and connections to remote non-Acquia services.
Verify that cron jobs are both running as expected and logging as expected, keeping in mind that Cloud Next has a new directory for cron logs and custom logs that must be routinely pruned to prevent unnecessary growth of your file system:
/shared/logs- Verify that all necessary scripts, Drush commands, automations, and CLI commands that you require are available and work as expected, by accessing your environment. Some may require updates and adjustments to syntax, and certain CLI commands you had used previously may not be available. A new SSH syntax will be required to access your production environment.
- If necessary, re-download your Drush aliases to ensure they are compatible with Cloud Next.
Technical issues after upgrading to Cloud Next
If you discover any technical issues after your environments are upgraded to Cloud Next, create a Support ticket and ensure you select an appropriate level of urgency. In the ticket description, include steps to reproduce the problem and a clear summary of how the environment behaved prior to upgrade.