Aegir in 2025

(disclaimer: this is my personal opinion, but I speak as “we” because most of this is about Coop Symbiotic requirements and roadmap; it’s a tech blog, not a sales pitch)

With the looming deadline of the Drupal 7 “end of life” (EOL) of 1 January 2025, many have been asking what to do with Aegir, which still runs on Drupal 7. Coop Symbiotic plan to continue supporting Drupal 7 in 2025, but some our clients have strict compliance requirements.

Elsewhere, Concensus have an Aegir5 initiative which aims to rewrite Aegir on Drupal 10, Omega8 have adopted Backdrop and are going towards an “Open Core” model (lite vs pro).

At Coop Symbiotic, we have a rather specific use-case: we host hundreds of CiviCRM sites. Some of them run on Drupal 7, some on Drupal 9/10, and some on WordPress. Eventually, some will run without a CMS (CiviCRM “Standalone”, also known as just “CiviCRM”).

The short version: we are moving our fork of Aegir3 to Backdrop, similar to what Omega8 have announced, but most likely in a different implementation. We have already forked drush8, hostmaster, provision and other modules in order to support Drupal 10 and WordPress. Our stack also increasingly uses Ansible to setup things such as crons and other configurations, and we are keeping an eye on initiatives such as CiviOneClick.

This post is about explaining the motivations and the status of what we are working on. You are welcome to test, use or fork our work. More disclaimers on that later.

Why another fork?

Aegir is complex. It has a lot of features and the code is difficult to debug. In order to support Drupal 10, we initially started by looking at Omega8’s work, but it did not work at the time, and debugging the code was a bit of a challenge. BOA also has a ton of (very neat) features, but is even more complex. We decided to go in another direction, which ended up being a quite drastic change to Aegir’s model (no more CMS bootstrapping to run tasks). To save time, we decided to focus on the core features of Aegir that we use.

We provide white-label hosting for 6 other CiviCRM providers (some small, some big), as well as hosting for our our clients. We manage over 100 servers and 1300 CiviCRM instances. Depending on your background, that might be quite modest or rather big. We consider it modest and growing. We expect to double the number of CiviCRM instances in two years.

Since we are a white-label hosting provider, part of our agreement with our partners is that they should not rely too much on our infrastructure. We provide Open Source hosting, not only in the sense that the stack is Open Source, but also they have the freedom to move to another host. That also means keeping it somewhat simple so that it does not require in-depth expertise to run it.

So each server usually runs its own Aegir instance, and our clients can create, clone or delete sites as they wish (and run remote import). Cost effectiveness is an important focus of what we do. Some of them might run dozens or even a hundreds sites on a VM. The objective is to make CiviCRM a powerful alternative to solutions such as SalesForce or Dynamics, at a fraction of the costs. Plus, our clients get to encourage and participate in a tech ecosystem of partners that share their social values.

I disgress, but this was important to explain our motivations here.

So… “talk is cheap”, as Lobo would say. Where are we at?

What works today

Edit: see also 2024-11-17 update

You can follow the progress on Github: https://github.com/mlutfy/hosting/labels/backdrop

We are in the process of learning how Backdrop works, and how to port the Aegir modules to it. Backdrop provides fairly good backwards-compatibility, but it still requires some changes.

Screenshot of Add new platform in Aegir

Our Aegir production servers are still on Drupal 7. Our forks of Aegir can run Drupal 7, Drupal 10, WordPress and we have partial support for CiviCRM Standalone. It was a rocky transition, and we had very understanding and patient partners/clients, and it’s starting to be pretty stable now.

When using Drupal 10, it works with the latest version of Drush (meaning that, as a dev, you can use Drush on the command line).

Code migration strategy

We haven’t decided if we will rely on ‘bee’ or on drush, which is still apparently somewhat supported. For now, using drush seems to work.

“Features” is another large area of code that is not very clear. There is a beta version of it on Backdrop, but first tests didn’t seem very conclusive. Maybe we just should dump it and use whatever Backdrop uses.

We have slowly started moving Views and Content Type definitions into the Backdrop way of doing things.

As much as possible, we want to run the same modules on both Drupal 7 and Backdrop, so that we can progressively migrate. So far that seems to be possible with minor tweaks.

Data migration strategy

I am hoping to write a script that would let us install a blank instance of Backdrop, then import the platform/site information from Aegir. Probably use Backdrop tools for migration, since it is mostly just nodes.

Our forks of Provision and other modules

Each of these forks has a symbiotic branch:

This list will be updated soon with more information (drush, hosting ansible, etc).

Do you need Aegir help?

If any of the above fits with your requirements, contact Coop Symbiotic. If not, I recommend Omega8 and Concensus, they are both very different but both very awesome.

This is not a sales pitch. We are looking for partners more than clients. We are a few shops working together and everyone is pretty busy. The best way we can grow is by working together and pooling resources.

Do you recommend migrating from Drupal 7 to Backdrop for regular websites?

If your site has complex Views, Webforms or custom modules (like Aegir does), you should consider Backdrop. Backdrop has a few usability improvements, and some developer improvements for configuration management, but otherwise it seems to be pretty close to Drupal 7.

If you like Drupal and you are a developer, you should try Drupal 10. It provides the same underwhelming admin experience from 1999, but with a more modern PHP architecture.

Otherwise, then you might want to consider WordPress. There are many more affordable WordPress shops out there, than both Backdrop and Drupal.

When using CiviCRM, we recommend separating the CMS and the CRM (separate sites and hosting). A CRM iterates slowly, reflecting the core processes of your organisation. It needs to be very stable. It has very different security requirements (since it stores a lot of personal information). A website iterates quickly, adapts to your various communication campaigns throught the year.

CiviCRM Standalone has also improved a lot recently and is very close to being production-ready. The SearchKit and FormBuilder extensions also provide good alternatives to Views and Webform.

Conclusion

I am very grateful to all the work done by the old-timer Aegir folks, Omega8 for continuing to push things forward, and the Backdrop community for being there as a solid alternative.

We’ll keep you updated on our progress! Good luck with your EOL plans.