Why a Synapse upgrade needs a planned path through the releases
A Synapse upgrade across several releases needs a planned path through those releases, and the rollback window depends on which database schema versions that path crosses. The target version tells you where the server will land, but the path decides what you can undo if an upgrade step goes wrong. The upstream upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so the sequence of steps is a design decision made before the first change.
Consider a self-hosted Synapse several releases behind, with staff and external users relying on it for daily messaging and room history stored in its database. Each release in between may include a migration that changes the schema, and Synapse will not start until those migrations complete. Before you choose a target, read every set of upgrade notes between your current version and that target, not only the notes for the final release. Those notes name the releases that change schemas, the platform floors that change, and the settings that must be corrected before the server will start.
The latest release listed on the Synapse GitHub releases page is v1.163.0, but the path should be planned against the release you intend to reach, confirmed on the day you plan. Synapse publishes a table of the earliest version each release range can roll back to. As an illustrative reading of that table, the published entry for v1.105.1 through v1.163.0 allows a safe rollback only as far as v1.100.0. A team that treats v1.163.0 as the only target may not realize that the same jump removes rollback options to earlier versions.
Before the first step, confirm that your PostgreSQL and Python versions meet the floors in the upgrade notes. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so a platform upgrade may need to happen before the Synapse path begins. Record your current version, the chosen target, every intermediate version on the path, and a verified backup taken before each step. The official Synapse upgrade notes are required reading for this work and should be treated as the baseline for the plan.
Breaking changes and platform floors to check in Synapse releases
This table lists the platform floors and breaking changes in recent Synapse releases, with the impact of each and the action to take before upgrading. Read each row against your current Python and PostgreSQL versions, your authentication setup and your profile settings to find the changes that apply to your server. The main takeaway is that several of these checks can block startup, so confirm each one in a test environment before the production upgrade.
| Change or floor | Impact | Action before upgrading |
|---|---|---|
| PostgreSQL 14 floor (from 1.143.0) | Synapse 1.143.0 and later require PostgreSQL 14 or newer. An older database blocks the upgrade. | Confirm the database server runs PostgreSQL 14 or newer. If it does not, plan the database upgrade as a separate change before moving to 1.143.0. |
| Python 3.10 floor (from 1.142.0) | Synapse 1.142.0 and later require Python 3.10 or newer on the hosts that run it. | Check the Python version on every host and container that runs Synapse or its workers, and upgrade the runtime before moving to 1.142.0. |
| MSC3861 auth delegation removed (1.157.0) | Synapse 1.157.0 removed support for the experimental MSC3861 auth delegation, so servers relying on it lose that login path. | Identify any server still using MSC3861 and migrate to the stable Matrix Authentication Service integration before upgrading to 1.157.0 or later. |
| Profile request startup check (1.163.0) | Synapse 1.163.0 refuses to start if limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests. | Review the configuration file for both settings and set require_auth_for_profile_requests before upgrading to 1.163.0. |
| Schema migrations before startup | Synapse will not start until database migrations complete, so an unfinished migration keeps the server down. | Let background updates from each upgrade finish, monitored through the Admin API, before starting the next upgrade step. |
| End-of-life Python and PostgreSQL versions | Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, which removes your current runtime from future releases. | Check the upstream end-of-life dates for your Python and PostgreSQL versions and schedule runtime upgrades before the Synapse release that drops them. |
How far a Synapse rollback can safely go
Before you start any Synapse upgrade, look up the earliest version your running release can safely roll back to, and write that number into the upgrade plan as your rollback boundary. Synapse publishes a table that lists, for each range of releases, the earliest version that range can be rolled back to. As an illustrative reading of that table, the example the upstream documentation gives is that Synapse v1.105.1 through v1.163.0 can be rolled back safely only as far as v1.100.0. An operator running any release in that range should therefore plan on v1.100.0 as the lowest safe target, and should treat any older version as outside the safe path.
The reason the table exists is database schema changes. Synapse stores its state in a database whose structure changes between releases, and each new version runs migrations before it will start. An older Synapse binary cannot reliably read a schema that a newer release has already changed, so reverting the software alone is not a complete rollback. The Synapse upgrade notes warn that rolling back can be difficult for this reason. Read the notes for every release between your current version and your target, because a schema change in an intermediate release can move the rollback floor even when your final target looks safe.
When a rollback would cross a schema change, the usual path is to restore the database and configuration from a backup taken before the upgrade. That restore discards anything written to the homeserver after the backup was taken, including messages, room state and account changes, so the cost of a rollback is data loss for that window. Decide in advance who approves a restore, how long the rollback window stays open, and how users will be told about any lost data. Take a consistent PostgreSQL backup immediately before each upgrade, and record the matching Synapse version, configuration files and media store, so a restore reproduces the same state.
Confirm the current table in the official Synapse upgrade documentation for your exact target release before you rely on any rollback floor. The table is maintained by the project and changes as new releases ship, so the example above is only an illustration of how to read it. Ask your implementation partner, or whoever runs your upgrades, to record the table lookup, the source version, the target version, the rollback floor and the restore owner in a written plan. Then test the restore on a separate environment before the production upgrade, so the rollback path is proven rather than assumed.
What to prepare before any Synapse upgrade
Each card produces a record that the upgrade plan depends on. Synapse rollback options narrow once database schema changes apply, so the backup, the configuration baseline, the dependency list and a rehearsal in a test environment must all exist before anyone runs an upgrade command.
Verified database backup
Take a database backup before every upgrade and prove that it restores. Synapse's upgrade notes warn that rolling back can be difficult because of schema changes between releases, so a tested backup is the practical fallback when the published rollback table no longer covers your starting version. Take it with Synapse stopped, or confirm that your database tooling produces a consistent snapshot while Synapse runs. Restore the backup into a scratch database and record the result, including the Synapse version it came from, the restore time and who signed off. Confirm the backup tooling, retention period and restore responsibilities with your database administrators before the change window is booked.
Homeserver configuration baseline
Record the current homeserver.yaml, with secrets redacted, in version control or an attached change record. Note server_name, the database block, listener settings, federation_domain_whitelist and any option that a newer release may change or refuse at startup. For example, Synapse v1.163.0 refuses to start if limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests, so that pair must be checked in the baseline before the upgrade. The output is a file that can be diffed against the new release's configuration and a list of each setting reviewed against that release's upgrade notes.
Dependent services and integrations
List every component that must keep working after Synapse changes: worker processes and their Redis connection, extra modules, bridges to platforms such as Slack or IRC, and SSO providers configured through oidc_providers, saml2_config or CAS. For each one, record its version, its configuration owner and the test that proves it works, such as a login through each identity provider or a message round trip through each bridge. If you use Matrix Authentication Service, record its version as well, because Synapse v1.157.0 removed the experimental MSC3861 delegation and requires the stable MAS integration. Components that fall behind a new Synapse release can block an upgrade partway through.
Test environment from production data
Build a test environment from a recent copy of production data, using the same database engine and major version, the same worker layout and the same identity setup. Run the planned upgrade there first, including every intermediate version your path requires, and wait for background updates from each step to finish, monitored through the Admin API, before moving on. Record the duration of each step, every error and any client or bridge that fails, then use those results to plan the production window. Apply the same access controls to the copy as to production, because it contains user messages and account data. Confirm supported PostgreSQL and Python versions for your target release before building it.
Reading every set of upgrade notes between your version and the target
When your Synapse release is several versions behind, read every upgrade note between your current version and the target, in order. The notes are the only place where breaking configuration changes, new minimum Python and PostgreSQL versions, and database schema changes are recorded for each release. Synapse documents that when upgrading from a very old release you should read all of these notes, but you should not install every intermediate version. Reading is inexpensive and gives you the full list of changes to plan around. Installing each release means running its migrations and waiting on its background work, which is where time and risk accumulate.
The recommended approach is to step through each release that makes an incompatible database schema change, rather than running every release in between. Each of these stops is a point you can roll back to. Synapse publishes a table of the earliest version each release range can safely roll back to. For illustrative purposes, if that table shows that v1.105.1 through v1.163.0 can roll back only as far as v1.100.0, then jumping from v1.100.0 directly to v1.163.0 leaves you no safe rollback point inside that range. Keep the schema stops on your plan so that a failed upgrade can return you to the last stop, not to the version you started from.
To find those stops, go through the notes for each release and mark any entry that mentions a database schema change, a background update, a removed or renamed setting, or a change to authentication. Record each marked release with the reason and its rollback floor. Confirm the rollback floor against the rollback table in the upgrade documentation for your exact target, because it changes as new releases ship. Some notes change the plan in a way that is easy to miss. Synapse v1.157.0 removed support for the experimental MSC3861 auth delegation and required migration to the stable Matrix Authentication Service integration. Synapse v1.163.0 refuses to start if limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests. Your administrators should check their configuration against those notes before scheduling any stop.
The path you choose sets how much operational work the upgrade involves. Synapse does not start until its database migrations complete, so each stop requires at least one restart. The documentation advises waiting for background updates from each upgrade to finish before starting the next one, and you can monitor their progress through the Admin API. More stops therefore mean more restarts, more background update waits and more test cycles, each covering the features your users depend on. Ask any implementation partner to list the stops they identified from the notes, the rollback floor for each, and the test cycle planned for each stop before accepting a fixed scope.
How to sequence a Synapse upgrade across schema versions
This sequence moves a Synapse homeserver through each incompatible database schema version in order, with a verified backup and a recorded rollback point at every stage. It ends in a production cutover decision backed by evidence from every step.
Freeze configuration changes before upgrading
The platform owner announces a freeze on homeserver.yaml, worker configuration, reverse proxy rules and Synapse package pins for the whole upgrade window. Anyone who needs a change files it for after cutover. The step is done when the change record names the frozen files, the owners who agreed to the freeze and the exact Synapse version running in production, so every later check compares like with like. Rollback point: none is needed yet because nothing has changed, but the recorded version is the target for any restore.
Take and test the production backup
The database owner takes a PostgreSQL backup of the Synapse database, copies the media store and saves the configuration directory. A restore is then run into a separate environment to confirm the data is readable. Synapse depends on its database schema, so a backup that has never been restored gives no reliable rollback. The step is done when the restore completes and a test Synapse instance starts against it. Rollback point: the verified backup, which is kept until cutover succeeds.
Stage the first schema-version target in test
The platform engineer reads every set of upgrade notes between the current and the first schema-changing target release, including breaking-change notes. Known examples to check include the removal of experimental MSC3861 delegation in v1.157.0 and the start-up refusal in v1.163.0 when limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests. The engineer then installs the target in the test environment built from the backup. The step is done when the server starts without configuration errors and reports the target version. Rollback point: rebuild the test environment from the backup, with production untouched.
Start Synapse and let migrations complete
The engineer starts the staged Synapse process and watches the logs until database migrations finish. Synapse does not start until migrations complete, so the process can look idle while schema changes run. The engineer also confirms that the main process and any workers have started and that the release supports the installed Python and PostgreSQL versions. The step is done when the logs show a completed start and the process accepts requests. Rollback point: the pre-upgrade binary plus the backup, because the upgrade notes warn that rolling back after schema changes can be difficult.
Wait for background updates to finish
The engineer polls the background update status through the Synapse Admin API and waits until no updates remain pending. Starting the next upgrade while updates are still running compounds unfinished work and makes any failure harder to isolate. The engineer saves the status output with a timestamp as evidence. The step is done when the Admin API reports no pending background updates and the logs show no update errors. Rollback point: the same backup and binary, with no further upgrade started while updates are still running.
Run functional checks on the staged version
The test owner runs a scripted set of checks: log in with a test account, send a message to a test room, run a federation test with a partner server you control or a known test partner, and sign in through each configured SSO provider. The federation test confirms the listener on port 8448 or delegated routing is reachable. The owner records pass or fail for each check. The step is done when all four checks pass on the staged version. Rollback point: restore the test environment from the backup and investigate before any further schema version is staged.
Record a rollback point and repeat
Before the next schema version, the engineer records the running release, the backup identifier, the background update evidence and the functional check results in the change record. The rollback point is the earliest release the documented rollback table allows for that range. For example, the table lists v1.105.1 through v1.163.0 as safe to roll back only as far as v1.100.0, so any release in that range has a floor at v1.100.0. The engineer then repeats the staging, start, background update and check steps for each next schema version until the target is reached. The step is done when each stage has a complete record.
Decide production cutover and handle failures
Cutover proceeds only when every stage has recorded passes for background updates and functional checks, the backup restores cleanly, the configuration freeze still holds and each rollback point is written down. The production window is scheduled with the owners of SSO, federation and the database. If any check fails, the sequence stops, production stays on its current version, the test environment is restored and the cause is found in the logs and upgrade notes. The team does not skip a schema version to recover time. The step is done when the platform owner signs the cutover record.
Waiting for Synapse background updates before the next step
Synapse will not start until its database migrations complete, and the upgrade docs advise waiting for the background updates from each upgrade to finish before you start the next one. Background updates are long-running database changes that continue after the server is up, so a server that starts is not the same as an upgrade that is finished. Write this into your runbook as an entry condition for the next version: no outstanding background updates for the current one. The rule matters most when you step through several incompatible schema versions, because each step assumes the previous step is fully applied.
Monitor progress through the Synapse Admin API, which reports the status of background updates. Confirm the exact endpoint and response fields in the documentation for your current and target versions, since the API can change between releases. For each upgrade, record the starting and target versions, the time the server first started, the names and states of pending updates at fixed intervals, any errors in the logs, and the time the updates reported complete. Keep this record with the change ticket so that anyone deciding on a rollback can see which schema changes were already applied.
Moving on early creates the risk of a stuck or partially applied migration. An unfinished background update can leave tables or indexes in an intermediate state, and the next release may assume the earlier work is complete. If the next upgrade starts in that condition, you may end up with a server that will not run the new code, a rollback path that the release table no longer covers, and a restore from backup as the only way back. Before each step, confirm with your database administrator which backup or restore point exists, and decide in advance who can authorize continuing if an update stalls.
The time a background update takes depends on the size of your database, the volume of events and rooms it holds, and the load on PostgreSQL while the update runs. The docs do not give a figure you can plan from, and a number from another deployment will mislead you. Measure it in a test environment restored from a recent production backup, using the same version path, hardware class and database settings. Run the upgrade one step at a time, record how long each background update takes, and size the production window from your measurements with margin for surprises. When a partner or vendor quotes this work, ask for the measurement method behind any estimate.
What makes a Synapse upgrade take longer
This table lists the factors that stretch a Synapse upgrade, the direction each one pushes the effort, and the question to ask a partner or your own team before agreeing a plan. Read it as a checklist: the more rows that apply to your deployment, the more planning, testing and waiting you should expect. Ask for each driver to be assessed against your current version and topology before a quote is written.
| Driver | Effect on effort | Question to ask in a quote |
|---|---|---|
| Releases crossed and incompatible schema versions | More releases between your current and target versions means more upgrade notes to read and more schema steps. Stepping through each incompatible schema version preserves rollback options, so effort rises with each stop. | Which upgrade notes apply between our current version and the target, and which incompatible schema versions must we step through? |
| Database size and load during background updates | Large tables and busy databases make background updates run longer. Synapse will not start until migrations finish, and the next upgrade should wait for background updates to complete. | How long do background updates typically run on a database of our size, and how will you monitor them through the Admin API? |
| Workers and Redis dependencies | Each worker and the Redis instance that relays replication must restart in a safe order. More workers and more Redis dependencies add sequencing steps and more places for version mismatches. | Which processes must restart first, how is Redis handled during the window, and is the restart order written into the runbook? |
| Custom modules and configuration | Custom modules and hand-edited configuration need compatibility checks against each target release. Modules written against internal interfaces are the most likely to need rework. | Which custom modules and config options will be checked against the target version, and who fixes incompatibilities found in testing? |
| SSO and MAS dependencies | Moving off the experimental MSC3861 delegation to stable MAS integration, or changing identity providers, adds a separate migration track. Login testing must cover every provider in use. | Do we need to migrate off MSC3861 for the target release, and which identity providers and MAS settings need retesting? |
| Bridges and integrations | Bridges and bots each have their own version compatibility with Synapse. Every bridge needs a version check and, where needed, an upgrade or replacement before or after the homeserver moves. | Which bridges and integrations are in use, what version does each support, and who confirms compatibility before the homeserver changes? |
| Availability target for the service | A stricter availability target leaves less room for downtime, so more rehearsal, staged rollout and a tested rollback path are needed. Rollback is limited, so the window must be planned around the safe rollback floor. | What availability target applies to Matrix, what maintenance window is agreed, and what is the rollback plan if a migration fails? |
Testing an upgrade and deciding whether to roll back
Test the upgrade against the paths your users and integrations actually take, and agree that list with your user and integration owners before the change window opens. Start with login. Test each identity path the homeserver accepts: password logins if they are enabled, and each single sign-on route, whether that is an oidc_providers entry, a saml2_config entry, CAS, or Matrix Authentication Service if you have moved to it. Then test room creation, sending and receiving messages between two accounts on different clients, and media upload and download, since media handling is a common source of surprises after a schema change. Record which accounts, rooms and file sizes you used so the same test can be repeated at the next upgrade.
If federation is enabled, test with at least one remote server that you do not control, checking traffic in both directions: a message from your users reaching a remote room, and a message from the remote server reaching your users. Confirm that the federation listener on port 8448, or the delegation served on port 443, still resolves as before, and that federation_domain_whitelist still lists exactly the domains you intended. Bridges and clients need their own checks. Confirm that each bridge can still log in, relay a message in each direction, and that your usual clients reconnect without a fresh sign-in. If you run workers, confirm that the main process and every worker reconnect to Redis after restart and that client, federation and event traffic all flows through the generic worker. Ask each owner to write their pass criteria before testing starts.
The go or no-go decision should rest on three checks completed before the change window: the release you are starting from, the rollback table in the Synapse upgrade notes, and the configuration the target release expects. Find your current release in the table. The published example is that Synapse v1.105.1 through v1.163.0 can roll back safely only as far as v1.100.0, so a target inside that range that needs to return past v1.100.0 falls outside the table. Also confirm that your configuration is valid for the target. Synapse v1.163.0 refuses to start if limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests, and a startup failure in a change window is a poor time to find that out. Treat any failed check as a no-go and record the decision and its evidence in the change ticket.
Decide rollback in two separate cases. If the failure occurs within the range the table allows, returning to the earlier release may be enough, provided the database schema has not moved past what that release expects. If the target lies outside the table, or the failure happened during database migration or while background updates were still running, plan to restore the database backup and the media store together. The upgrade notes warn that rollback can be difficult because of database schema changes between releases, so a version-only rollback cannot be relied on in those cases. Name in advance who may call a rollback. This is usually the operator who runs the homeserver, with sign-off from the business owner of the affected communication service. Confirm that approval chain with your own governance team, and make sure the restore procedure has been rehearsed before the upgrade starts.
Synapse upgrade cost, time and what it needs from your team
What drives the cost of a Synapse upgrade project?
Cost follows the distance between your current Synapse version and your target, the number of incompatible schema versions you must pass through, and how much of your environment the upgrade touches. Main drivers: whether PostgreSQL must be upgraded to meet the version 14 or newer requirement that Synapse 1.143.0 and later set; Python changes, since 1.142.0 and later require Python 3.10 or newer; worker processes and Redis; federation and single sign-on settings; and any experimental authentication that must move to Matrix Authentication Service. Most of the cost is specialist and staff time. The upgrade itself is largely one-time, while later upgrades recur on your release cycle. Ask for a written quote that lists each version step, each dependency change, the test plan and the rollback plan as separate line items.
How long does a Synapse upgrade take from start to finish?
No single duration applies, because the time depends on the version gap, database size, how long background updates take, the number of environments, and how many change windows you can use. Synapse will not start until database migrations complete, and the upgrade notes advise waiting for background updates from each upgrade to finish, monitored through the Admin API, before starting the next one. An old installation that must step through several incompatible schema versions needs more rounds than a recent one. Testing, approvals and your change calendar often set the pace more than the software does. Ask for a plan that names each version step, its checkpoints and what each checkpoint depends on, so you can compare proposals on the same basis.
What does a Synapse upgrade need from our staff?
The work needs named people and access before it starts. Database access: someone who can take backups, confirm the PostgreSQL version and connection settings, and grant the rights needed to run migrations. Configuration owners: people who know the Synapse configuration file, server_name, federation settings, authentication settings, and any workers or Redis. Test users: accounts in rooms, encrypted chats, federated contacts and any bridges, so behavior can be checked after each step. A change window: long enough for migrations and post-upgrade checks, with unrelated changes frozen. A rollback decision owner: someone with authority to approve or reject a restore during the window. Confirm each role in writing, including who answers during the window.
Can our own team upgrade Synapse without outside help?
Yes, if your team has Linux operations skills, PostgreSQL administration experience, and time to read every relevant upgrade note in sequence. The difficult parts are the schema steps, background update monitoring, and changes that break existing configurations. Examples include the removal of the experimental MSC3861 authentication delegation in v1.157.0, which requires moving to the stable Matrix Authentication Service integration, and the v1.163.0 startup check that refuses to start when limit_profile_requests_to_users_who_share_rooms is set without require_auth_for_profile_requests. Teams that upgrade on a regular cycle often build this into routine operations. Teams crossing many versions after a long gap should weigh planning and testing capacity most carefully before deciding.
What does a Synapse rollback cost when the backup must be restored?
A rollback cost is the time to restore the database and files, the messages and activity lost since the backup, and the investigation and retesting that follow. The Synapse upgrade notes provide a table of the earliest version each release range can roll back to. For example, v1.105.1 through v1.163.0 can be rolled back safely only as far as v1.100.0. The upgrade notes also warn that rolling back can be difficult because of schema changes between releases, so a restore from backup is often the route. Cost components include restore labor, extended downtime, user questions about missing messages, and specialist time. Confirm that a backup is taken immediately before each migration, that restores have been tested on a copy, and that the restore time has been measured. Ask for restore work as a separate line item in the quote.
What should we ask for in a written Synapse upgrade scope?
A written scope should name the starting and target versions, every intermediate stop version, each database and runtime change including PostgreSQL and Python, the configuration settings affected, the environments covered, and the test cases with named test users. Ask who runs each step, what you must provide, the change window requirements, the rollback method and its tested limits, the acceptance criteria, and the action taken if a background update runs long. Confirm what is excluded, such as bridges, Element Call, the Matrix Authentication Service migration or client updates. Ask which fees are fixed and which depend on findings during the work, and what a rollback costs. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Why does an old Synapse installation need several upgrade steps?
The Synapse upgrade notes say to read all notes between your version and the target, then install only the stop versions they identify. Stepping through each incompatible database schema version keeps a rollback option open, because each earlier stop is a restore point the rollback table recognizes. Jumping directly to the newest release removes those intermediate restore points and can leave you with a narrower rollback range. Each stop also runs migrations and background updates, so plan a checkpoint after each one. A usable plan lists the stop versions, the notes read for each stop, the backup taken before each stop, and the test results recorded at each stop.
How do we check that background updates have finished before the next Synapse upgrade?
Use the Admin API to check background update status, and confirm that no background update is still running before you start the next upgrade. Also confirm the server is healthy: migrations have completed, logs show no errors, client and federation traffic work, and test users can send and receive messages. Record the version and database state before each step so any restore point is clear. Assign an owner for monitoring and agree in advance what result should stop the work. Confirm the exact Admin API endpoints for your Synapse version in the upgrade notes and the Synapse documentation before writing scripts that depend on them.
How DeployOpen scopes, delivers and supports a Synapse upgrade
DeployOpen plans Synapse upgrades as a written, fixed-scope engagement inside infrastructure you control. The work starts with the upgrade notes for every version between your current release and the target, and it sets the rollback boundary before anything changes.
How we scope
- The written scope lists every Synapse version between your current release and the target, with the upgrade notes read for each one.
- We confirm your rollback boundary against the published table of earliest safe rollback versions before any change is approved.
- The scope names your PostgreSQL and Python versions and flags any that fall below the minimums Synapse now requires.
- Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work begins.
How we build
- We rehearse the upgrade on a copy of your database and configuration, stepping through each incompatible schema version in order.
- We monitor background database updates through the Admin API and hold the next upgrade until each one has finished.
- We check configuration against breaking changes such as the MSC3861 removal and the profile request setting enforced in v1.163.0.
- We document each step, the rollback point and the verification results so your team can repeat the process.
How we hand over
- You receive the runbook for the upgrade path, including the version sequence, checkpoints and the rollback point for each step.
- The handover includes configuration changes, a record of background update status and the checks used to confirm health.
- We walk your platform team through the runbook and the decision points where an upgrade should pause or stop.
- Your team keeps the database backup and restore procedure used during the rehearsal for use in production.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the first upgrade is complete.
- A retainer can cover monitoring of new Synapse releases and review of upgrade notes before each planned change.
- Support can include reviewing platform floors for Python and PostgreSQL as upstream end-of-life dates approach.
- Ask us to confirm response arrangements and what a retainer includes before signing, since these are set in the written agreement.
