CONTROLLED SOFTWARE RELEASES

Updates & Maintenance

Prepare the next release before moving live traffic.

Business owners and IT contacts who need to understand what to expect during a release.

Detailed product guide in English. Existing translated product summaries and the language selector remain available.
WHAT THIS MEANS FOR YOUR BUSINESS

Prepare the next release before moving live traffic.

In ZOVRO’s configured blue/green ERP deployment setup, the current application serves users while an update is prepared on a standby instance. The release is validated before an authorized switch. This approach reduces avoidable application-update interruption; it does not make the website, network, database or every maintenance task immune to downtime.

CAPABILITIES IN PRACTICE

What your team can do.

Understand the activity, its controls and the information available for follow-up.

01

A separate application slot

The standby instance provides a place to install a candidate without immediately replacing the live application. Both slots must remain compatible with the shared data they use.

02

Checks before switching

The supplied deployment flow checks the artifact, target health, routing consistency and session-store readiness before switching traffic.

03

Eligible sessions can persist

Database-backed sessions are designed to preserve eligible logins across compatible updates. Explicit logout, expiry, security revocation and incompatible changes remain separate considerations.

04

Verification and reverse switch

The team verifies the active release after switching and can use a healthy compatible previous application for reversal. Application rollback does not undo business transactions or database migrations.

THE WORKFLOW

A meaningful step at every stage.

Follow the process from preparation to review. Configuration and responsibilities are agreed during implementation.

  1. 1

    Prepare the update

    Keep the current slot live and upload the candidate to the standby process.

    What this producesA candidate without an immediate traffic change.
  2. 2

    Validate readiness

    Check artifact identity, target health and data/session compatibility.

    What this producesEvidence for a release decision.
  3. 3

    Switch deliberately

    Authorize the traffic move and verify the new active route.

    What this producesThe intended application serving users.
  4. 4

    Observe and retain recovery

    Review sessions and critical workflows; retain a compatible recovery path.

    What this producesA monitored release with clear limits.
A PRACTICAL EXAMPLE

Bring this scenario to your demo.

A routine compatible application release can be prepared while users continue using the live instance. A destructive database migration, operating-system reboot or DNS incident is a different operation and needs separate assessment and communication.

Discuss your workflow →
A SIMPLE TECHNICAL VIEW

Prepare. Verify. Switch. Observe.

Illustrative ERP blue/green architecture—not a promise of infrastructure redundancy.

Your teamNormal ERP browser access
Controlled traffic switchReadiness checks and authorization
LIVE

Current application

Serves requests while the next release is prepared.

STANDBY

Verified candidate

Receives traffic after the required release checks.

Compatible business data & persisted sessionsSchema changes need their own compatibility assessment.
BEFORE YOU DECIDE

Your questions, answered.

Confirm the selected release, integrations, hardware and limits in the agreed scope.

Does this mean zero downtime for every situation?

No. The architecture reduces avoidable application-release interruption. Infrastructure, DNS, network, database and external-service incidents can still interrupt access.

Will users never need to log in again?

No. Eligible sessions can persist during compatible tested updates, but normal expiry, logout and security changes still apply.

Does switching back reverse every change?

No. A traffic rollback selects an application version; it does not reverse database changes or transactions already saved.

Are two slots the same as independent disaster recovery?

No. Two application instances on one server still share infrastructure failure risks. Backups and broader recovery arrangements are separate topics.

CONNECTED SOLUTIONS

Follow the process further.

YOUR NEXT STEP

Show us how your business works.

Tell us about your locations, users and daily challenges. We will map a focused demonstration to your needs.

Read practical business articles →
Book a demo