KNOWLEDGE BASE ARTICLE · QPP NEXTGEN
Your New Upgrade Schedule: How the Shared Platform Works
How multi-tenant QPP NextGen environments are upgraded, notified, validated, and protected against regressions.
Overview
From 15 October 2026, all QPP NextGen environments on a multi-tenant subscription run on Quark's shared, multi-tenant infrastructure. This means every customer in a region runs the same software version and is upgraded together on a fixed, published schedule.
Previously, your environment was operated as a dedicated single-tenant deployment: upgrade scheduling was coordinated with your team, and confirmation was requested before any upgrade proceeded. That model no longer applies to multi-tenant subscriptions. This article explains the new process in full.
What has changed and what has not
What is changing
- Upgrades are applied automatically on a shared schedule — no individual confirmation is required or possible.
- All customers in a region move to the same software version at the same time.
- You can no longer defer, decline, or schedule upgrades independently.
What is not changing
- Where your data lives. The shared infrastructure runs within your own region only. Data in your region stays in your region; content, logs, audit records, backups, and disaster-recovery copies are unaffected.
- Separation from other customers. Your data is processed individually from the moment a request enters the system, held in its own database, with that separation extending to storage, backups, and audit records. No data or services are shared between tenants — only the software version is the same.
- How you connect. Hostnames, APIs, user logins, and your own configuration continue to work exactly as they do today.
- Your customisations. Customer-specific configuration and customisations are expected to carry over and operate as they do now.
- Your contractual commitments. Existing terms, service commitments, and data protection obligations remain in effect and unchanged.
How releases will reach your environments
Quark produces a new release of QPP NextGen every week. Each release is validated internally before it reaches any customer environment. Your environments then follow a fixed two-week rhythm.
Before you see it — Internal testing
Every release passes the full automated regression suite, then runs on Quark-internal environments for several days of platform-health and specialist checks. A release that does not clear this gate is never deployed to you.
Saturday, Week 1 — Your non-production environments
All of your non-production environments — development, QA, and UAT — receive the same release simultaneously in a single Saturday window. They hold that version for the full two weeks. If a defect is found and the release is held, a corrected release replaces it; otherwise the version does not change during this period.
Saturday, Week 3 — Your production environment
Production is promoted to the same version — but only after two clean weeks with no critical issues reported during your UAT validation period. After each production promotion, your UAT environment moves one cycle ahead again, so it always gives you a two-week preview of what production will run next.
Important: There is no fast path for small changes. No planned release reaches your production environment on the strength of the change being minor.
Because each weekly release includes all work from previous weeks, receiving a release every two weeks rather than every week means you lose nothing — the version you receive already contains the intervening fixes and improvements.
Maintenance windows
Upgrades to both non-production and production take place in your region's Saturday maintenance window. Both events — the Week 1 non-production deployment and the Week 3 production promotion — use the same window, so there is a single recurring time for your team to record.
| Region | Window opens (UTC) | Local equivalent |
|---|---|---|
| AP | Saturday 19:00 UTC | Sunday 05:00 AEST / 06:00 AEDT |
| EU | Saturday 21:00 UTC | Saturday 21:00 GMT / 22:00 BST or CET / 23:00 CEST |
| US | Saturday 21:00 UTC | Saturday 16:00 EST / 13:00 PST |
A regular upgrade typically causes 30 to 60 minutes of unavailability. The window is reserved for up to two hours so the figure you plan against does not move from cycle to cycle.
Times are fixed in UTC. Your local time will shift by an hour across daylight saving transitions. We recommend recording the UTC time in your change-management system.
No action is required from you or your users during a maintenance window.
Advance notice you will receive
Scheduled upgrades: Your Quark Customer Success Manager writes to you at least 72 hours before each scheduled upgrade. If the release does not clear its internal testing after the notice is sent, the notice is withdrawn and no upgrade takes place that weekend.
Release notes: Published before each deployment to your environments, covering new features, fixes, known issues, and any breaking changes or deprecations. Because your UAT environment receives the release two weeks ahead of production, you can also verify behaviour directly.
Emergency fixes: Issued as soon as practicable, with notice given before the change wherever possible. A critical defect or security issue affects every customer in the region, so these move on a faster path than the standard 72-hour notice allows. An emergency fix still passes full regression testing and may be deployed outside the Saturday window.
Off-schedule changes: If a release is held or a promotion date changes for any reason, Quark will notify you directly.
Your two-week UAT validation period
The two weeks between the non-production deployment and the production promotion are yours to test the release against your own content, configuration, and workflows before it reaches production. The version in your UAT environment at any point is the exact version your production environment will receive next — a stable preview, not a moving target.
If your organisation runs an internal acceptance or change-control process, UAT is where that process now runs.
If you find a problem during UAT
- Report it through your normal Quark support channel and state that it was found in UAT during the validation period.
- A defect is considered blocking if it causes loss of core functionality or data with no reasonable workaround, if it is a security issue, or if it is a regression that would disrupt production use.
- Reports received by Thursday 23:59 UTC before a promotion Saturday are assessed for that promotion. Reports received after this deadline are still assessed and can still stop a release.
- A confirmed blocking defect stops the release from reaching production for you and for every other customer in your region.
- You will be informed of the outcome either way.
Note: Your UAT and production environments will never run the same version by design. UAT always runs one cycle ahead. If you compare behaviour between the two environments, expect UAT to be the newer of the two.
If a release is held before it reaches production
A held release is discarded, not postponed. Your production environment stays on its current version and never receives the held release. A corrected version is built and enters the full validation cycle from scratch.
How long this adds to your upgrade timeline depends on when the defect is found:
- Found early in the two-week period: approximately one additional week
- Found late in the two-week period: approximately two additional weeks
- Add one further week for each weekly release the fix misses
Quark will give you the revised upgrade date.
If a critical defect reaches production
Where it is safe, Quark rolls production back to the previous version. This is the preferred remedy when the problem came from the most recent upgrade and nothing irreversible was included in it.
If a rollback is not safe, Quark prepares a targeted emergency fix. This fix still passes full regression testing and may be deployed outside the Saturday maintenance window.
What you can no longer do on the shared platform
| Previously available | Status |
|---|---|
| Deferring or declining an upgrade | No longer available |
| Remaining on an earlier version (version pinning) | No longer available |
| A maintenance window specific to your organisation | No longer available |
| Upgrades scheduled around your own change-freeze periods | No longer available |
| Requesting a selective or out-of-cycle upgrade | No longer available |
If your organisation operates formal change control, it will need to align to the published Saturday windows. The two-week validation period is designed specifically so that alignment is workable: your testing happens inside time already built into the schedule, against the exact version production will receive next.
What you can rely on
- A fixed, published window that does not move week to week
- At least 72 hours' advance notice before every scheduled upgrade
- A full two-week preview of every planned production change, in your own UAT environment
- A production version you can determine at any time
- Release notes published before every deployment
- Fixes and security updates on a predictable rhythm, with a faster path for critical issues
- Every release tested by Quark before it reaches you
- You can always check upcoming release dates on the QPP Release Tracker: trilogy-group.github.io/qpp-release-tracker
If the shared platform schedule does not fit your organisation
Some organisations need more time for testing, validation, or internal approval than the shared schedule allows. If that is the case, a dedicated single-tenant deployment remains available: an application environment reserved for your organisation, with upgrade timing coordinated with your team.
Please raise this with your Quark Customer Success Manager early — not close to a scheduled window — so there is time to discuss your requirements, migration timing, and the associated subscription terms.
<supportagent>
AGENT ONLY
Only surface this section (or otherwise suggest the Single Tenant option) when the customer's own query indicates they want control over upgrade version or timing — for example, asking to stay on an older version, pick their own maintenance window, or defer/skip an upgrade. Do not proactively offer ST in response to general questions about the upgrade schedule, maintenance windows, or notice periods.
</supportagent>
Scope
This applies to QPP NextGen only. Other Quark products are not affected.
<supportagent>
AGENT ONLY
CRO (Customer-specific Reserved/Operational) deployments exist for a small number of select partners (e.g., Glemser) and are not part of this KB or the standard customer offering. Do not mention CRO proactively under any circumstances. If a customer already references CRO themselves, do not confirm details or scope from this article — escalate to the support team to handle the CRO-specific question directly.
</supportagent>
Csaba Daniel
Comments