As described in Importing an existing application, there are several different methods you can use to import a Drupal application into Cloud Platform. In the majority of cases, the import process works quickly and smoothly. Here are some things you can do to make the import work better and some things to check for in those cases where it does not work.
Read Preparing a Drupal application for export, which lists recommended steps to take before you import your Drupal application to Cloud Platform.
Multisite Drupal installations use a separate database for each website within the application. The site import process used by Cloud Platform can import only applications with a single database. If you want to import a multisite Drupal installation, you need to import it using the manual import process.
Cloud Platform runs a specific set of PHP libraries on the versions of PHP listed in Cloud Platform technology platform. If your application requires a later or earlier PHP version or PHP libraries that do not run on Cloud Platform, your application may not work on Cloud Platform.
Cloud Platform configures a PHP memory limit for your infrastructure. If your application is configured with a larger PHP memory limit, it will not be able to start. The PHP memory limit might be set in one of three places:
memory_limit parameter in
php_value parameter in
memory_limit parameter in the Drupal
settings.php file in
For Cloud Platform applications, you should never set any of these parameters
in these files. Cloud Platform Professional customers can configure the
PHP memory limit for an environment. Cloud Platform Enterprise
customers can create a Support ticket
requesting a change in the PHP memory limit. If you have
settings.php files, delete them before you
import your application.
Importing an application into Cloud Platform is usually fairly quick, but it is not instantaneous. Depending on which import method you choose, the import process has three major steps:
Creating a site archive
Sending the site archive to Acquia
Opening the site archive and creating the application from it
Depending on the size of your application and your Internet connection, the first two steps can take from a few minutes to, in some cases, more than an hour. You can check the progress by signing in to the Cloud Platform interface, selecting your application, and clicking the activity button. After the site archive has arrived on the Cloud Platform infrastructure, you should see an entry like this in the activity log:
Import [archive-filename].tar.gz to environment Dev
In addition, you can see your site archive file on the infrastructure. Connect
to the infrastructure with SSH. You should be able to find the site archive
One factor in how long a site import can take is the size of of your site archive. You can minimize the size of the site archive by doing the following:
Clearing your cache before you start the site import
Removing any Drupal modules that have been disabled and that you are not using
If you have verified that your application’s archive file has reached Cloud Platform, but your application does not start (will not serve pages), here are some things you can check.
From the command line, run the
drush status command, targeting
your Dev environment:
drush @[site].dev status
Examine the output of
drush status for errors that may give you clues about
issues that are keeping your application from starting.
You can download your Apache infrastructure and PHP error logs from the Logs page for examination. As an alternative, you can obtain the logs by using SSH:
Find your Apache infrastructure error log at
/var/log/sites/[site].[env]/logs/[infrastructurename]/error.log and your
PHP error log at
Any displayed error messages should indicate the root cause of the error. For more information about the format of these log files and their contents, see About Cloud Platform logging.
One common reason why a Drupal application might not start on Cloud Platform is a custom Drupal module that will not run on Cloud Platform. If you know which module is causing the problem, you can disable it. For information about how to do this, see Disabling modules that block sites on Cloud Platform.
Here are solutions to some issues you may encounter in importing an application using the Acquia Connector.
If you are experiencing errors while migrating your application, clear the Migrate files directory checkbox, select the Reduce database export size checkbox, and then retry the migration process. These options are not displayed unless you have already attempted to migrate and encountered an error.
The following error messages describe the most common causes of problems with the migration process. If you don’t see your error message, or the actions associated with the message don’t allow you to migrate your application, contact Support or use a different application import method.
The application’s installed PHP does not have available GZip or Zip libraries.
The Acquia Connector cannot create a directory in the Drupal files directory. Examine the file system permissions for the Drupal files directory.
The Acquia infrastructure did not respond. Retry the migration process. If the Acquia Connector displayed this message at the end of the migration process, examine the Cloud Platform interface Notifications panel to see if an import is in progress, and if so, you can ignore this error message.
Your Cloud Platform application did not respond with a correct signature, indicating possible transmission corruption. Retry the migration process.
Make sure that your Development environment does not have a tag deployed. Environments with tags deployed will be excluded from the eligible list of environments.
The Acquia Connector encountered an unknown error during the site archive upload portion of the process. Retry the migration process.
The Drupal batch process running the migration encountered an error. Consult Drupal logs for more information or retry the migration process.