Medplum upgrades and support for self-hosted teams: when to bring in a partner
Keeping self-hosted Medplum current is a recurring, sequenced operational job that runs for the life of the deployment. Most teams keep routine patching in-house, since weekly patch releases fit a normal change process, and bring in a partner for the parts that are harder to staff: the upgrade path across versions, the post-deploy migration window, and ongoing support coverage when capacity or specialist skills are thin. Four triggers usually prompt that decision: approaching end of support, a critical security advisory, a skipped minor version, or an upcoming compliance review. Whether a partner is the right call comes down to one question: who owns the platform on call?
Each trigger runs on its own clock. Medplum ships a major version once a year in Q4, and each major gets one year of Active support and one year of Maintenance. The Enterprise extension adds 12 more months of security patches, for 36 months in total, so a team on an older major may find its window already closed. Security timing follows severity: Medplum's versioning policy targets patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). A team that cannot meet those windows internally has a gap to close, through staffing or a contract. A less visible problem is the skipped minor version. Self-hosted upgrades must pass through each minor version in sequence, and jumping ahead causes startup failures, so an inherited deployment several minors behind needs a written plan before anyone runs an installer. A compliance review then asks for evidence of patch timing and version history, which is easier to produce when the change record is kept current.
The short answer depends on who owns the platform on call. If an engineer on your team can be paged at night when a post-deploy migration stalls, and that person can read Node.js and TypeScript server logs and inspect PostgreSQL and Redis state, routine upgrades can stay in-house with a documented runbook. If that coverage rests on one person who also holds other platform duties, or on nobody at all, the upgrade path and support window become a continuity risk. Confirm four things before deciding: your current version and how many minor releases sit between it and the target, whether a staging copy of production data exists, how long your last migration took against a representative dataset, and who signs off on the cutover.
Illustrative example: a team two minor versions behind finds that the upgrade needs an intermediate step it has never rehearsed, and the data migration runs longer than the maintenance window it booked. Neither problem is exotic, but both land on the same on-call engineer during the change. If you bring in a partner, ask for the scope in writing: which triggers are covered, which versions and environments are in scope, how migration windows are planned and rehearsed, and what response expectations apply. Treat those as commitments in the scope document rather than general assurances, and check the plan against Medplum's own upgrading guide before signing.
What Medplum upgrades and support includes
Medplum ships a major version each year, minor versions two to three times a year and patches weekly, and self-hosted installs must move through each minor version in order. The work below connects planning, rehearsed upgrades, production cutover, patching and ongoing support, with each card ending in a document or record the client keeps.
Assessment, planning and runbooks
Start by recording the current Medplum version, the PostgreSQL and Redis versions, the deployment method (CDK, Kubernetes, Docker or source) and every custom Bot and integration. Map the minor-version sequence from the current release to the target, since each minor version must be applied in order. The deliverable is a written upgrade plan with a runbook for each step, including rollback points and the checks to run before and after each version.
Sequential minor upgrades in non-production
Each minor version is applied and tested in order in a non-production environment, ideally with a data volume close to production. Skipping versions causes startup failures, such as a jump from v3.1.2 straight to v4.3.4, so the path is never shortened. Testing covers Medplum Auth logins, FHIR API calls, Bots and HL7 flows. The deliverable is a test record for each version step, with defects logged against the version that introduced them.
Production cutover and migration monitoring
Production work follows the rehearsed runbook inside an agreed change window. Post-deploy data migrations can run for hours or days on large datasets, so the window must allow for the duration measured in the non-production run. Monitoring tracks migration progress, server logs, PostgreSQL load and Redis behavior until the migration completes. The deliverable is a cutover record with timings, migration logs and a documented rollback decision point.
Security patch application
Medplum targets security patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). Each patch is checked against the version you run and tested in your environment before it reaches production. Confirm that your change process can meet those targets, since an urgent patch may need approval before the next standard window opens. The deliverable is a patch log with release dates, CVSS scores and verification results.
Ongoing support under a retainer
A retainer covers scheduled minor and patch work, monitoring of the Medplum release stream and response to incidents within agreed terms. Major versions ship annually in Q4, and each has one year of Active support and one year of Maintenance, with the Enterprise extension giving security patches for 36 months in total. Ask which of these periods the retainer covers and who owns the decision to move to a new major version. The deliverable is a periodic service report and an updated version register.
Client inputs and responsibilities
Upgrades stall without the client's inputs, so agree them before the plan is signed. Required items are access to non-production and production environments, change windows approved in advance, named owners for technical and clinical sign-off, and backup access that allows a PostgreSQL restore before any migration runs. Medplum describes compliance as a shared responsibility, so the client also keeps the change approval records. The deliverable is a responsibility matrix listing each input and its owner.
How Medplum's annual, minor and weekly releases set the upgrade calendar
Medplum's release rhythm determines how often your team must plan work on a self-hosted deployment. Major versions ship once a year, in Q4. Minor versions ship two to three times a year, and patch versions ship weekly. The annual and minor releases are the planned upgrade events, with changes to the server, database schema and configuration that need a test cycle and a change window. The weekly patches are the stream that arrives between them. Decide early whether your team will take every weekly patch, apply them on a fixed monthly window, or apply only security-relevant ones, and write that decision into your operations runbook so it is not renegotiated after each release.
Each major version receives one year of Active support and one year of Maintenance. Medplum also offers an Enterprise extension of 12 more months of security patches, which brings a major version to 36 months in total. Confirm with Medplum which of these windows, and which types of fixes, apply to your edition, since the extension is described as part of the Enterprise offering. Then map the windows onto your own calendar. A major version released in Q4 will move out of Active support about a year later, so a production environment that stays on one major version for several years will spend part of that time with security patches only, or with no vendor patches at all once the window closes.
Medplum's versioning policy sets patch targets of 7 days for critical vulnerabilities (CVSS 9.0 or higher) and 14 days for high vulnerabilities (CVSS 7.0 to 8.9). These are the vendor's policy targets. They describe when Medplum intends to publish a fix, and they do not guarantee that the fix is running in your environment. Your own exposure window also includes the time to test the patch against your data, schedule a change, and complete any post-deploy migration. Set internal targets for your organization, and make them at least as tight as the vendor's, so the gap between a published fix and a production deployment is owned by a named person. Ask Medplum how it notifies self-hosted customers of critical fixes and whether that notice comes with release notes that describe required steps.
The release line moves quickly. The latest version at research time was 5.2.5, published on October 15, 2026, after 5.2.4 on October 14 and 5.2.3 on October 8. A deployment that was current in early October could have been several patches behind within days. Treat that as an example of the pace, not as a version to plan against. Before you schedule any upgrade, check the Medplum releases page for the current version, record the version running in each environment in your inventory, and compare it against the current release. Then identify which releases between your version and the target contain migrations, and estimate the test time for each one with your own data volume before you commit to a date.
What makes a Medplum upgrade take longer than planned
This table lists the factors that most often stretch a self-hosted Medplum upgrade beyond the planned window, with why each one changes effort and what to do about it. Read it as a checklist: for each driver, measure your own value in staging before you commit to a change window. The main takeaway is that the version gap and the size of the data migration are usually the largest unknowns, so measure them first.
| Driver | Why it changes effort | How to reduce it |
|---|---|---|
| Minor versions between current and target | Medplum requires each minor version to be applied in sequence, and skipping versions causes startup failures, so every intermediate step adds a deploy, a check and a rollback point. | Map the full upgrade path from the Medplum upgrading guide before scheduling. Batch planning across fewer, larger windows only where the guide allows it, and confirm each step in staging first. |
| PostgreSQL dataset size and post-deploy migration runtime | Post-deploy data migrations can run for hours or days on large datasets, and runtime grows with the number of stored resources and history. | Measure migration runtime on a copy of production data in staging. Record table sizes and resource counts, and plan the window from that measurement rather than from an estimate. |
| Number of environments upgraded in sequence | Each environment, such as development, test, staging and production, must move through the same version path, so a delay in one blocks the next. | Keep environments on the same version path and promote the identical artifact and configuration through each one. Document the order and the sign-off required between them. |
| Customizations and Bots that depend on changed APIs | Custom Bots, extensions and integrations written against FHIR, GraphQL or SDK behavior may need changes when the server or SDK changes, and each change needs its own testing. | Inventory every Bot and custom integration with its Medplum SDK version. Run automated tests against the target version in staging and review each changelog entry that touches APIs you use. |
| Identity provider and SMART-on-FHIR configuration | Medplum Auth, external identity providers, client credentials and SMART-on-FHIR app launch settings can change between versions, and a misconfiguration can lock out clinicians or integrations. | Export and version-control your auth configuration. Test login, MFA, SMART launch and client credential flows for each role in staging before the production window. |
| Deployment method | Effort depends on whether you use AWS CDK and CloudFormation, Kubernetes, Docker, Ubuntu APT, or a Terraform-based GCP or Azure path marked Beta, and each method has its own update steps and drift risks. | Confirm the update procedure for your method in the self-hosting docs. Treat Terraform-based GCP or Azure deployments as Beta in your plan and confirm current status with Medplum before relying on them. |
| Change-window constraints | Clinical systems often limit when changes are allowed, and a migration that overruns a window forces a rollback or an extended outage decision. | Agree the window length, the rollback point and the communication plan with clinical stakeholders before the upgrade. Use the staging measurement to decide whether the window is realistic. |
| Compliance evidence needs | Change records, test results, approvals, backup confirmation and access reviews must be captured for each upgrade, and gaps in that evidence can extend the work after the technical change is complete. | Define the evidence list per upgrade in advance, including test outputs, approvals and backup restore checks. Store it with the change record so it does not need to be rebuilt after the fact. |
How a Medplum upgrade moves from assessment to handover
Every Medplum upgrade follows the same sequence, because Medplum's upgrade guide requires each minor version to be applied in order. Durations come from measured rehearsal runs on data copies, and each phase ends with a named output that the next phase depends on, so the client sees what is ready before any production change is made.
Inventory versions and map every minor step
DeployOpen records the Medplum version currently running, the target release, and every minor version between them. It also documents the current self-hosting path, PostgreSQL and Redis configuration, and any custom Bots, SDK usage or integrations that the upgrade could affect. The output is a gap map listing, for each minor version, the changes to configuration, data migrations and client-facing behavior, with a named owner for each item. The step is done when the client signs off the gap map and no minor version in the chain is unaccounted for. Confirm with your own platform team which deployment method the production environment uses, since that determines the rehearsal steps.
Clone production data and rehearse the full sequence
DeployOpen builds a staging environment from a copy of production data, matching the self-hosting path, database engine and cache configuration of production. The team then applies every minor version in sequence, from the current release to the target, and records each startup, migration log and error. A rehearsal that skips a version does not test the upgrade path the guide describes. The output is a sequential run log for each minor version and a list of issues with owners. The step is done when the full chain completes on the cloned data without manual database edits.
Measure migration timing on representative data
Post-deploy data migrations can run for hours or days on large datasets, so timing is taken from measured rehearsal runs and never assumed from a template. DeployOpen records the duration of each migration on a copy sized like production and notes which migrations scale with row count or record history. The output is a timing table per minor version, showing observed run times alongside the data volumes they were measured on. Ask the vendor and your team which migrations are expected to be long before the rehearsal starts. The step is done when the timing table covers every minor version in the chain.
Write the production change plan and rollback criteria
The change plan sets out the backup method, the order of minor versions, the maintenance window and the rehearsal timings the window is based on. Rollback criteria are written in advance, such as a failed startup, a failed migration, or an error rate above a threshold the client agrees to. The plan also names who is told, when, and through which channel, including clinical and integration owners who depend on the API. The output is an approved change record with a restore procedure that has been tested. The step is done when the client approves the plan in writing and the backup has been restored once in staging.
Cut over and monitor after deployment
The team takes the backup, applies the approved sequence in production, and runs post-deploy migrations to completion before declaring the cutover finished. Monitoring covers server startup, PostgreSQL and Redis health, API error rates, authentication flows through Medplum Auth, and integration traffic such as HL7 messages and Bots. DeployOpen watches the agreed signals for the monitoring period set in the change plan and invokes rollback only when a criterion written in advance is met. The output is a post-deploy report comparing observed behavior with the rehearsal record. The step is done when the monitoring period closes with no open rollback criterion.
Hand over the runbook and support model
DeployOpen writes a runbook for this deployment covering the upgrade procedure, rollback, backup and restore, monitoring checks and the escalation path. It records the versions, configuration and any deviations from the vendor's default self-hosting setup. The client's operators are walked through the runbook and perform a supervised dry run of at least one step. Ongoing patching under Medplum's security patch targets can be covered by a support retainer, and the handover states what that retainer includes and what stays with the client's team. The step is done when the client's team signs the handover record.
Why post-deploy migrations decide the length of your maintenance window
The most important planning fact for a self-hosted Medplum upgrade is that the upgrade itself is rarely the slow part. Medplum's upgrading guide warns that post-deploy data migrations can run for hours or days on large datasets, and that startup failures follow if a minor version is skipped. Your maintenance window is therefore set by how long the migration takes on your data, not by how long the new containers or images take to start. Until you have measured that number on a realistic copy of your database, any window you commit to is a guess.
Measure migration time in staging before you schedule production. Restore a recent production backup of your PostgreSQL database into a staging environment that matches production in size, instance class, and Redis configuration. Run each minor version step in sequence, as the guide requires, and record how long each post-deploy migration takes, how many resources are written, and whether any step produces errors or long-running locks. A staging copy with a fraction of production's resource count will understate the time badly. Ask whether the rehearsal used a dataset close to production volume and how that volume was verified, because the answer determines whether the timing record is usable.
Decide whether the service can run degraded during migration. Some migrations may allow the API to serve reads while writes are paused. Others may block startup entirely. Confirm with Medplum's release notes for each minor version in your path which behavior applies, and then decide what your clinical and integration consumers can tolerate. Map the decision to concrete components: FHIR API clients, Bots that write resources, HL7 feeds, SMART-on-FHIR apps, and the web app. For each, record whether it can queue, fail safely, or must be disabled at the edge. This decision sets whether you plan a read-only mode, a full maintenance page, or a traffic freeze at the load balancer.
Plan read-only or maintenance modes before the change window opens. Write down who switches each mode on and off, which runbook step does it, and how the team confirms that no writes are arriving. Pause scheduled Bots and inbound integrations first, then stop external writers, then start the migration. Keep a short list of what must be verified after restore, including FHIR API responses for representative reads and searches, Bot execution against a test resource, login through each identity provider in use, multi-factor prompts, and token issuance for client credentials. Confirm that audit log entries are continuous across the window, with no gap in timestamps or missing actor records. A gap in audit history is a compliance finding, so treat it as a go or no-go criterion.
What to ask a partner for. Before approving a window, request three artifacts: a rehearsal log showing each minor version applied in order against a production-sized copy, with start and end times for every migration step; a timing record that states the measured duration, the dataset size used, and the variance observed across runs; and a rollback decision point, defined as the last moment at which the team can revert without losing data, with the criteria that trigger the decision. Ask who makes that call and how long it may take. These three documents, not the vendor's general guidance, should set your maintenance window.
What goes wrong in Medplum upgrades and how to prevent it
Medplum upgrades tend to fail in the same places: version order, migration runtime, rollback, customizations, identity settings and ownership of new releases. Each card pairs one failure mode with a prevention step you can build into the upgrade plan before the maintenance window is booked.
Skipping a minor version
Self-hosted Medplum must move through each minor version in sequence. Jumping ahead can leave the server failing at startup, as in the documented example of going from v3.1.2 directly to v4.3.4. Before any change, record the installed version, list every minor release between it and the target, and follow that order using the upgrading guide. Put the sequence in the change record so the team executes a reviewed plan during the window instead of reconstructing one under pressure.
Migration time and rehearsal underestimated
Some post-deploy data migrations run for hours or days on large datasets, and they start only after the new version is live. Teams that size the window from a small test database usually find out too late. Restore a recent production snapshot into staging with matching PostgreSQL and Redis sizing, run each migration in sequence, and record elapsed time per step. Use those timings to set the maintenance window, decide whether a staged cutover is needed, and ask the vendor which migrations are long-running for the target version.
Backups that cannot restore the pre-upgrade state
A backup helps with rollback only if restoring it returns the platform to its state before the upgrade. Confirm that the backup covers the PostgreSQL database and any other stateful storage the deployment uses, and that it is taken immediately before the change starts. Restore it into a separate environment and run the same smoke tests used after the upgrade. Ask the vendor whether the target version's post-deploy migrations can be reversed, and write the rollback decision point into the runbook before the window opens.
Bots and customizations that break on changed behavior
Bots, custom search parameters, profiles and changes to the web app depend on Medplum behaving as it did before. A release can change defaults, API responses or internal interfaces they call. Inventory every Bot, subscription and custom component with its owner and the Medplum version it was last tested against. After upgrading the rehearsal copy, run each Bot's tests and compare responses for key resources. Keep all customizations in version control so any regression can be traced to a specific change.
Identity provider and client credential drift
Authentication settings often differ between development, staging and production, including redirect URIs, client IDs, client secrets, MFA policies and domain-level identity provider configuration. An upgrade can expose a mismatch that was hidden before, such as a SMART app or server-to-server integration failing after a restart. Keep an inventory of each identity provider and client credential per environment, store secrets in a managed vault, and compare each environment against its documented configuration before and after the change.
No owner for releases or upgrade knowledge
Medplum ships patch releases weekly, and its policy targets security fixes within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). If no named person watches the GitHub releases feed, those targets slip unnoticed. The same gap appears when one engineer holds every upgrade step and environment detail. Assign a release owner with a named backup, document the runbook and environment inventory, and have a second engineer execute a rehearsal.
What an ongoing Medplum support contract covers and what it leaves to you
DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. For a self-hosted Medplum deployment, the written scope matters more than the label on the retainer. Medplum ships a major version once a year in Q4, minor versions two to three times a year and patch versions weekly. A contract that covers only one upgrade leaves the rest of that rhythm with your team, so check that the retainer is written around the vendor's actual release pattern.
A typical contract for this platform bundles several components. Release monitoring tracks Medplum's published releases against the vendor cadence and flags which ones affect your deployment. Patch application runs inside change windows written into the contract, and those windows should be checked against the vendor's security targets of 7 days for critical vulnerabilities (CVSS 9.0 or higher) and 14 days for high ones (CVSS 7.0 to 8.9). Upgrades run sequentially through each minor version, with post-deploy data migrations scheduled and monitored, since skipping versions causes startup failures. The retainer also covers incident response hours, backup verification of the PostgreSQL database with restore tests, documentation updates and periodic access reviews of administrative and integration accounts.
Several decisions stay with your organization regardless of the contract. Business owners choose change windows and accept the downtime they bring, because a patch that is technically safe can still collide with a clinic schedule or a reporting cutoff. Clinical leads sign off on changes that affect workflows, such as edits to resource models, Bots or the app layer. Data governance decisions, including who may see which patient records, how long data is retained and how consent is recorded, belong to your privacy and clinical leadership. Compliance attestation also stays with you. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports. Independent auditors and certification bodies do that work, and Medplum's compliance documentation describes compliance as a shared responsibility between the vendor and its customers.
The division of work changes with the edition you run. On hosted Medplum plans, the vendor operates the platform, so the support contract covers a narrower set of tasks around your configuration and integrations. Under a self-hosted model, including the Community option and the custom-priced Enterprise Self-Hosted edition, your environment carries the infrastructure, database and upgrade load, and a retainer can cover much more of it. Support also depends on the version lifecycle. Each major version receives one year of Active support and one year of Maintenance, and the Enterprise extension adds 12 months of security patches for 36 months in total. Ask whether the retainer continues through that extension, and when your current major version leaves standard support. The cost of ownership guidance in this series sets out how these trade-offs affect the budget.
Before signing, put these questions to the provider in writing. Which Medplum releases, minor versions and patch types are in scope? How are change windows chosen and who approves them? How are incident hours counted, and what response is expected outside business hours? How is post-deploy migration time estimated for your dataset size, and who decides whether to pause a migration? How do backup verification and access reviews produce evidence you can hand to an assessor? Confirm each answer in the statement of work. Any figure for response times, hours or durations should come from that document, not from a verbal estimate.
How upgrades differ by starting version, deployment method and network
A deployment still on an older minor version must move through each minor release in order. Skipping minors is not supported: the vendor's upgrading guide notes that jumping from v3.1.2 straight to v4.3.4 causes startup failures. Post-deploy data migrations can run for hours or days on large datasets, so the path is planned as a sequence of stages, each with its own test and rollback point.
- Map the path: list every minor version between your current release and the target, and read each upgrade note in the upgrading guide.
- Size the data: count your FHIR resources and identify which post-deploy migrations each step runs. Ask for a run-time estimate based on a copy of production.
- Plan rollback per step: take a database snapshot before each step and record the image or build deployed.
- Re-test integrations: confirm client credentials, SMART apps and Bots still work after each step, not only at the end.
Confirm the target and every intermediate version in the upgrading guide before you schedule any production window.
AWS with CDK and CloudFormation is the vendor's recommended self-hosting path, so most upgrades change stack definitions your team already runs. The work is to regenerate the stack from the target release, review the diff for changes to databases, cache, compute and networking, and apply it in a non-production account first. Post-deploy migrations still run against your production database, so the stack change is only part of the work.
- Review the stack diff: check every change to the managed PostgreSQL and Redis resources, compute, load balancing and security groups before applying.
- Pin toolchain versions: record the CDK and CloudFormation versions used, and confirm they match what the release documentation expects.
- Detect drift: find manual console changes that a stack update would overwrite or reset.
- Monitor the migration: schedule the post-deploy migration step and watch database load, locks and error logs while it runs.
Confirm that the staging stack matches production configuration before you apply the same change to production.
Container installs move the change into image tags and manifests. Docker, Kubernetes, DigitalOcean and source builds share this pattern: pin the new image or build, update configuration, and make sure the post-deploy migration runs once and is observed. Source builds add a compile and dependency step, and DigitalOcean installs depend on the provisioning path your team chose, so each method needs its own checks.
- Pin image tags: deploy a specific release tag rather than an unpinned tag, and record the image digest in your change record.
- Compare configuration: diff environment variables and config files against the target release's self-hosting documentation.
- Control migration runs: in a rolling Kubernetes update, confirm the migration runs once and not once per replica.
- Rebuild from tags: for source builds, check out the tagged source, confirm the Node.js and PostgreSQL versions the release supports, and rebuild all artifacts.
Confirm the target image tag or source tag and the supported runtime versions in the self-hosting docs before the change window opens.
The Terraform-based GCP and Azure options are marked Beta in the vendor's self-hosting documentation. Confirm current status with Medplum before you rely on either option for an upgrade path, because module interfaces and supported versions can change between releases. Treat the upgrade as a module version change combined with a careful review of Terraform state.
- Confirm status in writing: ask Medplum whether the module and cloud combination is supported for your target version and what support scope applies.
- Pin module and provider versions: record both in your infrastructure repository so the upgrade is reproducible.
- Review the plan: run a plan against a copy of the state and look for any replacement of databases, clusters or network resources.
- Back up state: store a versioned copy of the Terraform state before any apply, and confirm you can restore it.
Get the Beta status and the support scope for your cloud in writing before you schedule any production upgrade work.
In an air-gapped or restricted network, release artifacts, container images and patch media must come in through an approved transfer process. The upgrade cannot begin until those artifacts are scanned, approved and staged inside the network. Security typically owns the import and approval, and the platform team owns the install, so both teams need the same artifact list before work starts.
- Stage every artifact: list each image, package and source archive for the target version and move them through your approved channel.
- Verify integrity: record checksums or signatures for each artifact at transfer and compare them with the release page.
- Host internal mirrors: run the container registry and package repository inside the network so the install never reaches public sources.
- Fit the patch window: Medplum's policy targets security patches within 7 days for critical vulnerabilities and 14 days for high ones, so your approval process must fit that window.
Ask Medplum which artifacts the target version requires, then confirm your import process can meet the vendor's patch targets.
Questions buyers ask about Medplum upgrade and support costs and effort
What drives the cost of a Medplum upgrade?
The main cost drivers are the number of minor versions between your current release and the target, the size of your dataset, and the complexity of your deployment and customizations. Medplum must be upgraded through each minor version in sequence, so every step adds planning, testing and a staging run. Dataset size matters because post-deploy data migrations can run for hours or days on large datasets. Costs also rise with Bots, custom integrations, identity provider changes, and the number of environments that must be tested. Ask for a quote that lists each minor step, the staging runs, cutover, rollback planning and documentation as separate line items, so you can see which parts scale with your data and which are fixed.
Can you quote a Medplum upgrade as a fixed-scope project?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. An upgrade quote is most accurate once the current version, the target version, the deployment type and the dataset size are known. The biggest variable is the migration runtime, which is best measured in a staging environment that resembles production before the production date is fixed. A written scope should name the minor versions covered, the environments in scope, the testing performed, the cutover plan, the rollback approach and the handover documents. Anything outside that list, such as new features or custom Bot rewrites, should be quoted separately so the baseline stays clear.
How long does a Medplum upgrade take to complete?
The duration depends mainly on how long the post-deploy data migrations take to run against your data, and that figure is best measured in staging rather than assumed. Medplum's upgrade guidance notes that migrations can run for hours or days on large datasets, so two deployments on the same versions can take very different amounts of time. Other factors include the number of minor versions you must pass through, the size of your staging environment, change window constraints and the time needed for testing and sign-off. Ask any provider, including DeployOpen, to base the schedule on a measured staging run and to show which steps depend on that measurement. There is no fixed figure that applies to every deployment.
Can our own engineers upgrade a self-hosted Medplum server?
Yes, a capable internal team can upgrade a self-hosted Medplum server, provided it has the right skills. The work involves Node.js and TypeScript for the server, PostgreSQL as the database, Redis as the cache, and the tooling used for your deployment, such as AWS CDK and CloudFormation, Kubernetes or Docker. The most common gaps are skipped versions and migration timing. Medplum requires sequential minor upgrades, and skipping one, for example moving from v3.1.2 straight to v4.3.4, causes startup failures. Teams also underestimate how long data migrations take on production-sized data. Read the upgrading guide for each version in your path, confirm the steps against your environment, and rehearse the full sequence in staging before committing to a production window.
What must we provide before a Medplum upgrade starts?
You need to provide a staging environment that closely matches production, a verified and restorable backup of the database and configuration, and agreed change windows for each step. You also need access to the cloud account, Kubernetes cluster or host where Medplum runs, along with the database credentials and any secrets the upgrade touches. Name an owner for each area: infrastructure, data, application and Bots, identity provider configuration, and final sign-off. Confirm who can approve a rollback and what the rollback trigger is. Finally, provide a copy of your current configuration and a list of customizations, so the upgrade plan covers your deployment rather than a generic one. Without named owners and tested backups, even a well-scoped upgrade stalls at the first decision point.
How does a Medplum support retainer differ from a one-time upgrade?
A one-time upgrade is a scoped project with a defined set of versions, environments and deliverables, and it ends when the agreed work is handed over. A support retainer is an ongoing arrangement that covers continuing support, upgrades and continuous testing over a period, and it recurs for as long as it is in place. Because Medplum ships patch releases weekly and a new major version annually, a retainer is often the better fit when you need to stay current rather than catch up once. Confirm in writing what the retainer covers, how patch releases are assessed and applied, how response is handled, and how upgrades are scoped and billed. Ask whether it commits to Medplum's own security patch targets before you rely on them.
How quickly does a self-hosted Medplum deployment need security patches?
Medplum's versioning policy targets security patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). These are vendor targets for releases, not a guarantee that your environment will be patched within the same window. Your own process decides the real exposure, because a patch must be tested, scheduled into a change window and deployed through each required minor version. Each major version also has a lifecycle of one year of Active support and one year of Maintenance, with an Enterprise extension of 12 more months of security patches for 36 months in total. Confirm which lifecycle applies to your version and edition, and plan upgrades before a major version leaves support.
How DeployOpen scopes, delivers and supports Medplum upgrades
DeployOpen plans, implements and supports self-hosted Medplum inside your own cloud accounts, data centers or air-gapped networks. Each upgrade follows a written scope, is rehearsed against a copy of your environment, and ends with documented handover to your team.
How we scope
- Inventory your current Medplum version, deployment method and database and Redis footprint before any plan is written.
- Map every minor version between your release and your target, since upgrades must run in sequence.
- Agree in writing the upgrade path, post-deploy migration windows, rollback steps and who approves each cutover.
How we build
- Rehearse each minor step in a staging copy that mirrors production data volume and configuration.
- Time post-deploy data migrations on representative data so your change window reflects measured runtimes, not guesses.
- Verify authentication, SMART-on-FHIR launch, Bots and HL7 interfaces after each step, and record results in the change log.
How we hand over
- Deliver a runbook covering each upgrade step, its checks, its rollback path and known startup failure modes.
- Document the deployment as-built, including infrastructure definitions, configuration and backup and restore procedures.
- Walk your platform and security teams through the runbook so the next upgrade can run with your own staff.
How we support
- Ongoing support is available as a retainer covering monitoring of Medplum release activity and scheduled upgrades.
- Patch triage follows the vendor's stated security patch targets, and we agree response expectations in the retainer scope.
- Confirm with us in writing which environments, versions and hours a retainer covers before signing.
