--- title: "Additional changes for Cloud Next readiness" date: "2024-02-14T00:48:38+00:00" summary: "Prepare your application for Cloud Next upgrade with essential changes for compatibility and optimal performance." image: type: "page" url: "/acquia-cloud-platform/additional-changes-cloud-next-readiness" id: "fa9a05d6-6e5a-4adf-a1a1-e7d623787180" --- Table of contents will be added This page lists the changes that you must make so that your application can be upgraded to [Cloud Next](/acquia-cloud-platform#cloud-next-benefits). These changes do not break the existing functionality in Cloud Classic. You must perform these changes prior to your application upgrade. These development best practices help you to ensure a smooth upgrade.   **Task** □ [Configure the Swift Mailer module by using the “t” mode](#configure-swift-mailer) □ [Use shared paths when using the flock command](#use-shared-path) □ [Reduce the frequency of cron jobs](#reduce-frequency-cron-job) □ [Disable the Memcached binary protocol](#disable-memcached-binary-protocol) □ [Use the Drupal Memcache module later than 8.x-2.0](#use-drupal-memcache-module) □ [Update SimpleSAMLphp code](#update-simplesamlphp-code) □ [Limit code repository size to 2 GB](#limit-code-repository) □ [Disable live development](#disable-live-development) □ [Limit the size of PHP directives](#limit-php-directive) □ [Limit the PHP Max File Upload concurrency to 20](#limit-php-max-file-upload) □ [Avoid sharing database tables](#avoid-sharing-database) □ [Remove dependency on custom PHP extensions](#remove-dependency-on-custom-php-extensions) □ [Avoid using MyISAM database tables](#avoid-myisam-db) □ [Apply Cloud Platform’s limitations for custom environment variables](#apply-custom-env-variabes-limitation) □ [Check dependencies](#check-dependencies) □ [Confirm Drupal and MySQL version compatibility](#confirm-drupal-and-MySQL-version-compatibility) □ [Review Acquia contract revisions](#review-acquia-contract-revisions) □ [Review MySQL Workbench  compatibility](#review-mysql-compatbility) □ [Retrieve legacy keys](#retrieve-legacy-keys) □ [Use different directory for custom log storage](#use-different-directory-for-custom-log-storage) □ [Review slow queries](#review-slow-queries) □ [Test Remote Administration patches](#test-remote-administration-patches) Note All changes are not necessary for all applications. Acquia Support will direct you to address the specific changes that are required to enable your upgrade. Configure the Swift Mailer module by using the “t” mode ------------------------------------------------------- To use the **sendmail** transport, you must configure the Swift Mailer module by using the **t** mode. For more information, see [Swift Mailer settings for Cloud Platform](https://acquia.my.site.com/s/article/1500010098722-Swift-Mailer-settings-for-Acquia-Cloud). Use shared paths when using the flock command --------------------------------------------- When using the flock command to prevent commands from executing concurrently, ensure that the lock file is written to a location that is writable and not ephemeral. In Cloud Classic, paths such as `/tmp` could be used for flock since all the jobs would execute on the same servers. However, that directory is not shared across multiple containers on Cloud Next. Therefore, Acquia recommends that you use the Drupal private files directory located at `/mnt/data/${AH_SITE_NAME}/files-private`. An example usage of flock on Cloud Next that is also compatible with Cloud Classic: flock -x -n /mnt/data/${AH_SITE_NAME}/files-private/flock.example -c "echo 'hello world'" Reduce the frequency of cron jobs --------------------------------- Cloud Next does not support scheduled cron jobs running every one minute. If you have any scheduled jobs that run at a frequency of 1 minute, you must reduce their frequency so that they do not run more than once every 5 minutes. 1. [Sign in to the Cloud Platform user interface](/node/55875). 2. Select an application and an environment. 3. Click **Scheduled Jobs**. 4. Locate all jobs with frequency: `* * * * *` or `Every Minute`. 5. Update the frequency for such jobs to: `*/5 * * * *`. 6. Test your application to verify that it works as expected. If you do not make this change by the time your environments are upgraded, any cron jobs running too frequently are automatically set to a lesser frequency. This might impact the normal operations of your sites if not tested beforehand. Disable the Memcached binary protocol ------------------------------------- The Memcached binary protocol is not supported in Cloud Next environments. It is a deprecated feature of Memcached since Memcached 1.6.0, but is still supported in Cloud Classic. If you enable binary protocol in Cloud Next environments, Drupal and PHP cannot communicate with Memcached. The application fails to set or get cache items, but does not return an error message. In your `settings.php` file or any file included in the `settings.php` file that contains Drupal Memcache module configurations, remove or comment out any lines similar to the following that set the `OPT_BINARY_PROTOCOL` parameter to `true`: $settings['memcache']['options'][Memcached::OPT_BINARY_PROTOCOL] = TRUE; Use the Drupal Memcache module later than 8.x-2.0 ------------------------------------------------- Include files used in Cloud Next reference the `MemcacheTimestampInvalidator` class, which is not provided by the Memcache module prior to 8.x-2.0-beta1. Therefore, using older versions of the Memcache module triggers a fatal PHP error when bootstrapping Drupal. You must update applications to the latest stable release of the Memcache module. Update SimpleSAMLphp code ------------------------- Customers with SimpleSAMLphp in an application must make a few changes before upgrading to Cloud Next to ensure ongoing compatibility with both Cloud Classic and Cloud Next. For more information, visit [Using SimpleSAMLphp with Drupal 10](https://dev.acquia.com/blog/using-simplesamlphp-drupal-10). Limit code repository size to 2 GB ---------------------------------- To ensure reliable deployments in Cloud Next, application codebases must not exceed 2 GB. Application codebases that exceed 2 GB experience timeouts or failure during deployments. In addition, code in a single branch must not exceed 500 MB to avoid the risk of code deployment failures. You must review your repository for any files that can be stored in a public files directory. For example, large image assets, audio/video files, and PDFs. Additionally, you must verify that public files directories, such as `sites/default/files`, are not committed to the repository. Once deployed to Cloud Platform, the distributed file system is mounted in that location. This hides anything that you commit to the repository. Disable live development ------------------------ The live development feature is deprecated and is unavailable for environments running on the Cloud Next infrastructure or Site Factory. Acquia recommends that you use [Cloud IDE](/acquia-cloud-platform/add-ons/ide) instead. For more information, see [disabling live development](/node/56317#disabling-live-development). Limit the size of PHP directives -------------------------------- Directive Max size Default value `upload_max_filesize` 1024 MB 256 MB `client_max_body_size` 1024 MB 256 MB `post_max_size` 1024 MB 256 MB `memory_limit` 1024 MB 128 MB During your upgrade to Cloud Next, these values are adjusted as needed so that they are within the limits. Limit the PHP Max File Upload concurrency to 20 ----------------------------------------------- In Cloud Next, the `max_file_uploads` PHP directive is limited to the default value of 20. During your upgrade, your application is adjusted to match this limit. Avoid sharing database tables ----------------------------- In Cloud Next, you cannot configure your multisite installation to share database tables, such as users, sessions, and profiles tables, across multiple websites. Therefore, you must adjust your application to not use shared tables. Remove dependency on custom PHP extensions ------------------------------------------ Custom PHP extensions, including the ones that are compiled and included in your codebase, are not supported in Cloud Next. You must change your application to remove dependency on custom extensions, or contact your Acquia account team for assistance. Note Custom PHP extensions such as `imap` and `PSpell` extensions are not supported in PHP 8.4. Avoid using MyISAM database tables ---------------------------------- The MyISAM table engine is unavailable in Cloud Next. Although InnoDB is the default database for Drupal since the release of Drupal 7.0, Cloud Platform supports MyISAM tables prior to Cloud Next. To determine if your current database tables use the MyISAM engine, use: SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM'; Apply Cloud Platform’s limitations for custom environment variables ------------------------------------------------------------------- Cloud Platform has the following limitations for custom variables: * Maximum 5000 bytes for each variable value * Maximum 255 bytes for each variable name * 100 kilobytes in total (all variables with their names and values) * Variable name and value must not contain tabs, spaces, or quotation marks. For more information, see [Creating custom environment variables](/acquia-cloud-platform/manage-apps/variables). Check dependencies ------------------ * Cloud Next environments use Ubuntu 20.04 or 22.04 while Cloud Classic environments use Ubuntu 16.04. For more information, visit [Configuring OS versions](/acquia-cloud-platform/configuring-os-versions "Configuring OS versions"). * Before upgrading to Cloud Next, note that Python2, rssh, Drush 9, and Drush 10 binaries are unavailable in Ubuntu 20.04 and 22.04. If you depend on global Drush 9 or Drush 10, you must start using vendored Drush. * Before upgrading to Ubuntu 22.04, you must verify that SimpleSAML is configured as documented in [Using SimpleSAMLphp with Drupal 10](https://dev.acquia.com/blog/using-simplesamlphp-drupal-10). * The default Ubuntu version for newly provisioned Cloud Next environments, is Ubuntu 22.04. For more information, visit [Configuring OS versions](/acquia-cloud-platform/configuring-os-versions "Configuring OS versions"). Confirm Drupal and MySQL version compatibility ---------------------------------------------- The MySQL version in Cloud Next infrastructure is Aurora MySQL 8.0. Drupal 7 versions earlier than 7.76 and Drupal 8 versions earlier than 8.6 are incompatible with MySQL 8.0. Before you plan to upgrade your application to Cloud Next, you must ensure that the Drupal version in your application is compatible with MySQL 8.0. For more information, see [Amazon Aurora major versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html#Aurora.VersionPolicy.MajorVersions. "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html#Aurora.VersionPolicy.MajorVersions."). Review Acquia contract revisions -------------------------------- All environments, applications, and subscriptions upgraded to Cloud Next are subject to the March 31st, 2021 revisions to Acquia’s [Support Users Guide](/service-offerings/guide) and Acquia’s Products & Services Guides ([Legacy Server-based Pricing Model](/service-offerings/products-services-guide/cloud-ace), [Current Views/Visits Pricing Model](/acquia-cloud-platform/cloud-platform-product-guide "Cloud Platform Product Guide")), especially as they pertain to Acquia’s Resource Limits on dynamically auto-scaling infrastructure. See all sections related to the use of shared resources, infrastructure capacity, and capacity management for more details. Review MySQL Workbench  compatibility ------------------------------------- If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Next environments. This issue occurs for a few versions of MySQL Workbench. If you face issues connecting to Cloud Next environments from MySQL Workbench: 1. Locate the database credentials listed on your Databases page. 2. Open Terminal on your local machine and run: `{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}` Here, * `LOCAL_PORT` is the port to which Workbench must connect when using localhost. * `DB_HOST` is the hostname obtained from the Cloud Platform user interface. * `SSH_STRING` is the full connection string from the Cloud Platform user interface. For example, `user@something`. Retrieve legacy keys -------------------- SSH keys that were manually added to an environment before the October 2018 EOL of per-environment SSH key management will not persist after the upgrade to Cloud Next. If your application was running on Cloud Platform Enterprise before that date, visit the Users & Keys page for each of your application’s environments before they are upgraded. You must ensure that all necessary SSH keys are properly associated with users in your subscription’s Teams & Permissions console. Failure to do so may result in errors whenever users, scripts, development software, automations, or remote services attempt to access those environments after they are upgraded. Use different directory for custom log storage ---------------------------------------------- The `/var/log/sites` directory is no longer available for direct log access or custom log storage. Use `/shared/logs` for custom log storage instead. Review slow queries ------------------- Acquia reserves the right to terminate queries at a certain threshold to preserve the overall experience. As a best practice, Acquia recommends that queries do not run longer than 60 seconds for non-production environments and 5 minutes for production environments. To ensure that your environments complete all long-running transactions as expected, wrap them in a MySQL transaction to avoid the risk of data loss or corruption. If your environments require long-running MySQL queries to complete reports or other complex data management processes, contact your Acquia Accounts team to request a delay to your upgrade to Cloud Next. Test Remote Administration patches ---------------------------------- Applications running on Cloud Next should test all Remote Administration patches in a Cloud Next non-production environment before pushing changes to the production environment. This ensures that no differences in Cloud Next and Cloud Classic logic impact the way patches behave after deployment in a Cloud Next environment. Logic requiring access to a tmp or persistent shared directory must be redirected to `$HOME` on Cloud Next.