Release and Update Cycle
The release and update cycle describes the rhythm and form in which a software vendor delivers new versions, features, bug fixes and security updates. In an ERP context it determines how often a company receives new features, how long a version is maintained and how much effort applying updates involves.
The release and update cycle is the planned rhythm in which a software vendor publishes new versions of its application and supplies existing versions with fixes. It defines when larger feature leaps (releases) appear, how often smaller improvements and bug fixes (updates, patches) follow and how long a version once delivered is still supported with security corrections at all. In short, it answers the question: "How and how often does the software my company uses every day change?"
In the ERP world this cycle is especially consequential, because the ERP system runs a company's central, business-critical data foundation. New releases bring additional features, legal adjustments and security fixes – but at the same time force testing, training and sometimes the adaptation of individual extensions and interfaces. Anyone who knows the release and update cycle of their ERP and plans it into their own operations avoids nasty surprises: outdated versions without support, breaking interfaces or missing mandatory features such as the e-invoice.
At a glance
- Release and update cycle = rhythm and form in which a vendor delivers new versions and fixes
- Typical tiers: major release (large innovations), minor release (features), patch/hotfix (fixes)
- Cloud/SaaS ERP is usually updated continuously and automatically, on-premise often in large version leaps
- Every version has a lifecycle with a defined end of support and maintenance (end of life)
- Individual customizations and interfaces must remain upgrade-capable, otherwise update effort rises
How a release and update cycle works
A release and update cycle sorts software changes into tiers of different size. At the top is the major release: a new main version with noticeable feature extensions, a changed user interface or rebuilt technology. Below it lie minor releases, which add smaller features and improvements without changing the basic structure. At the very bottom are patches and hotfixes – narrow corrections for bugs or security vulnerabilities that are applied as quickly and with as little risk as possible.
Many vendors make this gradation visible through a version number. In the widespread "semantic versioning" scheme, the notation MAJOR.MINOR.PATCH (for example 12.4.1) means the first number rises for large, potentially non-backward-compatible changes, the second for new features and the third for pure fixes. Based on the number, a company can therefore recognise how extensive and how risky an upcoming update is likely to be.
Fixed dates or rolling delivery
Vendors choose different delivery models. In a scheduled cycle, releases appear at fixed points in time – for example two large releases per year plus monthly correction updates. This creates predictability: companies know in advance when they need to test and train. In the rolling, continuous model (continuous delivery), by contrast, changes flow into the production environment continuously in small steps, often unnoticed in the background. This is typical for cloud services and spreads the risk across many small leaps instead of a few large ones.
Release, update, patch and hotfix: the terms distinguished
The terms are often mixed up in everyday use but mean different things. A release is the delivery of a named version with a clear scope of features. An update is the process of bringing an existing system to a newer state – this can be a switch to a new release or the application of a smaller fix. A patch is a narrowly defined correction of a specific bug or security vulnerability; a hotfix is a particularly urgent patch delivered outside the regular plan and under time pressure.
The term also needs to be distinguished from an upgrade and a system change. An upgrade usually denotes the jump to a higher main version of the same product and is often associated with greater effort. A system change, by contrast, means switching to a different product and generally requires a complete data migration – something fundamentally different from an update within the same system.
Release and update cycle in the ERP system
For an ERP, it is above all the operating model that decides how updates proceed. A cloud ERP in the SaaS model is operated centrally by the vendor and usually updated automatically: all customers use the same continuously maintained version, and individual update dates largely disappear. This reduces a company's own effort and keeps the system up to date in terms of security, but it also removes control over timing from the company – a feature change can appear at any time and must still fit into existing workflows.
With an on-premise installation or self-hosting, update authority lies with the company. It decides when which release is applied, but must provide a test environment, time windows and personnel for it. The advantage is control and predictability; the price is effort and the risk that older versions stay in use too long out of convenience and fall out of support. In both models, responsibilities, test steps and fallback plans should be recorded in the procedural documentation.
Why customizing and interfaces must remain upgrade-capable
The most expensive point of friction with ERP updates is individual customization. If a system is altered through deep customizing, every major release can break these adjustments – then they have to be re-adapted and re-tested after every update. The same applies to interfaces and extensions via an API: if the vendor changes data structures, connected shops, marketplaces or accounting systems have to follow. It is therefore considered upgrade-safe to solve adjustments as far as possible through documented parametrisation and stable interfaces instead of interventions in the core.
Why the release and update cycle matters
The cycle is more than a technical footnote – it has direct business consequences. Regular updates close security gaps, deliver new features and keep the system compatible with connected services. Anyone who postpones updates, by contrast, accumulates technical debt: the jump from a very old to a current version grows larger, riskier and more expensive with every skipped release. Once a version finally runs out of support (end of life), there are no more security corrections – a serious risk for a central business system.
At the same time, every update is an intervention in ongoing operations and needs to be prepared. It has proven effective to first check releases in a test environment, verify affected processes and interfaces and involve the key users early. The vendor's release rhythm is thus also a selection criterion: a predictable cycle with a clear maintenance commitment is easier to integrate into operations than an unclear, erratic delivery.
DACH specifics: legal updates
In German-speaking countries, the release and update cycle has an additional, legal dimension: an ERP must be continuously adapted to legal requirements. Changes in VAT rates, new formats such as the e-invoice under EN 16931 (XRechnung, ZUGFeRD), requirements of the GoBD or, in Austria, the cash register security regulation (RKSV) must arrive in the system on time. Whether and how quickly a vendor delivers such mandatory adjustments through its regular cycle is a central criterion for companies in the DACH region.
It is precisely here that the cloud model plays to its strengths: legal changes are entered centrally and are automatically available to all customers, often before the deadline. With on-premise systems, the company itself must ensure the corresponding update is applied in time. In both cases, the question of legal update reliability belongs in every serious ERP selection – a system without a reliable maintenance commitment quickly becomes a compliance risk in the DACH region.
Example
Example: e-invoicing obligation hits two retailers
Two mid-sized B2B retailers face the introduced obligation to be able to receive and generate electronic invoices in the XRechnung format. Retailer A uses a cloud ERP with a continuous update cycle. The vendor delivers the new feature via a regular release that becomes active automatically in all tenants; A merely has to test the new fields and train its staff. Cost and time remain manageable.
Retailer B operates a three-year-old on-premise version whose maintenance period has expired. The e-invoicing feature is only available in the current major release. B therefore first has to catch up on several skipped versions, rework adapted customizing and an accounting interface and check everything in a test environment – a project of weeks rather than days. The example shows how strongly a maintained release and update cycle determines the effort involved in mandatory legal features.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Release and Update Cycle in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.