What MISP upgrades and support involve
An operating MISP instance needs a repeatable routine for applying releases, testing them and coordinating the feed and sync partners who depend on it. MISP 2.5 is the recommended line for new deployments, and MISP 2.4 is end of life with security fixes only, so an instance still on 2.4 should be planned for migration rather than kept indefinitely. Upgrades also touch more than the application: the database, Redis, PHP and the web server configuration, and any custom modules or PyMISP scripts that call the API all need to be checked after each change.
Four triggers usually start upgrade work. A new security release arrives and the patch window is short. A vendor or project end-of-life date approaches. A module, such as an enrichment module, a SSO plugin or a custom workflow, breaks after an update. Or a new partner asks to join synchronization and needs a compatible version. Each trigger should lead to a written change record that names the target version, the test instance used, the rollback path and the partners notified before the window opens.
Many teams keep routine patching in-house, because the work is mostly sequencing and checking rather than design. Teams often bring in a partner for the first upgrade, for setting up a staging environment that mirrors production sync, or for retainer-based coverage that handles monitoring of releases, scheduled patching and post-upgrade checks. Ask any provider to state in writing which of these items are included, how many environments are covered, who approves a production change, and how partner notifications are handled.
What the service includes
Each MISP upgrade follows the same cycle: track the release, test it on a copy, check modules and integrations, coordinate partners, then verify production. Each step produces a record you can check against the written scope.
Release tracking and triage
The team watches MISP 2.5 point releases and security fixes, then triages each one by severity, the modules and integrations it touches, and whether it changes the database schema. Recent examples include 2.5.47, which introduced a new database migration system with PostgreSQL support, and 2.5.50, released on 9 October 2026. Each release gets a written decision: apply now, schedule, or defer with a reason.
Staged upgrade runs
Every upgrade is first run on a non-production copy built from a recent database backup and the production configuration. The copy should match the production web server, PHP, database engine, Redis version and installation method, since a mismatch can hide faults that appear only after go-live. Ask how long the staging copy is kept in step with production.
Module and integration checks
After each change, the team checks every enabled module, feed import, export format and custom integration against a list agreed at scoping. This covers enrichment and expansion modules, PyMISP scripts, SIEM exports and OidcAuth single sign-on settings. Each failed check is logged with an owner, so custom code that breaks on a new release is found before analysts depend on it.
Feed and sync partner notification
Sync partners and feed consumers receive notice before each maintenance window, with the planned start, the expected pause in push and pull, and a contact for problems. Sync is paused on production, the upgrade runs, and sync resumes in a defined order while the team confirms that events flow in both directions. Ask who approves notices and who may request an emergency pause.
Post-upgrade verification
Verification confirms that the upgraded instance handles logins, event creation, correlation, API keys and sharing groups as it did before the change. It also checks that distribution levels still limit what each partner can see, because a permissions regression can expose attributes to the wrong organization. Each check is recorded as passed, failed or accepted by a named approver.
Runbook, test record and handover
The engagement ends with an upgrade runbook that lists step order and rollback points, a test record for each run, a maintenance calendar, and a written handover of the support scope. The handover states what the support covers, what remains with your team, and how changes to scope are requested. You keep all four documents and can give them to auditors or a successor provider.
What drives effort and cost
Each row names a factor that changes the work for every MISP upgrade or support period, why it matters, and what your team can do to keep it contained.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Installation method | The Ubuntu installer, Docker images, Ansible roles, Puppet and RPM packages each have their own upgrade path, and mixing them multiplies test and rollback steps. | Standardize on one installation method for all environments and record the exact version and configuration in source control. Confirm with the project which method you run before quoting. |
| Enabled modules | Each enabled module, such as enrichment, import or export modules, adds code to retest after every 2.5 release and can break on dependency changes. | Trim modules you do not use, document why each remaining one is enabled, and keep a short list of the ones that must be checked in every upgrade test. |
| Custom PyMISP scripts and automation | Scripts that call the API or depend on specific object templates must be re-tested when API behavior, taxonomies or object definitions change. | Keep scripts in version control with tests against a staging instance, pin the PyMISP version, and remove scripts that no one owns. |
| Feeds and sync partners | Each feed and sync partner needs coordination on timing, certificates, and sharing settings, and a change on your side can disrupt their pulls or pushes. | Agree a list of partners and feeds before each window, notify them in advance, and confirm sharing groups and distribution settings still apply after the upgrade. |
| Database migration | Moving to PostgreSQL or applying the database migration system introduced in 2.5.47 adds data validation, longer downtime risk, and a rollback plan that is harder to test. | Decide early whether the database move is in scope, take a verified backup before any schema change, and rehearse the migration on a copy of production data. |
| Number of environments | Each environment such as development, staging and production needs its own upgrade, testing and sign-off, so effort grows with every extra instance. | Keep the number of environments to what the team actually uses, and upgrade staging first so production changes follow a tested sequence. |
| Support response expectations | Faster response targets for security releases or outages require on-call coverage, and the scope of what is covered changes the hours involved. | Define in writing which issues are covered, the response expectations for each category, and the process for scheduling maintenance windows in advance. Ask for the defined terms in any quote. |
How an upgrade and support engagement runs
Each phase produces a written record, so every upgrade is tested on a copy, scheduled with partners, checked at go-live and followed by a planned support cadence.
Record the baseline and installation method
Record the running MISP version, the installation method (installer, Docker, Ansible, Puppet or RPM), the operating system, database and Redis versions, enabled modules, feeds, and each sync partner with its distribution settings. The output is a written inventory that becomes the reference for every later check.
Test the upgrade on a copy with rollback
Clone the production server and database into an isolated environment and run the upgrade there. Review the release notes for the target version, including database migration changes, since MISP 2.5.47 introduced a new migration system. The output is a tested runbook with a documented rollback that restores the pre-upgrade snapshot and database backup.
Verify modules, feeds and integrations
Re-run enabled modules, enrichment and export paths, feed pulls, sync connections and any SIEM or IDS integrations against the copy. Compare results with the baseline inventory, including API key access and correlation output on a sample of events. The output is a verification checklist marking each item as passed, changed or blocked.
Notify partners and schedule the window
Tell sync partners and internal users the planned window, the expected effect on synchronization and feeds, and who to contact during the change. Agree the production window in writing and confirm how partners will pause or queue their pushes. The output is a dated change notice and recorded partner acknowledgements before work begins.
Run the production upgrade and go-live checks
Take fresh backups, apply the tested runbook, and check login and SSO if configured, API access, feed updates, sync push and pull, exports and background worker health. Compare each result with the baseline. The output is a go-live report, with the rollback decision recorded if any check fails.
Watch releases and agree the support cadence
Track MISP release announcements and security fixes, assess each one against your instance, and schedule patches through the same test, notify and window cycle. Confirm the support cadence in writing, covering what is reviewed, who responds and how paid support or a retainer applies. The output is a support calendar and a release log.
What to keep in-house and what to outsource
This table compares the MISP work most teams keep internally with the operational work often outsourced, and names the skills each side needs so you can match the split to the people you have.
| Work area | Typically kept in-house | Typically outsourced |
|---|---|---|
| Threat intelligence decisions | Deciding which indicators, galaxies and feeds your organization trusts and acts on, which requires analyst judgment and knowledge of your threat landscape | Maintaining feed configuration and taxonomy updates once your team has made the decisions |
| Sharing policy | Setting distribution levels, sharing group membership and what must stay inside the organization, which requires sharing-group knowledge and your legal or ISAC obligations | Implementing the agreed policy as role, sharing group and sync filter configuration, which requires MISP administration and PHP and MySQL or MariaDB familiarity |
| Partner routing | Deciding which partner organizations receive which events, which requires knowledge of trust relationships and data-handling terms | Configuring push and pull server connections and filters, which requires Linux administration and MISP sync setup experience |
| Maintenance window sign-off | Approving timing, communication to partners and rollback decisions, which requires business owner authority and incident response contacts | Preparing the change plan, dependency checklist and rollback steps for approval, which requires Linux administration and runbook writing skills |
| Release tracking | Reviewing advisories and deciding when your organization accepts a new release, which requires a named owner and a patch cadence agreed with security | Monitoring MISP release notes and security fixes, then producing an impact summary, which requires familiarity with the MISP GitHub releases |
| Staging upgrades | Providing a staging copy of your data and approving test results, which requires data owner access | Running the upgrade on a staging server, including the database migration step, which requires Linux administration, MySQL or MariaDB and Redis operation |
| Module and script regression testing | Defining the critical workflows, such as event import, sync, and sightings, that must still work after upgrade | Testing enrichment modules, PyMISP scripts and API integrations against the new version, which requires PyMISP scripting and REST API knowledge |
| Out-of-hours patch execution | Standing by for escalation and approving go or no-go during the window | Executing the patch, verifying services and restoring from backup if needed, which requires Linux administration, Redis operation and on-call availability |
What usually goes wrong
MISP upgrades and routine support tend to fail in a small set of predictable ways. Each risk below names the control that prevents it.
Upgrading production without a rollback
Upgrades change application code and database schema together, and the 2.5.47 release introduced a new database migration system. Before any production change, take a full database backup, restore it to a staging copy, run the upgrade there and time a rollback. Record the steps and results in the change ticket.
Custom modules breaking after updates
Custom modules, enrichment modules and PyMISP scripts depend on internal functions and API behavior that can change between releases. Keep them in version control, pin the PyMISP version, and run each one against staging with a known set of events and API calls before the upgrade reaches production. Confirm which endpoints your developers call.
Sync partners receiving unexpected changes
Once an instance pushes or pulls events, a misconfigured upgrade or a broken sync job can reach partners before anyone notices. Notify partners of the window in advance, pause outbound sync during the change, and check sync status and error logs for each connection before resuming. Ask partners to confirm they received a test event.
Feeds stopping without alerts
Default and external feeds can fail quietly when a source changes its format, a credential expires or a fetch job stops after an upgrade. Monitor each feed's last successful fetch and its event count, alert when a feed goes stale, and compare counts before and after every maintenance window.
Falling behind a security release
Security fixes arrive as releases, and an instance that waits for a convenient window stays exposed for the length of that wait. Follow the project's release announcements, classify each release by severity, and keep a documented release calendar that sets how quickly security releases move through staging to production. Agree those timings with your risk owner.
Running a 2.4 instance in production
MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. An instance still on 2.4 carries that exposure and drifts further from current features and integrations. Inventory every 2.4 instance, plan the move to 2.5 with a dated owner, and test the upgrade path before the cutover.
How the work differs by environment
A single instance installed with the provided Ubuntu installer is the most common starting point and the one the project documents most directly. The MISP download page recommends MISP 2.5 on Ubuntu 24.04 and provides an upgrade script for Ubuntu, so the upgrade path is usually the shortest.
- Testing: Clone the production database and files to a staging host with the same OS and PHP build, then run the upgrade script there first.
- Partner coordination: Confirm which sync partners will pause pushes during the window and whether any feeds depend on local cron jobs.
- Rollback: Take a full database and filesystem backup before the script runs, and confirm the restore steps on staging.
- Confirm: Ask the vendor whether the installer's upgrade script covers your exact package versions, and check your own Ubuntu release against the download page.
A containerized deployment built from the published Docker images changes the upgrade from an in-place script to an image swap. Data lives in volumes and an external database, so the persistence layout decides what a rollback can actually restore.
- Testing: Pull the target image into a non-production stack that mirrors your volume and database configuration.
- Partner coordination: Tell partners about the window, since container restarts can interrupt background workers and sync jobs.
- Rollback: Keep the previous image tag and a database dump together, because rolling back the image alone may not undo schema changes.
- Confirm: Verify with the vendor which image tags are supported and whether the database migration can be reversed.
An instance managed by Ansible roles or Puppet modules is upgraded through configuration code, so the upgrade work includes changing the managed version and reviewing how the role applies database migrations. Drift between the code and the running host is the most common surprise.
- Testing: Run the role or module against a staging inventory that matches production, then check for changes the role reports on an already-current host.
- Partner coordination: Coordinate with whoever owns the configuration repository so no unrelated change lands in the same window.
- Rollback: Revert the version variable in code and restore the database backup, since a configuration revert alone does not reverse data changes.
- Confirm: Ask the project which role versions match each MISP release, and confirm your own inventory variables cover any custom settings.
An RPM-based host uses packages rather than the Ubuntu installer, so package manager behavior, PHP and web server versions and SELinux or firewall rules become part of the upgrade test. Package availability for your distribution release needs checking before a window is planned.
- Testing: Install the target package set on a staging host of the same distribution release and check PHP modules, workers and permissions.
- Partner coordination: Agree the window with partners, and check whether any sync client depends on a specific PHP or Python version.
- Rollback: Record the exact package versions before upgrading so the previous set can be reinstalled, and back up the database first.
- Confirm: Verify with the project which RPM packages are published for your distribution and release, and whether the package path is maintained for the target version.
An instance connected to many sync partners and feeds has the widest coordination surface. An upgrade can change how events are pushed, filtered or validated, so a change that looks local can affect every connected organization.
- Testing: Replay sync and feed imports against staging using recent traffic, and compare event counts and distribution settings afterward.
- Partner coordination: Notify each sync partner in advance, agree a pause window, and confirm which side should resume first after the upgrade.
- Rollback: Plan for pulled events that arrived during a failed window, and decide in advance whether they are removed or reconciled.
- Confirm: Ask each partner which MISP version they run, and confirm feed sources and their update schedules with the feed providers.
An air-gapped or restricted deployment cannot download release files or packages directly. Every artifact must enter through an approved transfer path, which adds lead time and a verification step before any test begins.
- Testing: Stage the release files, checksums and dependency bundles inside the enclave, then test the upgrade on an isolated copy before production.
- Partner coordination: Sync may be limited to approved peers across a controlled boundary, so confirm which connections are allowed during and after the window.
- Rollback: Keep the previous release bundle inside the enclave, since the original download source may not be reachable to recover it.
- Confirm: Check with your security team how release files are approved and verified, and ask the project which dependencies must be bundled for offline installs.
What you need to provide
Before work starts, we need administrative access to the MISP host and its database, plus a current backup that you have confirmed can be restored. Ask your team to note the running MISP version, the installation method (the project's Ubuntu installer, Docker, Ansible, Puppet or RPM packages) and any local changes to the web server or PHP configuration. Those four facts decide which upgrade path applies and whether the work is an in-place upgrade or a rebuild.
We also need an inventory of enabled modules, feeds and sync partners, with a named technical contact for each partner. Modules, custom taxonomies and galaxies, and any PyMISP scripts that depend on the API should be listed with their owners. Sync partners need to know when a maintenance window will interrupt pushes and pulls, so their contacts should be on the same list as the internal change approvers.
Name one owner who approves maintenance windows and can accept the risk of a rollback. Put the agreed window in writing, including the time zone, the expected duration and who is told if the window moves. Clear ownership and a written change window shorten the first upgrade cycle more than any other input, because decisions that would otherwise wait for a meeting are made in advance.
Provide a test environment, or permission for us to create a copy of production on separate infrastructure. Upgrades should be rehearsed against real event data, feed imports and sync settings before they touch production. Finally, decide who receives urgent security-release notices outside business hours and how they will be contacted. Security fixes are not scheduled around office hours, so this decision belongs in writing before the first cycle begins.
Questions buyers ask about MISP upgrades and support
How much does a MISP upgrade and support engagement cost?
Cost follows from the written scope. DeployOpen does not publish a price list, and a fixed-scope quote is written once the scope is agreed. The main drivers are the number of MISP instances, how far the current version is behind MISP 2.5, the modules, custom objects and integrations that must be retested, the feeds and sync partners to coordinate, the size of the test environment, and whether the work is a one-off upgrade or an ongoing retainer. Ask the quote to separate one-time upgrade work from recurring support so you can compare the two over time.
How long does a MISP upgrade take to plan and complete?
The calendar is set by the scope and by the change windows you agree with your sync partners and feed users, not by the release date alone. MISP 2.5 receives frequent releases, including 2.5.47 on 17 September 2026 and 2.5.50 on 9 October 2026, so the target version may gain point releases before go-live. Release 2.5.47 also introduced a new database migration system with PostgreSQL support, which adds test time if your database layout changes. Confirm any notice period your partners require for sync changes, and fix the target version at kickoff.
What do we need to provide for a MISP upgrade?
The work needs access and decisions from your side before testing starts. Expect to provide administrative access to the MISP servers, the database and the web server, a staging environment that resembles production, a list of enabled modules, custom objects, integrations and feeds, and named contacts who can approve change windows. You will also need a tested backup, a rollback plan, and a contact at each sync partner who can confirm that their instance is ready. Missing inventory is the most common cause of extra scope, so ask for an inventory review in the first phase of the work.
Can our internal team upgrade MISP without a partner?
Yes, a team with Linux, database and web server skills can perform an upgrade using the project documentation, the upgrade script the project provides for Ubuntu, and a staging copy of the instance. The harder parts are validating custom modules and integrations after the upgrade, coordinating sync partners, and rehearsing rollback. Check whether the team has time to test each point release it will need to absorb, and whether the people who run the upgrade can also cover the on-call and sharing questions that follow it.
What is the difference between a one-off upgrade and a support retainer?
A one-off upgrade is a fixed-scope project with a defined end point, such as moving an instance to the current 2.5 release and handing it over. A support retainer is an ongoing agreement for upkeep, covering the patch and release work, testing and changes as new versions arrive over the agreed term. DeployOpen makes ongoing support, upgrades and continuous testing available as retainers. Ask what the retainer includes, how response is defined in writing, and what it excludes, such as custom module development.
What do the MISP project's paid support and third-party providers cover?
The MISP project offers paid support services, and a number of third-party providers offer commercial support. Their coverage, response terms and willingness to work on your customizations differ, so confirm the scope in writing with each provider before you choose one. DeployOpen works separately from these options. It plans, implements, tests and supports MISP inside your own infrastructure, and it is not an official MISP partner or certified provider unless that status is confirmed in writing.
How DeployOpen delivers MISP upgrades and support
DeployOpen plans and carries out MISP upgrades and support inside infrastructure you control, with each engagement agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as a retainer.
How we scope
- The written scope lists the MISP instances, versions, server hosts and database engines covered by the upgrade or support work.
- Feeds, sync partners, custom modules and integrations are inventoried so maintenance windows and dependencies are known before changes begin.
- Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing at the start.
How we build
- Upgrades are rehearsed on a staging copy of the production database, with module and plugin compatibility checked before any cutover.
- Feeds and synchronization partners are paused, tested and resumed in a planned order so indicators and events are not silently lost.
- Rollback steps, backup verification and post-upgrade checks against sharing groups and distribution settings are written and tested first.
How we hand over
- Runbooks describe the upgrade procedure, maintenance window steps, sync partner communications and rollback decisions for your own team.
- Configuration, versions, custom components and known issues are documented so the next upgrade can be planned without the original builders.
- Handover includes a walkthrough with administrators and a record of what was changed, tested and left for your team to confirm.
How we support
- Ongoing support can be taken as a retainer covering security release review, upgrade planning and maintenance windows for your instances.
- Patch and release tracking is matched to your agreed cadence, with testing performed before production changes are made.
- Support scope, response expectations and inclusions are set out in the written agreement, so you know what the retainer covers.
