Acquia · official partner
Acquia is a decision about responsibility, not about the CMS.
Drupal is the same Drupal on any host. What changes is who answers at three in the morning, and what you no longer have to maintain.
The difference
Drupal is the software. Acquia is who operates around it.
Drupal is the open source CMS, and it does not change according to where it runs. Acquia is a company selling managed hosting, tooling and Site Studio on top of it.
That is why "Drupal or Acquia" has no answer: they are not alternatives. The real question is how much of the operation you want in house.
What actually changes
What leaves your side of the responsibility.
With the Acquia platform, these stop being your problem:
- Keeping development, staging and production environments in parity
- Sizing infrastructure for peak without paying peak all year
- Operating the edge, the cache and content delivery
- Tracking core security updates and having an escalation path when something breaks
None of this is magic: it is work someone does. The decision is whether that someone sits in your team or in the contract.
Being a partner
What the partnership changes for whoever hires us.
We are official Acquia partners. In practice that means a direct escalation path when a ticket needs to leave first level, and visibility into what is coming to the platform before it becomes a release note.
What the partnership does NOT mean: that Acquia is the right answer for every project. It is an operations contract, and an operations contract is justified by scale and criticality, not by a badge.
The decision
When Acquia is worth it, and when it is not.
Worth it when
- The platform is critical and downtime has a cost you can name
- There is no dedicated infrastructure team, and there will not be one
- The operation is multi-site or multi-country, with environments that must match
- Compliance requires a trail of who changed what, and when
Not worth it when
- The site is institutional, with low and predictable traffic
- A platform team already runs what you have, and runs it well
- The expectation is that hosting solves a problem that belongs to architecture
We are partners, and we say when it is not the case. Recommending what does not fit costs more than losing the project.
Questions before deciding
- Does Acquia serve Brazil?
- The platform is global and serves Brazilian operations normally; what is usually missing is someone to implement and operate it here, in your timezone and your language. That is the role we fill: the commercial relationship can be direct with Acquia or through us, and engineering stays on this side either way.
- Do I need to migrate hosting to use Site Studio?
- No. Site Studio is a licensed product and runs on Drupal on any host. It and Acquia Cloud Platform are separate decisions, and conflating them is what makes many people think they must change both at once.
- Is Acquia more expensive than hosting it ourselves?
- The invoice is larger and the total cost rarely is, when there is real operation on the other side of the comparison. The common mistake is comparing the price of Acquia with the price of a machine, instead of with a machine plus the time of whoever maintains it, out of hours coverage, and the cost of an outage.
- Can we leave Acquia later?
- You can, and it is worth designing for that from the start. Drupal is yours and the content is yours; what locks you in is whatever was built assuming platform specific services. Keeping that dependency isolated and named is architecture work, and it is what keeps leaving an option rather than a project.
- Do you only work with Acquia?
- No. We run Drupal on Acquia, on other managed hosts and on our own AWS infrastructure, which is what Soul Stack does. Hosting is a consequence of the operating decision, not the start of it.
Tell us what your platform has to withstand.
Version migration, Site Studio, design system, or a Drupal that outgrew its architecture.
Engineering is not decoration. It is direction.