# For decision makers: should we upgrade to CBX 4?

> For owners and managers weighing the upgrade — especially sites still running CBX 2 (the older, one-off-priced generation). This lays out the concrete advant…

Source: CBX documentation, version 4.0 preview (unreleased). Canonical page: https://docs.configbox.at/docs/4.0-preview/migration-to-cb4/whats-new-for-decision-makers. Last updated 2026-08-25.

---
For owners and managers weighing the upgrade — especially sites still running **CBX 2** (the older,
one-off-priced generation). This lays out the concrete advantages and the real risks so you can decide with
eyes open. It deliberately sticks to what can be verified from the product; **commercial terms (pricing,
licensing, support windows) are not covered here — confirm those directly with Rovexo.**

> **This page weighs the jump to 4.0.** For what the 4.0 line has *gained since* — and therefore what
> the upgrade is worth today rather than at release — see
> **[Latest features](https://docs.configbox.at/docs/4.0-preview/features/latest/)**: the capability showcase, area by area, with
> every claim linked to the documentation behind it.

## The short version

CBX 4 is a modernization: a simpler, more maintainable core, current platform support, and quality-of
-life features (dark-mode admin, command-line operations, a cleaner answer model). The upgrade is **low-risk
for your storefront and order data** (they're preserved and behave the same), but it **is a real project**
if your site has custom code or you rely on the old shared-option workflow. The further back you're
starting from (CBX 2), the more of a re-platforming it is rather than a simple update.

## Advantages of upgrading

- **Modern platform support.** CBX 4 targets current Joomla 5 (and keeps the multi-platform design
  for WordPress / Magento). Staying on CBX 2 ties you to old platform versions, which increasingly
  blocks security updates to the *surrounding* CMS — often the real risk, not CBX itself.
- **A simpler product model that's cheaper to run and extend.** The old two-table "global option +
  assignment" answer model is collapsed into one clean **answers** table. Fewer moving parts means fewer
  bugs, easier training, and less custom-development cost going forward.
- **Operational tooling.** A proper command-line suite (clear caches, apply updates, read/write settings,
  run tasks) makes deploys and support faster and less error-prone — relevant if you have an agency or
  in-house team maintaining the site.
- **Admin dark mode.** The backend follows the admin's light/dark/auto preference — a small but real
  day-to-day comfort for staff who spend hours in it.
- **Better maintainability of the codebase itself.** Documented migration/customization processes, a
  running breaking-changes log, and auto-conversion shims mean future upgrades are more predictable.
- **Your data carries over.** Products, prices, carts, and orders are preserved; existing configurations
  price and display the same after the upgrade.

## Risks and costs to weigh

- **Custom code needs work.** If your site has customizations (custom fields, templates, integrations,
  brand-specific logic), some will break on the answer-model change and need updating. There are shims and
  detailed playbooks (see this docs area), and much auto-converts — but budget developer time proportional
  to how customized your site is. **A heavily-customized CBX 2 site is a migration project, not a
  click-to-update.**
- **The "shared option" workflow is gone.** If your team relied on reusing one option across many questions
  and editing it in one place, that mental model changes: answers are now independent (the upgrade splits
  shared options into separate answers as part of the migration, but *future* edits are per-answer). Factor
  in retraining — see the [operator retraining brief](https://docs.configbox.at/docs/4.0-preview/migration-to-cb4/operators-what-changed).
- **Jumping from CBX 2 is a big jump.** CBX 2 → 4 spans multiple generations of changes at once
  (platform, admin UI, data model). Expect more testing and a staging rehearsal, not an in-place production
  update. Budget for a test-migration on a copy first.
- **The engine is encoded / licensed.** The pricing/rules/calculation engine ships ionCube-encoded and
  needs a compatible ionCube loader and a valid CBX licence to run and to be rebuilt. Confirm your
  hosting meets the loader requirements and that your licence covers CBX 4 **before** committing.
- **Commercial change.** Moving off a one-off-priced CBX 2 likely changes your licensing/support
  arrangement. **This is the item to clarify with Rovexo first** — it often drives the go/no-go more than
  the technical work does. Do not assume; get it in writing.

## A sensible decision path

1. **Confirm the commercial terms with Rovexo** (licence coverage for v4, support, any pricing change).
   Settle this before technical evaluation.
2. **Inventory your customizations.** How much custom code / template overrides / integrations do you have?
   This is the single biggest driver of effort and cost.
3. **Check hosting** meets Joomla 5 + the ionCube loader requirement.
4. **Rehearse on a staging copy** — run the upgrade, run the migration, click through the admin, place test
   orders, and check every customization against the playbooks in this area.
5. **Retrain staff** on the answer-editing change and dark mode (the [operator brief](https://docs.configbox.at/docs/4.0-preview/migration-to-cb4/operators-what-changed)).
6. **Then** schedule the production upgrade with a rollback plan (a full DB + files backup first).

## Bottom line

If you're on CBX 2, upgrading to 4 is worth it for platform currency and lower long-term maintenance
— but treat it as a **planned migration project** sized to your customization footprint, and **settle the
licensing question with Rovexo up front**. Storefront and order data are safe; developer time and staff
retraining are the real line items.