Acquia Site Factory Pro common mistakes
Acquia Site Factory Pro · Understand the traps and how to avoid them.
Trying to deploy a module or theme update to one individual site's codebase, or looking for a per-site code branch in the Site Factory console.
Candidates carry over single-site Drupal habits and assume each site has its own code. Site Factory is a multisite factory where every site runs from one shared codebase, so per-site code deployment does not exist.
What to do instead
Treat code as factory-wide: commit to the factory codebase, deploy through the dev, stage, and production factory environments, then run the site update process for affected sites. Use update hooks or configuration for site-specific behavior instead of per-site code.
Deploying code to the production factory and then telling stakeholders the change is live, without running the site update or synchronization step.
Code deployment and applying database updates to each site are separate operations. The console can show sites as needing updates after new code arrives, and skipping that step leaves sites on old schema or configuration.
What to do instead
After each production code deployment, run the Site Factory site update task or the equivalent Drush command, monitor for failures, and verify a sample of sites before declaring the release complete.
Assuming that deploying code from stage to production also promotes the stage database, content, or configuration to production.
The deployment pipeline moves code only. Each factory environment has its own database, so content and configuration created in stage do not travel with the code artifact.
What to do instead
Separate code deployment from content and configuration movement. Use a deliberate content staging or export/import process, and verify configuration in the target environment after code deployment.
Cloning a site and expecting the clone to keep the original site's custom domain, owner, and any per-site code customizations automatically.
Cloning copies the source site's database and files into a new site with a new site ID. The clone still needs its own domain configuration, and code is shared factory-wide, so per-site code differences cannot be cloned.
What to do instead
After cloning, set the new domain and SSL configuration, confirm the site owner and roles, review copied users and content, and verify that required modules and configuration are enabled through the shared codebase.
Treating archiving and deletion as interchangeable, or deleting a site without checking whether it can be restored or backed up.
Site Factory lifecycle states have different effects. Archiving is for temporarily removing a site from service, while deletion removes it from active management and may be subject to retention or recovery limits.
What to do instead
Confirm the intended lifecycle action before acting: archive for temporary takedown, export a backup before permanent deletion, and verify the platform's restoration window and process for deleted sites.
Creating a production site from a site template and later trying to switch that site to a different template or distribution.
The site template determines the starting configuration, content, and enabled features at creation time. Site Factory does not provide a simple template-swap operation after the site exists.
What to do instead
Validate the template in a lower environment, create a test site, and confirm the feature set before creating production sites. Plan later changes as code and configuration updates rather than as a template change.
Assuming that site groups can be used to run different code versions or isolate module updates to a subset of sites.
Site groups organize sites for governance and bulk user or role assignment. They do not create separate codebases, so all sites in every group still share the factory code.
What to do instead
Use site groups for access control, ownership, and operational grouping. Manage code and module versions at the factory level, and test changes against representative sites from each group.
Installing a contributed module through an individual site's Drupal UI and expecting it to remain available and supported.
In Site Factory, module installation is managed through the shared codebase rather than through per-site UI installs. A UI install can be disabled, overwritten, or inconsistent across sites.
What to do instead
Add the module to the factory codebase, deploy it through the environments, and enable it with configuration or an update hook. Test the enablement on a representative site before applying it broadly.
Granting a user the Site Factory Administrator console role and assuming that gives them full Drupal permissions on every site.
Console roles control access to Site Factory management tasks such as site creation and user administration. Per-site Drupal roles and permissions are separate and must be assigned through site groups or site-level user management.
What to do instead
Map console responsibilities and per-site Drupal responsibilities separately. Assign the minimum console role needed for factory tasks, then grant Drupal roles through site groups or individual site administration.
Removing a user from a site group and assuming their account, content authorship, and access on each grouped site are removed as well.
Site group membership controls access to grouped sites, but per-site Drupal accounts and content can persist. Removing group access does not automatically delete accounts or reassign content.
What to do instead
Audit the user's per-site accounts after changing group membership, reassign or delete content as required, and explicitly block or remove accounts where access must end.