Which CiviCRM release track fits your organization
For most nonprofits and NGOs, the standard release is the right starting point if your team can test and apply a new CiviCRM version every month. The standard release is free to download and use and is published monthly, so you get fixes and new features as soon as they ship. The Extended Security Release (ESR) is a slightly older, stability-focused version released every six months as a subscription priced by organization budget, from US$360 to US$1,440 a year. It is the better fit when your organization cannot absorb monthly change, and the subscription cost is worth weighing against the staff time you would otherwise spend on upgrades.
The standard track suits teams with in-house capacity: a staging copy of the site, someone who reads the release notes, and time to rerun contribution forms, membership renewals, CiviMail templates and any custom extensions after each update. Ask your current developer or hosting provider which extensions you depend on and whether their maintainers publish compatibility notes for each monthly release. If you cannot name that person or that test routine, the monthly cadence becomes a recurring risk rather than a benefit.
The ESR justifies its subscription when a staff change, a funder's audit window or a busy campaign season makes unplanned upgrades costly, or when you need a predictable version for longer periods. Confirm the current terms, the budget band that applies to your organization and what the subscription includes on CiviCRM's Extended Security Release page before you commit. Also confirm with your hosting provider and extension authors that your stack and add-ons support the ESR line you would receive.
Who should run the standard release and who should pay for stability
An organization with a staff member who owns the CiviCRM installation and can test updates before they reach users is the situation where the standard release fits best. The standard version is released monthly and is free to download and use, so the cost of staying current is mostly the staff time spent testing each release on a copy of the production site. The trade-off is cadence against testing effort: every monthly release is a small change, which is easier to review, but it arrives often enough that someone has to schedule the work.
- Test on a staging copy: Restore a recent backup to a separate environment and run the upgrade there before touching production.
- Read the release notes each month: Look for changes to contact, contribution or CiviMail behavior that your staff use daily.
- Keep a rollback path: Confirm that database and file backups can be restored in a known time window before each upgrade.
- Track the PHP and database requirements: Check that the host still matches the versions listed for the release you are moving to.
- Plan the review window: Assign a named owner and a fixed day each month, so updates are not deferred until a security fix is overdue.
Before committing to this track, confirm with the in-house lead how many hours per month they can realistically give to testing, and who covers that work during leave.
An organization run largely by volunteers, or by an IT team of one or two people who also handle email, laptops and the network, has less capacity to absorb a monthly change. Here the standard release asks for regular attention from people who may not have time to test it. The Extended Security Release is a slightly older, stability-focused version released every six months, so it trades newer features for fewer upgrade events. For this situation the predictability often matters more than the newest functionality, but the subscription cost is a recurring line in the budget and must be weighed against what the team can actually test.
- Fewer upgrade events: A six-month cadence means fewer windows in which something can break during a busy campaign or year-end appeal.
- Recurring subscription cost: The ESR is priced by organization budget, from US$360 to US$1,440 a year, so the tier must be checked against the current budget.
- Less testing capacity needed: A team without a test environment can still plan one scheduled upgrade every six months.
- Delayed features: Staff may wait longer for new functions that the standard release already includes.
- Vendor and volunteer dependence: Confirm who will apply upgrades if the one person who knows the system leaves.
Ask the organization whether it has a named person and a budget line for either track, because a subscription without anyone to run the upgrade gives little benefit.
An organization with a large number of custom or third-party extensions faces a different risk. Each extension must still work after the core changes, and the more extensions there are, the more places an update can affect. The standard release gives the fastest access to fixes, but it also means extension authors and the team must keep pace with a monthly cycle. The ESR is designed around stability, which may reduce how often extensions need rework, though the facts supplied do not state how compatibility is managed for individual extensions. Confirm this with each extension's maintainer before deciding.
- Inventory every extension: List each one with its source, author, version and the CiviCRM release it was last tested against.
- Check maintainer commitments: Ask whether each extension is updated on the same cadence as the chosen release track.
- Budget for regression testing: Each monthly release may require re-checking custom forms, reports and integrations.
- Consider the six-month window: Fewer core changes can mean fewer extension breakages, but extension updates may still be needed.
- Document dependencies: Record which extensions depend on specific core behavior so a future upgrade can be scoped quickly.
Before choosing, ask your extension developers or partner for written compatibility statements covering both release tracks.
Across all three situations the question is the same: who will test each upgrade, who will fix anything that breaks, and how much unplanned work the organization can absorb. The standard release means more frequent, smaller changes that need steady testing. The ESR means fewer, more predictable changes, at a recurring subscription cost. Neither track removes the need for backups, a staging environment or a named owner. The choice is therefore about capacity and risk tolerance, not about which version is more capable.
- Named owner: Confirm one person is accountable for applying every release on the chosen track.
- Test environment: Check whether a staging copy exists and how long a full test takes.
- Security exposure: Ask how quickly fixes reach each track and whether your security team accepts that timing.
- Budget: Compare the subscription tier with the staff hours and risk of the standard track.
- Exit path: Confirm how a switch between tracks would be handled, including data and extension compatibility.
Request current ESR terms and the release calendar directly from CiviCRM before making a commitment, since the facts supplied here may change.
What the standard and ESR releases differ on
This table sets the free monthly standard CiviCRM release beside the six-monthly Extended Security Release (ESR) subscription, row by row. Read it to decide which track fits your upgrade capacity, your tolerance for change and your budget, then confirm the open points with CiviCRM before you commit.
| Dimension | Standard release | Extended Security Release (ESR) |
|---|---|---|
| Release cadence | Released monthly, so new versions arrive often and each upgrade is smaller but more frequent. | Released every six months, so fewer upgrade cycles and a longer planning window between them. |
| Version age | Carries the newest code, including the current 6.19.1 download, which suits teams that want the latest changes. | Described by CiviCRM as a slightly older, stability-focused version, so it trails the standard line by design. |
| Cost to obtain | Free to download and use, per CiviCRM's download and ESR pages. | Subscription priced by organization budget, from US$360 to US$1,440 a year (CiviCRM ESR page). |
| Who receives updates | Everyone on the standard track, with the monthly release as the update path. | Subscribers only. Confirm with CiviCRM whether ESR security fixes are delivered on the same schedule as standard fixes. |
| Feature content | Same codebase as the ESR track. Confirm with CiviCRM which features and fixes reach each track and when. | Same codebase as the standard track, but on an older cut. Confirm which features are withheld or delayed, if any. |
| Extension compatibility | Extension authors may target the newest release first, so test each extension against every monthly change. | Teams often find extensions more stable on a fixed, slower cut. Confirm with your extension authors which versions they support. |
| Who should pay for stability | Teams with in-house developers or a partner who can absorb monthly upgrades and regression testing. | Organizations that need a predictable upgrade calendar, limited change windows or a documented support path for a budget-bound team. |
License and update terms for each release track
Both CiviCRM tracks run the same AGPL-3.0 core, so the license does not decide between them. The difference lies in what the vendor promises about release cadence, stability and fixes, and in what you pay for. Read each card as a question to put to CiviCRM before you commit budget.
AGPL-3.0 core applies to both tracks
CiviCRM core is licensed under AGPL-3.0, and that license covers the standard release and the ESR alike. Paying for the ESR does not change your right to use, modify or redistribute the core under those terms. What you buy is a different release schedule and vendor commitment, not a different license. Confirm with your counsel how AGPL-3.0 obligations apply if you host a modified CiviCRM for users outside your organization, since those obligations follow the code rather than the subscription.
Standard release is free and monthly
The standard CiviCRM version is released monthly and is free to download and use. Each monthly release brings the newest features and fixes, so you must keep pace with that cadence to stay current. The cost of the standard track is the staff or partner time to test each release against your extensions, your CMS and your data, plus the work of applying it on a schedule. Ask who on your side owns that testing and how much time a monthly cycle takes in your environment.
ESR is a six-monthly subscription
The Extended Security Release is a slightly older, stability-focused version released every six months, sold as a subscription. Its price is set by organization budget, between US$360 and US$1,440 a year, so it recurs for as long as you keep it. Check whether the subscription renews automatically, what happens to your access if you lapse, and whether you can move back to the standard track without a migration project.
Security fixes on each track
The main reason to choose the ESR is a steadier path for security fixes with fewer feature changes to absorb. The standard track also receives fixes through its monthly releases, so the real question is how quickly fixes reach each track and whether the ESR carries fixes that the standard track does not. Put this to CiviCRM in writing: which security fixes go to each track, how fast, and what your obligations are if you run a version that has passed its support window.
Support and warranty terms
Check what the subscription includes beyond the files: named support channels, response expectations, indemnity wording and whether any warranty applies to your use. Stability promises are only as strong as the written terms behind them, and a general statement on a marketing page is not a contract. Request the current terms of service and the ESR terms before purchase, and have them reviewed against your procurement and risk policies.
Drupal 7 support window
CiviCRM warns that the Drupal project has ended support for Drupal 7. An ESR subscription does not remove that exposure, because the risk sits in the CMS underneath CiviCRM. If you run CiviCRM on Drupal 7, confirm which CiviCRM release your subscription supports on that platform and plan a move to a supported Drupal or to Standalone, since no subscription will extend a platform that its maintainers have stopped supporting.
Extension compatibility under each track
Extensions are often the hardest part of an upgrade. An ESR gives you fewer version changes, which can reduce how often you must retest extensions, but it does not guarantee that a third-party extension works on either track. Before you choose, list your extensions, their maintainers and their last compatible CiviCRM release, and ask CiviCRM which extensions it tests against the ESR. Keep a rollback plan for each track.
How security fixes reach each release track
A team on the standard CiviCRM release receives security fixes as part of the monthly release train. Each month a new version ships, and the team that runs it is expected to move to that version to pick up whatever changed. The fix arrives in the same package as feature work, so the upgrade you apply each month is both your security patch and your functional change. The ESR track works differently. It is a slightly older, stability-focused version released every six months as a subscription, so an ESR subscriber takes a smaller number of larger changes and stays on a line that CiviCRM maintains for that purpose. Read the CiviCRM Extended Security Release page for the product description, then ask CiviCRM in writing how and when security fixes are delivered to ESR subscribers between six-monthly releases, and whether any of those fixes are back-ported to the older line.
The slower cadence changes the testing workload rather than removing it. On the monthly track, your test cycle repeats every month: you need a staging copy of the site, a regression pass over the contributions, membership, event and CiviMail workflows you depend on, and a check of every extension you have installed, because an extension can break on any new core version. On the ESR track, each upgrade covers six months of change, so the regression surface per upgrade is larger but the number of upgrades falls. Either way, the work sits with your team or your partner. Estimate it from your own extension list and your own test cases, not from a generic figure, and confirm with the extension authors which versions they test against. Before you commit to either track, ask CiviCRM to confirm the ESR security-fix commitments, the window between a vulnerability being fixed upstream and the fix reaching ESR subscribers, and the terms that apply if a critical issue lands between releases.
Moving from the standard release to the ESR, or back
This sequence tells you whether your current CiviCRM install can move between the monthly standard release and the six-monthly Extended Security Release without breaking extensions, hosting or data. It ends with a dated switch plan that your team has tested on a copy of production.
Record your current version and host
Confirm which CiviCRM version runs in production, which CMS it sits inside (Standalone, WordPress, Drupal, Joomla or Backdrop), and the PHP and database versions on the server. Check the CiviCRM requirements page for the version you run, since 6.16 and later recommend PHP 8.3, 8.4 or 8.5 and need MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible. Your team or host owns this inventory. It is done when you have a written record of version, CMS, PHP and database, and you have confirmed that all of them sit within the supported ranges.
Check the CMS and PHP upgrade path
If the record shows Drupal 7, treat that as a blocking item. CiviCRM warns that the Drupal project has ended support for Drupal 7, so a move to a current CiviCRM release usually requires a CMS upgrade first. Confirm with your web host and CMS maintainers whether the PHP version you need is available on the server. The current standalone download is 6.19.1, and you should confirm which CMS builds your chosen track supports before you plan any change. It is done when a named person has signed off that the CMS and PHP combination is supported for the target release.
Decide the release track
Choose between the monthly standard release, which is free, and the Extended Security Release, which is a slightly older, stability-focused version updated every six months and sold as a subscription priced by organization budget from US$360 to US$1,440 a year. Ask CiviCRM which current subscription tier matches your budget and whether the ESR line supports your CMS and PHP. Record the decision with the reasons, including who approves the recurring cost. It is done when the track, the tier if applicable, and the approver are written down.
Inventory and test extensions on staging
List every installed extension, theme and custom PHP or Smarty change, with its current version and its maintainer. Build a staging copy of the live site with a recent database backup and attach the target CiviCRM release. Install and run each extension, then test contributions, memberships, events, CiviMail, scheduled jobs and any payment processor on the staging copy. Extensions that do not declare support for the target release are the main risk, so ask each maintainer in writing. It is done when every extension has a pass or fail result and each failure has an owner and a fix or a removal decision.
Rehearse the upgrade and rollback
On the staging copy, run the full upgrade procedure from the current release to the target release, including database schema updates and clearing caches. Time each step with your own tooling and record the actual duration, since no published duration applies to your site. Then restore the pre-upgrade backup and confirm the site returns to the prior state. It is done when a rehearsal completes end to end, the rollback restores a working site, and the runbook reflects what you actually did.
Plan the production switch
Agree a change window with the people who depend on the CRM, such as fundraising, membership and event staff. Freeze configuration changes, take a full backup of files and database, and confirm the rollback steps and the person authorized to trigger them. Notify your payment processor and email sending provider if their integrations depend on specific versions. It is done when the change ticket lists the backup location, the rollback owner and the sign-off from business users.
Switch and verify production
Apply the target release to production during the agreed window, run the upgrade, and clear caches. Then check key workflows: a test contribution, a membership renewal, an event registration, a scheduled job run and a test mailing. Review the logs for errors. It is done when those checks pass and the business owners confirm in writing that the site is in use.
Set the next switch date and keep the backup
Record the new release line, the support expectations you agreed, and the next date you will review the track, since the standard release moves monthly and the ESR moves every six months. Keep the pre-switch backup for the period your retention policy requires. Moving back to the other track follows the same steps, so keep this runbook current. It is done when the calendar entry, the retention record and the updated runbook are stored where the operations team can find them.
How extension compatibility shapes the release decision
Extension compatibility is often the factor that decides between the monthly standard release and the Extended Security Release. An organization with a handful of extensions from the public catalog and no custom code can usually absorb a monthly upgrade with a short test cycle. An organization with many third-party or custom extensions faces more work on the monthly track, because each release can change the APIs, hooks and database assumptions those extensions depend on. Every extension is a separate compatibility question, and the cost of answering it repeats each month. A stability-focused release reduces that churn by changing the pace, not the problem. Fewer upgrades mean fewer rounds of regression testing across the extension set and fewer windows where a broken extension forces an emergency fix. The trade-off is that the extension maintainer may target the current release first, so the organization still has to confirm that each extension it depends on supports the ESR line before it commits. The CiviCRM Extended Security Release page describes the subscription and its release cadence, which is the starting point for that comparison. Before choosing a track, build an inventory of every extension, its version, its source, its maintainer and the CiviCRM versions it declares as supported. Ask each maintainer in writing which CiviCRM releases they test against, and how quickly they publish fixes after a new release. Record any custom extension that a DeployOpen-style implementation partner or your own developers wrote, because those have no external maintainer and carry the full testing burden. If a critical extension has no confirmed support for the release line you are considering, that finding should settle the decision before budget does.
Questions buyers ask before choosing a CiviCRM release track
Is the standard CiviCRM release really free to use?
Yes, the standard CiviCRM release is free to download and use, and it is released monthly. The licence cost is zero, but the work around it is not. Your team or your partner still pays for hosting, the time to apply each monthly update, regression testing of your extensions and theme, and any fixes needed when an update breaks something. Ask any provider to split a quote into one-time setup work and recurring upkeep, so you can see what the free release actually costs you each year.
What does the CiviCRM Extended Security Release cost?
The Extended Security Release is a subscription priced by organization budget, and CiviCRM's published range runs from US$360 to US$1,440 a year. The tier you land in depends on your organization's budget, so confirm which tier applies to you on the CiviCRM Extended Security Release page before you plan spend. The subscription is a recurring cost, and it covers the ESR line itself, not the hosting, testing or support work you still need to run it.
Can our own team run CiviCRM upgrades without outside help?
Often yes, if you have a developer who is comfortable with PHP, MySQL or MariaDB, and the CiviCRM host platform you chose. The main drivers are how many extensions you run, whether they are maintained by a third party, and how much custom code touches the database. A small site with a few stable extensions and a staging copy is a realistic fit for an in-house team. A site with many custom extensions, several integrations and public forms usually needs more testing time and a clear rollback plan, which is where outside help tends to pay off.
How long does upgrade testing take, and what makes it longer?
No supplied figure gives a standard testing duration, so ask any provider for an estimate built from your own scope. The biggest drivers are the number of extensions and their maintenance status, the size of your contact database, how many custom forms, reports and payment or email integrations depend on core behavior, and whether you have a staging environment that mirrors production. Testing scope also grows when you move between a monthly release and a six-monthly ESR line, because the two tracks can differ in features and extension compatibility. Put the test checklist into the written scope before work starts.
Which parts of a CiviCRM upgrade need a second pair of hands?
Outside help is most useful where the risk is highest, not for every routine update. Bring in a specialist when you run a large number of extensions, when you are moving to a new major version or a different host, when your data model has been customized, or when you need a documented, repeatable upgrade runbook for auditors or board reviews. DeployOpen plans, implements, upgrades and documents self-hosted platforms inside the client's own infrastructure, and work is usually agreed as a fixed scope with written deliverables. Retainers are available for ongoing upgrades and support.
Which release track suits an organization that needs stability most?
The Extended Security Release suits organizations that value a slower, predictable cadence and can accept that it is a slightly older, stability-focused version. The standard monthly release suits teams that have the capacity to test and apply updates every month and want features and fixes as soon as they ship. Choose by how much change your staff can absorb, not by the headline price. If an upgrade failure would stop donations, memberships or event registration, weigh the subscription against the cost of a bad month.
What should we check on our hosting before picking a release?
Check the requirements for the release you intend to run before you commit. CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5 and need MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible. Also confirm which CMS you will run CiviCRM on, since the download supports standalone, Backdrop, Drupal, Joomla and WordPress installs, and note that the Drupal project has ended support for Drupal 7. Confirm these details against the CiviCRM requirements page for your target version.
What the cost of each track includes beyond the subscription
The free standard download carries no license fee, but it is not a zero-cost track. Your organization pays for the servers or hosting that run CiviCRM, for the staff hours to apply a new monthly release, and for the testing that proves your sites, forms, contribution pages and scheduled jobs still work afterward. CiviCRM's download page lists the current release as 6.19.1, and the standard version is released monthly, so these tasks recur every month rather than once. Most of the recurring cost sits in people time, which is why the question to ask is not what the download costs but who will do the upgrade and how long they have to do it. The ESR adds a subscription that CiviCRM prices by organization budget, from US$360 to US$1,440 a year according to its published Extended Security Release page. That fee buys a slightly older, stability-focused release every six months, so the upgrade cycle is slower, but it does not remove the work. You still pay for hosting, for the upgrade and testing effort at each six-month step, and for any extensions you depend on. Confirm with CiviCRM which budget band applies to your organization and whether the subscription covers the full range of security fixes you expect to need.
Several factors push effort up or down. Extension count and maintenance status matter most: each third-party extension you depend on must be checked against the new release, and an abandoned extension can force custom work or a replacement. The CMS you host inside (Standalone, WordPress, Drupal, Joomla or Backdrop) changes the upgrade path, as does any Drupal 7 install, which CiviCRM flags because Drupal has ended support for that version. Your database and PHP versions also matter, since CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5 and do not support PostgreSQL. When you request a quote from an implementation partner, ask for each cost line separately: the one-time setup and extension review, the recurring monthly or six-monthly upgrade and test cycle, the hosting environment and its monitoring, and the ESR subscription if you choose that track. Ask who performs rollback if a release fails, how many staging environments are included, and how extension compatibility is checked before each upgrade. Written scope and assumptions should show which of these are included and which are billed separately.
Official CiviCRM sources for release and pricing terms
These four sources cover what CiviCRM publishes about its free monthly release, the paid six-monthly Extended Security Release, platform requirements and the open-source code itself. Read them together before you commit to a release track, because the download page, the ESR terms and the requirements can change independently of each other.
Standard release download terms
The download page lists the current release, 6.19.1, and the platforms it installs on: standalone, Backdrop, Drupal 10 and later, Drupal 7, Joomla 5 and later, and WordPress. Check which CMS you plan to host on, because the supported combinations determine whether a monthly upgrade is a routine task or a migration. The same page carries the warning about Drupal 7 support ending, which matters if your current site still runs that version.
ESR subscription terms
The Extended Security Release page describes the six-monthly, stability-focused track sold as a subscription, with prices tiered by organization budget. Confirm the current tier that matches your annual budget, what the subscription includes, and whether it covers the security fixes you need on your own schedule. Ask whether renewals change the tier and how a lapsed subscription affects your upgrade path.
Platform requirements
The requirements documentation sets the PHP, MySQL and MariaDB versions CiviCRM supports, and states that PostgreSQL is not compatible. Compare these against your hosting image before choosing a release, since an ESR or standard upgrade can require a PHP or database change first. Note that the recommended PHP versions for 6.16 and later differ from older platform images that many hosts still ship.
Core source and license
The civicrm-core repository holds the code under AGPL-3.0, so your right to run, modify and redistribute it does not depend on which release track you buy. Review the license file and the release history yourself if your legal team needs to confirm terms before signing. Remember that the license covers the code, not the ESR subscription or support, so those are separate contracts to review.
Confirming the ESR fit with your team
Ask CiviCRM directly whether your installed extensions are tested against the ESR branch, since extension compatibility is the most common reason an organization stays on the standard release. Request the written list of what the subscription includes and what happens to security patches for releases outside it. Your own test environment should run the candidate release against your extensions before any production change.
How DeployOpen scopes and supports either CiviCRM track
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For CiviCRM, that means working out which release track fits your organization, then building and handing over the environment on that track, whichever one you choose.
How we scope
- Written scope fixes which CiviCRM track, host platform and extensions are covered before work starts
- Scope lists the upgrade cadence your team will run, including who applies each monthly or six-monthly update
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins
How we build
- Installation on your own cloud account, data center or air-gapped network, using the PHP and MySQL or MariaDB versions CiviCRM documents
- Extension compatibility checks against the chosen track, with results recorded before any production change
- Hardening, backup and restore configuration tested in your environment, not only described on paper
How we hand over
- Runbooks covering the upgrade procedure, rollback steps and the decision points for moving between tracks
- Documentation of configuration, access, extensions and evidence your compliance team can review
- Knowledge transfer sessions so your administrators can run routine upgrades without outside help
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build
- Retainer scope can cover monitoring of new CiviCRM releases and planned upgrade windows for your track
- Ask in any quote which party pays for ESR subscription fees, since DeployOpen does not resell that subscription
