Why Hyperswitch upgrades need a plan before the next release lands
Hyperswitch upgrades and post go-live support are recurring work that needs an owner, a test path and a rollback plan. A self-hosted deployment has to keep pace with a release cadence of roughly one minor release a month. The GitHub releases page lists v1.126.0 (August 24, 2026), v1.127.0 (September 28, 2026) and v1.128.0 (October 16, 2026), and each release publishes a compatibility matrix for Control Center and web client versions. Teams that treat each release as a one-off project tend to fall behind within a few cycles, then face a large catch-up upgrade with little time to test it.
Four kinds of event should start upgrade work. The first is a new release, which may include database changes for the PostgreSQL primary and replica that the Router and Scheduler services depend on. The second is a security fix, which can arrive outside the normal monthly rhythm and needs a faster decision. The third is a new required dependency. The v1.124.0 release notes state that Superposition became a required configuration dependency, and deployments must have a Superposition service running before upgrading to that version. The fourth is a version mismatch between the core app server and the Control Center or a client SDK, which often appears first as failed dashboard actions or errors in a checkout flow.
Each trigger touches a different part of the stack, so one generic change process will not cover them all. Redis serves caching and the scheduler queue, so a change to the Scheduler can affect retries that are already in flight. The card vault is a separate Rust service, and its upgrade path should be checked on its own, because the vault model you run determines which PCI DSS evidence must be refreshed after a change. Ask your team to list the components each release touches before a window is booked, and treat any change to the vault or encryption service as a separate review item.
Before the next release lands, confirm five things: the Hyperswitch version running in each environment, whether a Superposition service is already deployed, which Control Center and SDK versions sit in front of the core app server, whether a staging environment mirrors production connector configuration, and who can approve a rollback during a change window. Write the rollback as a path you have actually run in staging, including what happens to payments that are routed or retried while the change is in progress.
Most teams split this work between an internal platform owner and an outside partner. The internal owner usually keeps the decision to upgrade, access to the Kubernetes cluster and sign-off on any change that affects live payment traffic. The partner typically carries release review, test runs, runbook updates and support after go-live. The exact split, and what each side should pay for, is explained later on this page, so decide now who holds the on-call duty and who approves a window.
What an upgrade and support engagement includes
Every upgrade engagement starts with scope and deliverables agreed in writing before work begins. The six components below run in sequence, so each one produces the input the next one needs, from the upgrade plan through to a change record and post-go-live support.
Release intake and impact review
Each monthly minor release is read against your deployed versions, enabled connectors, routing rules and custom code before anyone schedules a change. The review sorts release notes into items that affect your configuration, items that need a database change and items that do not apply to your estate. The client receives an upgrade plan that names the source and target versions, the reason for the move, an owner for each change and a decision on whether to skip a release. Confirm which version you run today and which Control Center version sits beside it.
Compatibility checks across components
Each target release publishes a compatibility matrix for Control Center and web client versions. The Android, iOS, React Native and Flutter SDKs release on their own schedules, so pairings must be checked as a set. The engagement tests the core app server, Control Center and the SDKs your merchants use against the target versions and records every pairing that fails. The client receives a compatibility record listing tested pairings, known gaps and any SDK release that must ship with the server change. Ask which SDK versions your apps currently pin.
Dependency changes such as Superposition
Some releases add required dependencies. Hyperswitch v1.124.0 made Superposition a required configuration dependency, so a Superposition service must be running before a deployment upgrades to that version. The work covers deploying and configuring that service, checking its network path and secrets, and confirming the core app server can reach it in staging. The client receives a dependency change plan listing new services, configuration keys, owners and the order in which they go live. Ask whether any other systems in your estate share those components.
Database migration rehearsal and staging upgrade
Hyperswitch runs on PostgreSQL with a primary and replica, so schema migrations must be timed and tested against data that resembles production before go-live. The team runs the migration on a restored copy, records the sequence and any locking or replication effects, then performs the full staging upgrade with Control Center and SDK checks. The client receives a tested runbook and a rollback procedure that states the point after which rollback is no longer clean. Ask how your backup restores are tested and how recent they are.
Production change window
The production change follows the tested runbook inside a window agreed with your operations and payments teams. Before the window opens, the team confirms backups, freezes unrelated changes, checks the router and scheduler replicas and agrees go or no-go criteria. During the window, each step is logged against the runbook and the rollback trigger has already been agreed. The client receives a change record with timestamps, the steps executed, approvals and any deviations. Ask who holds authority to call a rollback during the window.
Post-upgrade verification and ongoing support
After go-live, verification checks payment authorization, routing decisions, refunds, Control Center access and SDK behavior against a baseline captured before the change. Findings are triaged by severity and tracked until closed. Ongoing support, upgrades and continuous testing are available as a retainer that covers the monthly releases that follow. The client receives a verification report and an updated runbook for the next upgrade. Confirm the hours, response terms and release coverage in the retainer before you sign.
What makes a Hyperswitch upgrade cost more or take longer
This table lists the main drivers of Hyperswitch upgrade effort and explains how each one changes the work. Read each row as a question to answer about your own deployment before you request a quote. The main takeaway is that environment count, customization depth and the number of releases skipped usually matter more than the upgrade command itself.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Connector count and connector customization | Each connector carries its own credentials, mappings and test cases, and custom connector code must be re-tested on every upgrade. | Enable only the processors you need, keep custom connector changes in isolated modules, and document each connector's test cases. |
| Number of environments | Sandbox, staging, production and disaster recovery each need the same upgrade run, so the work multiplies with each copy. | Deploy from one versioned configuration, and upgrade sandbox first so later environments follow the same steps. |
| Divergence from upstream code | Patches to the core app server must be re-applied or re-merged at each release, and conflicts grow the longer you wait to sync. | Keep changes in configuration or extension points where possible, and merge upstream each month so drift stays small. |
| Control Center and SDK customization | Dashboard and client SDK changes must match the compatibility matrix for each release, so custom UI can break on upgrade. | Check the release compatibility matrix before each upgrade and limit forks to the screens and SDK hooks you need. |
| Number of client applications calling the SDKs | Every web, mobile or React Native app that calls the SDKs needs regression testing and may need a coordinated release. | Pin SDK versions per app, share a release calendar with app teams, and test one reference integration per platform first. |
| Database size and migration complexity | Schema migrations run against PostgreSQL, and large payment tables lengthen the maintenance window and raise rollback risk. | Test migrations on a restored copy of production, time the run, and archive or partition old data before the upgrade. |
| Kubernetes setup and vault model | Custom Helm values, cluster versions and where the vault runs (self-hosted, external or SaaS) each add checks and can change PCI scope. | Keep Helm values in version control, and confirm with your vault provider which components change scope on each upgrade. |
| Releases skipped at once | Each skipped monthly release adds migrations and config changes, and some add required dependencies, such as Superposition from v1.124.0. | Upgrade in small steps where practical, and read each release note for required dependencies before planning the window. |
How a Hyperswitch upgrade moves from release notes to production
This sequence turns each monthly Hyperswitch release into a tested, approved and supported change in your environment. Each phase closes with a written output, so your team can see what changed, what was tested and what it owns after go-live.
Log each release and write an impact note
DeployOpen reviews each new Hyperswitch release on the GitHub releases page, including its compatibility matrix for Control Center and client versions, and compares it with your running versions. Required configuration changes, such as the Superposition service that v1.124.0 made a required dependency, are flagged first. The output is a written impact note covering your connectors, routing, dashboard users and SDK clients. Confirm in the written scope who receives the note and how it is issued.
Review compatibility and dependencies
The team checks the Router, Scheduler, Control Center, SDK versions, Helm chart values, PostgreSQL, Redis and any Superposition service against the target release. Custom connectors and forks are compared with upstream so conflicts surface before testing. The output is a version pin list that names every component, image and chart version to be deployed, with any open dependency blockers recorded. Ask your team to confirm which customizations and client SDK versions must be kept.
Rehearse the upgrade in staging
The pinned release is deployed to a staging environment built from the same Kubernetes configuration as production, using a copy of production-like data. Database migrations run first, and the team records timings, errors and rollback behavior for each migration. Payment flows, routing rules, refunds, webhooks and Control Center logins are tested against the processor sandboxes you use. The output is a tested migration log and a list of defects resolved before production. Confirm with DeployOpen how staging data is handled under your data policy.
Plan the production change and rollback
The team writes a production change plan from the staging results. It covers the maintenance window, the order of Router, Scheduler and dashboard rollouts, database backup and restore points, and the criteria for stopping or rolling back. Your change board, security owner and payments operations lead review the plan. The output is a signed-off change plan with named approvers and a rollback procedure that has been rehearsed in staging. Ask whether your change process requires additional approvals or notices.
Upgrade production and verify results
The approved plan is executed in production by DeployOpen with your on-call staff present. After each stage, the team runs the verification checks from staging, including test transactions through live-safe paths, routing confirmation, webhook delivery, reconciliation totals and error rates in logs and metrics. Any failed check triggers the rollback criteria in the plan. The output is a verification record showing each check, its result and the final deployed versions. Ask the team how verification results will be shared with your operations staff.
Hand over to support and update runbooks
After go-live, the team updates the deployment documentation, runbooks, pin list and monitoring thresholds to match the new release. Your operators are briefed on the changes, known issues and who to contact for incidents. Support scope, such as monitoring, monthly upgrades or on-call cover, is then defined in a separate written agreement. The output is an updated handover pack and a confirmed support scope. Ask in the written scope which support tier applies, what response expectations are stated and what is excluded.
Checking the Hyperswitch compatibility matrix before every upgrade
Before any Hyperswitch upgrade, open the GitHub releases page for the target version and read its compatibility matrix. Each minor release lists the Control Center and web client versions it supports. Hyperswitch ships roughly monthly minor releases, and the cadence is visible on the page: v1.126.0 (August 24, 2026), v1.127.0 (September 28, 2026) and v1.128.0 (October 16, 2026). The gap between v1.127.0 and v1.128.0 is shorter than a month, so a team that upgrades on a fixed calendar could skip a release it never evaluated. Treat each minor release as a separate decision, and record the version you are moving from and the version you are moving to.
Next, read the matrix against what you actually run. Compare your deployed Control Center version with the row for the target release, then inventory the web client SDK version used by each checkout page or embedded payment flow. Then list the Android, iOS, React Native and Flutter SDK versions in each app that calls the router. The matrix as described covers Control Center and web client versions, so confirm in the release notes, or with the Hyperswitch maintainers, which mobile and cross-platform SDK versions the target release requires. If you run a custom fork of Control Center or any SDK, compare the fork's base version with the matrix row and list every local patch that will need rebasing before the upgrade.
Superposition is the dependency most likely to block an upgrade. The Hyperswitch v1.124.0 release notes state that Superposition became a required configuration dependency and that a Superposition service must be running before you upgrade to that version. If your deployment is on a release earlier than v1.124.0, confirm this step before scheduling any move to v1.124.0 or later. Ask the platform team to confirm the Superposition version the release notes call for, how it is deployed in your Kubernetes environment, and where its configuration is stored. Then test that the router can reach the service in a non-production environment. Do not assume a dependency is absent because the matrix does not mention it.
For every target version, read the full release notes, not only the matrix. Look for new required services, new or renamed configuration keys, changed environment variables, database migrations, and changes to supported PostgreSQL or Redis versions. Record each finding in an upgrade checklist with an owner, a status and the environment where it was verified. Payments operations and security should sign off on the checklist before the change window opens. Repeat this review for every monthly release, because the matrix and dependency list change from one release to the next. If a partner runs upgrades for you, ask them to deliver this checklist as part of the written scope.
What usually goes wrong during Hyperswitch upgrades and how to prevent it
Most Hyperswitch upgrade problems come from treating a monthly release as a single container swap. The failures below cluster around dependencies, version alignment, data changes and proof of success, and each one has a check you can run before production traffic moves.
Skipping the Superposition dependency
Hyperswitch v1.124.0 made Superposition a required configuration dependency, and the release notes say a Superposition service must be running before you upgrade to that version or later. Teams that upgrade the router first often find the new version cannot start cleanly. Before any upgrade, confirm Superposition is deployed, reachable from the router, and included in your Helm values and rollback plan.
Control Center outside the compatibility matrix
Each Hyperswitch GitHub release publishes a compatibility matrix for Control Center and web client versions. Running a dashboard build that the matrix does not list can break payment, refund or dispute views in ways that look like processor problems. Pin the Control Center version to the matrix row for your server release, and test the dashboard against sandbox payments before the cutover.
SDKs lagging the server
The core app server is only one part of the client path. Web, Android, iOS, React Native and Flutter SDKs each call the server, and an SDK that predates a server change can fail on payment confirmation or redirect handling. Inventory every SDK version in your mobile and web apps, confirm which ones the new release supports, and schedule app releases so they do not wait for the server to catch up.
Migrations run without a tested rollback
Hyperswitch runs against PostgreSQL with a master and replica setup, and a schema migration that succeeds forward may not reverse cleanly once new payment rows exist. Rehearse the migration on a copy of production-shaped data, record how long it takes, and decide in advance whether rollback means a database restore or a version revert. Do not start the migration until a restore point is verified.
Router and scheduler upgraded out of step
Hyperswitch architecture has two app services, Router and Scheduler (Producer and Consumer), that share PostgreSQL and Redis state, including the scheduler queue. Running a new Router with an old Scheduler, or the reverse, can leave queued jobs unprocessed or misread payload formats. Upgrade both services to the same release in one planned change, and drain or check the Redis scheduler queue before and after.
Customizations that conflict with upstream
Custom connectors, routing logic or Control Center changes made on a fork often touch the same files that a monthly upstream release changes. The conflict may surface as a build failure or, worse, as a silent behavior change in routing or retries. Keep customizations in separate modules where possible, record each one, and run a merge and regression pass against the new release before scheduling production work.
Card vault or encryption change without a PCI change record
The card vault (locker) and the encryption service hold cardholder data and key material, so a version change there affects PCI DSS scope and evidence. An upgrade that changes vault or key handling without a documented change record can leave assessors without the evidence they need. Treat vault and encryption components as a separate change track, record the version, the approver and the test results, and tell your QSA or assessor before the change.
No monitoring baseline to prove success
Without metrics captured before the upgrade, there is no way to show that authorization rates, latency, error rates and queue depth returned to normal afterward. Capture a baseline for at least one representative period before the change, covering the processors and payment methods you run. Define the pass criteria in writing so the go or rollback decision rests on measured data, not on the absence of visible errors.
Which upgrade and support tasks teams keep in-house and which they hand to a partner
Split upgrade and support work by task, not by team size. A small payments team can still own the decisions only it can make, and a large one may still outsource the mechanical work. Three things usually stay in-house: the business decision to move to a given Hyperswitch release, approval of change windows against live payment traffic, and keeping payment operations and fraud teams informed before and after each change. Those decisions depend on settlement timing, processor commitments and fraud rules that an outside team does not hold. Under PCI DSS change control, the approver of record should also be a named person on your side.
The technical chain is where outside help most often pays off. Release monitoring means reading each monthly release and its compatibility matrix for Control Center and web client versions on the Hyperswitch releases page. Impact assessment maps that release onto your connectors, routing rules, vault model and any custom code. Staging rehearsal, migration scripting for database schema changes, Helm and Kubernetes chart changes, and verification evidence follow. Teams often outsource these when internal staff are thin on Rust, PostgreSQL or Kubernetes. Deciding whether a Rust change touches your customizations requires Rust literacy, and a migration that stops halfway requires someone who can inspect PostgreSQL primary and replica state directly.
Each part needs a different skill set, so test candidate partners against them. Payments domain knowledge decides whether a routing or connector change is safe for live authorizations. Kubernetes operations covers Helm values, rollouts, health probes and rollback for router and scheduler pods. PostgreSQL administration covers migration ordering, backups taken before schema changes and replica lag. PCI DSS change control means the change record, approval and test evidence your assessor will ask for when a change touches the card vault or other systems in scope. SDK front-end work applies when a release changes the web, Android, iOS, React Native or Flutter SDKs, or the Control Center. Ask which named person on the proposed team holds each skill.
Several trigger points usually move work to a partner. A release can add a new required dependency, as v1.124.0 did with Superposition, which had to be running before the upgrade. That introduces Kubernetes and configuration work the team may not have done before. A monthly cadence also leaves little slack for one engineer who also covers on-call. A failed migration in a staging rehearsal, a mismatch between Control Center and the SDK versions in use, or an assessor requesting change evidence the team cannot produce are further signals. Treat any of these as a prompt to scope outside help before the next release date, not as a reason to skip the upgrade.
Recurring costs after Hyperswitch go-live
This table lists the recurring cost lines that continue after a self-hosted Hyperswitch go-live, who pays for each one, and what drives it. Hyperswitch is Apache 2.0 licensed, so software licensing is not a recurring line for self-hosting, but confirm any hosted or vendor fees directly with the provider. The main takeaway is that most recurring spend sits in your cloud account and your staff time, and upgrade effort depends on how closely your deployment tracks upstream releases.
| Cost line | Who pays | Recurring pattern | What drives it |
|---|---|---|---|
| Kubernetes cluster infrastructure | Client cloud bill | Monthly, for every running environment | Node count and sizing for router and scheduler replicas, plus staging and production environments kept running |
| PostgreSQL primary and replica | Client cloud bill | Monthly, plus storage growth | Instance class for payment volume, replica count, storage growth and backup retention |
| Redis | Client cloud bill | Monthly | Cache and scheduler queue memory, and whether Redis is self-managed or a managed service |
| Superposition service | Client cloud bill | Monthly, plus patching effort | Required configuration dependency since v1.124.0, so it must run before upgrading and adds a service to maintain |
| Monitoring and logging | Client cloud bill or observability vendor | Monthly, scales with usage | Log volume, retention period and metrics volume. Confirm any vendor fees directly with the provider. |
| Upgrade effort per release | Partner retainer or internal team | Recurring, roughly monthly minor releases | Compatibility matrix checks for Control Center and SDKs, database migrations, Superposition changes and regression testing |
| Support retainer | Partner retainer | Recurring, per agreed term | Response scope, number of environments covered and whether upgrades are included in the retainer |
| PCI DSS evidence refresh (where the vault is in scope) | Internal team, assessor and vault provider if external | Recurring, per assessment cycle | Vault model: the in-house vault carries full PCI DSS responsibility, while an external vault shifts part of the scope |
| Internal staff time for on-call and change approval | Client internal team | Ongoing, per change and incident | Payments and security staff time for alerts, change reviews, connector changes and routing updates |
What your team must provide before an upgrade or support engagement starts
Before an upgrade or support engagement starts, your team has to put the working materials and named owners in place. The first item is read access to the current deployment manifests and Helm values for every Hyperswitch environment, including the router and scheduler services, the Control Center and the encryption service. Without the actual values in use, any compatibility check is a guess. Alongside that, supply the exact Control Center and client SDK versions in production, since the release compatibility matrix is only useful when it is read against what you run today. Also list every custom connector, patch or fork you carry. Each one is a place where a monthly upstream release can break your build, and it needs its own regression test before anything moves.
Next, confirm the operational access that makes a safe upgrade possible. You need database backup and restore access in staging, and you need to prove a restore works there before relying on it for production. Staging should mirror production in configuration: the same Helm chart version, the same vault model, the same PostgreSQL primary and replica topology and the same Redis setup, with only data and secrets differing. A staging environment that is merely similar will pass tests that production later fails. The outline also requires that Superposition is running where your release notes say it is now a required dependency. Ask the engagement lead to confirm its status in each environment before a version is selected, because a missing service can block a rollout entirely.
Four decisions belong to your organization and should be made in writing before work begins. The first is the target release. Upstream ships roughly monthly minor versions, so pick a version, the reason for choosing it, and a rule for when you will move again. The second is support hours, meaning when the partner is available for incident response and whether that cover applies to weekends and holidays. The third is the acceptable downtime window for payment traffic, which is usually narrower than for internal tools and should be set by the payments owner rather than by the platform team alone. The fourth is who approves production changes. That approval should name a person or role, not a committee, and should state what evidence they need to see.
Name two owners who have authority over their domains. A payments owner signs off on routing behavior, connector changes and any effect on authorization rates. A security owner signs off on any change that touches systems inside your PCI DSS scope, including the card vault, network paths, logging and key handling. Where a change affects evidence for a PCI DSS assessment, the security owner should review it before deployment and retain the record afterward. DeployOpen prepares that evidence but does not issue assessment results, and your assessor will expect to see who approved each change.
Finally, agree the change window rules and the on-call path. Write down the days and hours when production changes are allowed, the freeze periods around peak payment volume and the process for an emergency change outside the window. Define the on-call path with names, escalation order and response expectations for both your staff and the support provider, including who can stop a rollout and who can execute a rollback. Ask the provider to confirm, in the written scope, how rollback works for database migrations, since a schema change may not reverse as simply as a container image. Settling these items first lets the first upgrade be planned rather than improvised.
Questions buyers ask about Hyperswitch upgrades and support
What drives the cost of a Hyperswitch upgrade?
The cost depends mainly on how far your deployment has moved from upstream and how much of it you have customized. Main drivers:
- Version gap: the number of monthly releases between your current version and the target, including any required configuration changes.
- Customization: custom connectors, routing logic, and Control Center or SDK changes each need merging and retesting.
- Environment count: each Kubernetes environment, PostgreSQL database and Redis deployment needs its own rollout and verification.
- Dependencies: a required service such as Superposition may need to be deployed and configured first.
- Testing and evidence: payment flow regression, a tested rollback and change records for your approval process.
A fixed-scope quote lists these as line items. Ask for the assumed starting version, the environments covered and whether testing is included.
How long does a Hyperswitch upgrade take?
Duration is set by the release gap, the customizations, and the approval path your organization requires. Upstream ships roughly monthly minor releases, so a team that upgrades at every release usually has a small change set each time. A deployment several releases behind must review every intervening release note, compatibility matrix and migration. Other factors include whether a required dependency such as Superposition must be stood up first, how many environments follow the same sequence from staging to production, the length of your change windows and freeze periods, and whether a payment traffic test in non-production is required. Figures belong in the written scope, which should state the environments, the assumed starting version and the testing included. Ask the provider which steps depend on your team's availability.
Can our own team upgrade Hyperswitch without a partner?
Yes, if your team has the skills and capacity to run the work, and many do. Upstream publishes release notes and a compatibility matrix for Control Center and web client versions with each release, which gives you the inputs for a plan. The team needs Kubernetes and Helm experience, PostgreSQL migration knowledge, the ability to operate Rust-based services in your environment, and a way to test payment flows without touching live traffic. The harder questions are ownership and continuity: who reviews each release, who handles a failed migration outside business hours, and who understands your customizations. Many teams keep routine minor upgrades in-house and bring in a partner for a larger version jump, a customized fork or a compliance-sensitive change. Decide based on the ongoing monthly workload.
What must our team provide before an upgrade starts?
Your team provides access, knowledge and decisions. Typical inputs include read access to current deployment manifests, Helm values and configuration; database and Redis access for backups and migration checks; a staging environment close enough to production to test payment flows; connector credentials and sandbox accounts for each processor you run; change board dates and freeze windows; and named owners for approvals, on-call cover and sign-off. You should also document the current and target versions, the reasons for the target, and the list of customizations with their origin. Access must follow your own cloud and network controls. If the work touches PCI DSS scope, add current network diagrams and existing vault evidence. Ask the provider to confirm each input in the written scope so gaps surface before the schedule is set.
How does Superposition change Hyperswitch upgrade planning?
Superposition becomes a prerequisite step in your plan. According to the Hyperswitch v1.124.0 release notes, Superposition became a required configuration dependency, and deployments need a Superposition service running before they upgrade to that version. Your plan should therefore include standing up and configuring the service, confirming that the router can reach it, and bringing it under your backup, monitoring and access control processes before the Hyperswitch version changes. It also adds a second component to test, with its own configuration, versioning and failure modes. Start by checking whether your current deployment already runs it. If your upgrade crosses that release, sequence the dependency first and verify it in staging. Confirm with the provider how Superposition should be hosted in your environment.
What does a retainer cover compared with a one-off upgrade?
A one-off upgrade covers a defined change: a named version or set of releases, the environments listed in scope, and the testing and handover described in writing. Once that work is accepted, the engagement closes. A retainer covers ongoing work agreed in advance, such as monitoring upstream releases, assessing compatibility, planning and applying upgrades within agreed limits, handling support requests, and running continuous testing where it is included. Retainers suit deployments that follow monthly releases, because the work recurs and the plan stays current. A one-off job suits a single catch-up upgrade or a team that will take over routine upgrades after handover. Ask which release cadence is covered, what response terms apply, how work outside scope is requested and priced, and how change requests are handled. A quote follows from the written scope for either option.
How do we handle a custom fork during Hyperswitch upgrades?
Keep the fork as close to upstream as your features allow, and treat every divergence as a recurring cost. Each customized connector, routing change or Control Center and SDK edit must be merged with each new upstream release and then retested. Practical steps include keeping changes in clearly separated modules or extension points where the design allows, recording each divergence with its reason and owner, tracking release notes and compatibility matrices for each target version, and running each upgrade on a branch with automated regression checks for payment flows. Consider whether a feature can be built as configuration or placed outside the core. Merge effort grows with the number of divergences. The upgrade plan should list each fork item, its expected merge effort and who signs off on it. Ask the provider how they handle merges, testing and documentation of divergences.
What does DeployOpen hand over at the end of an upgrade?
The handover is defined in the written scope. A typical package includes the upgraded deployment in each agreed environment, updated manifests, Helm values and configuration records, and a record of the migrations applied. It should also contain the rollback procedure with evidence that it was tested, updated documentation of customizations and dependencies including Superposition, payment flow test results, a list of open issues, and runbooks your team can use. Ask whether source changes are delivered into your own repository, under which license, and who owns the documentation. Ask also how the upcoming upstream releases will be planned after handover. Ongoing support after handover is provided through a retainer or as separate fixed-scope work, which should be stated in the quote.
How DeployOpen scopes, delivers and supports Hyperswitch upgrades
DeployOpen plans and carries out Hyperswitch upgrades inside your own infrastructure, from reading the release notes through to a tested rollout. Each upgrade is treated as a controlled change with a written plan, tests and a rollback path. Engagements are fixed-scope, with scope, deliverables and timeline agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- The written scope names the target Hyperswitch version and every component it touches, including Router, Scheduler and Control Center.
- We check the compatibility matrix for Control Center and web client versions against your current and target releases.
- Scope records whether Superposition, a required dependency from v1.124.0, must be added or already runs in your environment.
How we build
- Upgrade work starts in a non-production environment that mirrors your Kubernetes deployment, Helm values and database layout.
- Database migrations are rehearsed on production-like PostgreSQL data, with rollback steps written before the change window.
- Regression testing covers payment flows, connector calls, routing rules, vault tokenization and Control Center logins before sign-off.
How we hand over
- Each release ships with an upgrade record listing versions changed, migrations run, configuration differences and test results.
- Runbooks cover the rollout order for Router, Scheduler and Control Center, plus the steps to roll back each one.
- Your team receives customized changes documented against upstream, so later monthly releases are easier to review.
How we support
- Support after go-live can run as a retainer covering monitoring of new monthly releases and their compatibility matrices.
- Retainer work can include planning, testing and applying each minor release in your environment, under the agreed scope.
- Before any retainer starts, confirm response expectations, change windows and who approves production upgrades in writing.
