What a MISP migration or upgrade involves
Three situations turn MISP work into a one-time migration or upgrade project: MISP 2.4 is end of life and receives security fixes only, the instance must move to a different server or hosting environment, or the team is consolidating events and indicators from another threat intelligence platform. Each one changes the database, the configuration or the data itself, so it needs a plan, a rehearsal and a defined cutover. Routine patching of a supported 2.5 instance does not.
A patch on a running 2.5 instance usually keeps the same server, database and sync relationships. A 2.4 to 2.5 upgrade, a rebuild on new hardware or an import from another platform can change all three. Organizations, user roles, sharing groups, distribution levels and sync partner settings must behave the same after the move. A sync path may stop exchanging data without an obvious error, so verify each feed and sync connection after cutover.
MISP 2.5 is the recommended version for new deployments, and the project strongly advises against installing new 2.4 instances. The download page lists an upgrade script for Ubuntu, recommends 2.5 on Ubuntu 24.04 with the provided installer, and also lists Docker images, Ansible roles, Puppet and RPM packages. Release 2.5.47 introduced a new database migration system with PostgreSQL support, so confirm your target version and any schema changes in the release notes before scheduling work.
In-house teams can do this work if they have a Linux administrator with MySQL or MariaDB experience, a rehearsal environment and time to test sync and feed behavior. A partner is most useful when the scope includes several sync partners, custom modules or an import with sharing rules to preserve. The right choice depends on the scope written into the plan, including the number of sync paths, integrations and data sources involved.
What the work includes
Six workstreams take the instance from planning to a verified cutover. The work produces a migration record, a verification report and a rollback plan that the client keeps.
Target platform and installation
Choose the installation method the team will operate: the Ubuntu installer, Docker images, Ansible roles, or Puppet or RPM packages. The project recommends MISP 2.5 on Ubuntu 24.04 with its installer. Confirm the operating system, PHP, MySQL or MariaDB, Redis and TLS setup before the rebuild, and record each choice in the migration record.
Upgrade path and database choice
MISP 2.4 is end of life and receives security fixes only, so moving to 2.5 is a planning requirement. The project provides an upgrade script for Ubuntu. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, so confirm whether the instance stays on MySQL or MariaDB or moves to PostgreSQL, and test the chosen path on a copy of the data first.
Organizations, users and roles
Map each organization, local user, role and API key owner from the source instance to the target. Decide which accounts move and which are recreated, and confirm that each organization keeps its host and sharing identity. Check that role permissions match the access model, then log counts and exceptions in the migration record.
Events, attributes and tags
Move events with their attributes, objects, tags, galaxies and sightings, then compare counts and sampled records against the source. Taxonomy and galaxy versions on the target should match what migrated events reference. Keep original event identifiers where possible so references and sync remain intact. Results go into the verification report.
Sharing groups and sync connections
Rebuild sharing groups with the same members and distribution levels, then reconnect push and pull sync partners. Confirm each partner's certificate, API key and filtering rules before enabling sync. Pause sync on the source during cutover to prevent duplicate or conflicting events, and document each connection in the runbook.
Cutover, rollback and handover
Agree a cutover window with sync partners, freeze changes on the source, run the final data load and verification, then switch DNS or the reverse proxy. Keep the source readable and the rollback plan tested until sign-off. The handover runbook covers backups, upgrades, sync and restore steps.
What drives cost and duration
The table lists the factors that most change the effort of a MISP migration or 2.4 to 2.5 upgrade, why each one matters, and how to keep it under control before work starts.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Events and attributes | Every event and attribute must be exported, transformed where needed, imported and checked. Large volumes lengthen export, import and correlation rebuilds. | Set a retention or age cutoff with the threat intelligence owners. Archive old events that are no longer needed for analysis, and confirm the counts from the source before scoping. |
| Organizations and users | Each organization, user, role and API key must map correctly to the new instance. Mismatched roles can expose data to the wrong group. | Export a current inventory of organizations, roles and sharing groups. Remove dormant accounts and agree the target role model before migration testing starts. |
| Sync partners and feeds | Sync connections and feed settings usually need to be re-established and tested with each partner, and partner-side changes may be needed. | List every partner, push and pull direction, and distribution rule. Ask partners early to confirm their endpoints, keys and availability windows. |
| Custom objects, taxonomies and galaxies | Custom objects, local taxonomies and galaxy clusters may not carry over unchanged and can break correlation, exports or integrations after the move. | Inventory every custom component and its version. Check each one against the target 2.5 release and remove unused items before migration. |
| Dependent SIEM and IDS integrations | Exports consumed by SIEM, Suricata, Snort, Zeek or RPZ pipelines must keep the same format, field names and schedules, or detections may silently stop. | List each consumer, export format, endpoint and schedule. Test each one against the new instance and keep the old export running until the cutover is confirmed. |
| Age and customization of the starting installation | An older 2.4 instance with local patches, custom PHP or manual database changes needs more analysis and more testing than a standard installation. | Record the installed version, operating system, PHP and database versions, and every local change. Compare the installation against a clean build before planning the upgrade path. |
| Export quality of the source platform | When moving from another threat intelligence platform, incomplete fields, inconsistent types or missing sharing metadata add mapping and cleaning work. | Sample exports from the source and check field coverage, timestamps, distribution values and tags. Agree the mapping rules in writing before bulk import. |
| Number of environments to verify | Each environment, including test, staging and production, needs its own install, data load, sync test and sign-off, which multiplies verification effort. | Agree which environments are required and which can be shared. Keep test data representative so one verification pass can cover several environments. |
| Compliance evidence required | Some programs require documented change records, access reviews, backup restore tests and retained logs. Producing this evidence adds documentation and testing steps. | Ask the assessor or internal audit team which evidence they expect before scoping. DeployOpen prepares the evidence, while independent auditors and certification bodies assess it. |
Project phases and outputs
The sequence moves a MISP instance onto a supported 2.5 deployment while keeping sharing relationships, data and integrations intact.
Inventory the current instance
DeployOpen engineers record the MISP version, operating system, database and Redis versions, PHP modules, plugins, custom objects, taxonomies, feeds, users, organizations and API keys in use. The output is a written inventory that marks each item to keep, change or retire. The phase is complete when your team has reviewed and approved the inventory.
Map sync and sharing relationships
Every sync partner, push and pull direction, distribution level, sharing group, filtering rule and community connection is documented. The output is a sharing map that shows which events and attributes leave your organization and who receives them. Partners are confirmed against the map before any setting changes, so sharing behavior can be checked later.
Design the target and build staging
The target MISP 2.5 layout is designed, covering server sizing, database choice, authentication, roles and the installation method your team prefers. The staging build follows that design, and the project's current download guidance for 2.5 and its recommended Ubuntu release are confirmed before installation. The output is a smoke-tested staging instance and a configuration record.
Rehearse the data migration
A copy of production data is migrated to staging, and the run is repeated until the steps, timings and exceptions are understood. Failed records, schema changes and events needing manual handling are logged. The project's upgrade script is one input to the runbook, and the rehearsal confirms what it changes in your data. The output is a rehearsal log and a corrected runbook.
Validate sharing and integrations
The staging instance is checked against a written checklist covering event and attribute counts, distribution levels, sharing group membership, sync pushes and pulls, correlation results, feeds, API key behavior, taxonomies, galaxies, and each SIEM, IDS or SSO integration. The output is a signed checklist with every failure resolved or formally accepted. Each item has a named owner.
Cut over with partner notification
The cutover window is agreed with your team, sync partners and community contacts are notified in advance, and traffic and sync endpoints are switched to the new instance. The output is a signed-off cutover plan containing the partner notice, contacts and rollback steps. The rollback steps are rehearsed in staging before the window opens.
Monitor and hand over
Logs, sync status, background job queues, error rates and integration feeds are watched after cutover, and issues are fixed as they appear. Runbooks, configuration records, access lists and the upgrade procedure are handed to your operations team. The phase closes when the handover pack is accepted in writing and alert ownership has moved to your team.
What to keep in-house and what to outsource
This table shows which parts of a MISP migration and 2.4 to 2.5 upgrade usually stay with your own staff because they are business or policy decisions, which parts are commonly outsourced as technical delivery, and which skills each part requires, so you can judge where a partner adds value.
| Work part | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Event and attribute retention | Deciding which historical events, attributes and sightings are worth keeping, archiving or dropping during the move | Mapping retention rules into migration scripts and reporting what was excluded | Threat intelligence analysis, data governance |
| Organization and role ownership | Confirming who owns each organization, who administers it and which roles map to which people | Building the organization and role model in the new instance and checking user access after cutover | MISP administration, identity and access management basics |
| Sharing rules and distribution | Signing off on distribution levels, sharing groups and what may leave the organization | Configuring sharing groups and distribution defaults as approved, then testing that they behave as specified | MISP permission model, information sharing policy |
| Sync partner agreements | Agreeing which partners and communities sync, under what terms, and who approves new connections | Reconfiguring sync servers, testing push and pull after upgrade and documenting the connection settings | MISP synchronization, TLS and API key handling, Linux administration |
| Installation and platform build | Approving the target host, Ubuntu release, and change window | Installing MISP 2.5 on the agreed platform, including the web server, PHP, database and Redis components | Linux administration, PHP, CakePHP, MySQL or MariaDB or PostgreSQL knowledge, Redis |
| Data migration scripts | Reviewing sample records and approving the field mapping from the source platform or old instance | Writing and running import or export scripts, including PyMISP-based transfers where they fit | PyMISP scripting, Python, MISP JSON and STIX data models, database knowledge |
| Validation and acceptance | Defining the test cases that prove the data and sharing behavior are correct and signing acceptance | Running reconciliation checks on counts, correlations, tags, and sync results before go-live | Threat intelligence analysis, SQL, PyMISP scripting |
| Cutover runbook and rollback | Deciding the cutover timing, communication to sync partners and go or no-go authority | Writing the step-by-step runbook, rehearsing it and documenting rollback to the previous instance | Linux administration, database backup and restore, operational change management |
What usually goes wrong
Most MISP migrations fail in places that look routine: sharing settings, sync connections, imported relationships and cutover steps. Each risk below has a check to run before the new instance serves users or partners.
Sharing groups and distribution levels shift
During a rebuild, distribution levels and sharing group references can be reassigned or dropped, which can expose restricted events or hide them from the partners who need them. Before cutover, export every event and attribute with its distribution level and sharing group UUID from the old instance. After import, compare those counts and values, and confirm each sharing group's organization membership matches the source.
Sync partners stop receiving events
A rebuilt instance often gets a new URL, certificate, API key or instance identifier, and partner servers that still point at the old settings silently stop pulling or pushing. Plan a coordinated change with each partner that covers the new endpoint, credentials and any identifier changes. Run a test push and pull with every partner before the old instance is retired.
Imports lose relationships and tags
Moving events from another threat intelligence platform can flatten links between events, drop tags, or map source fields to the wrong MISP attribute types. Write a field mapping that covers attributes, objects, tags, taxonomies and timestamps before importing anything. Load a representative sample and verify that object relationships and tags survived, and record what the importer does not carry over.
Plugins and customizations break on 2.5
Custom objects, taxonomies, galaxies, enrichment modules and PyMISP scripts written for 2.4 may fail or behave differently on 2.5. Inventory every customization and plugin on the old instance, then test each one on a staging copy running the target version. Confirm each plugin supports the 2.5 branch before cutover, and keep a list of anything that needs rework or removal.
Database migration fails on large datasets
Schema migrations on a large MISP database can run far longer than expected or stop partway when disk space runs short. Rehearse the migration on a copy of production data sized like production, and measure its duration and free disk space at each step. Check the migration system and database engine support in the exact release you plan to deploy, since 2.5.47 introduced a new migration system with PostgreSQL support.
Cutover without a tested rollback
Teams that switch traffic to the new instance without a rehearsed return path often discover that sync partners, users and feeds cannot be pointed back in time. Keep the old instance and its database backup restorable, and write down the conditions that trigger a rollback along with the steps. Rehearse the rollback on staging, including repointing sync partners, before the production cutover.
How the work differs by starting point
This path keeps the existing server and data and moves a running MISP 2.4 instance to 2.5 on Ubuntu using the upgrade script the project provides. The main risk is that the instance carries years of configuration, so the scope is mostly about preserving it.
- Scope: Confirm the Ubuntu release is one the project supports for 2.5, which the download page lists as Ubuntu 24.04, and plan an OS upgrade first if it is not.
- Scope: Review custom modules, enrichment services and any local changes to the application tree, since the script will not know about them.
- Verify: Take a tested database backup and a configuration export before the run, and confirm you can restore both.
- Verify: Check sync partners, feeds and scheduled tasks after the upgrade, and confirm that roles, organizations and sharing groups still match your policy.
- Confirm: Ask the team that runs the instance whether the database migration system introduced in the 2.5 release line affects any custom schema changes.
This path builds a fresh 2.5 instance on new servers, then moves data across with a MISP export and import. The old server stays available until the new one is verified, so cutover is the point where most of the risk sits.
- Scope: Size the new host and database for the current event volume, and decide whether the database stays on the same engine version or changes.
- Scope: Rebuild organizations, users, roles and sharing groups deliberately rather than assuming they come across unchanged in the export.
- Verify: Compare event, attribute and tag counts between old and new instances, and spot-check distribution levels on sensitive events.
- Verify: Re-point sync partners, API keys and SSO settings, then test each one from the new address before retiring the old server.
- Confirm: Check with the project documentation which export scope and options your version supports, and test the import on a copy first.
This path brings events and indicators from another threat intelligence platform into an existing MISP. Scope depends heavily on what the source platform can export and how much of its sharing logic MISP can represent.
- Scope: Inventory the source objects (events, indicators, tags, sources, sharing rules) and decide which ones must map to MISP attributes, objects, taxonomies or galaxies.
- Scope: Plan a mapping for sharing and distribution settings, because a source system's access model rarely matches MISP distribution levels and sharing groups one for one.
- Verify: Confirm which import formats and parsers the current release accepts for your source data, and do not assume a format is supported until you have tested it.
- Verify: Run a sample import into a staging instance and check duplicate handling, timestamps, and whether original sources are preserved.
- Confirm: Decide who may see imported sensitive data before the first production import, because sharing settings are applied at import time.
This path applies to teams that deploy MISP through Docker images, Ansible roles, or RPM packages inside a controlled environment, often with change management and a locked build pipeline. The upgrade is still a version change, but it runs through the packaging you already maintain.
- Scope: Confirm which packaging method the project currently supports for 2.5, since the download page lists Docker images, Ansible roles, Puppet and RPM packages as options and support differs between them.
- Scope: Review local overrides, such as templates, environment files and custom playbook variables, that must be merged into the new release.
- Verify: Rebuild images or packages in a test pipeline, then run the upgrade against a restored copy of production data.
- Verify: Check that secrets, certificates and volume mounts persist across container or package replacement, and that the database migration runs once.
- Confirm: Agree the rollback method in the change record, including how you return to the previous image or package if the migration fails.
What you need to provide
Start with three inputs that make every later step safe: a current backup, an inventory of what the instance holds, and read access to the existing system. The backup should include the database and attachment files, and it should be restored once on a separate host before any migration step begins. The inventory lists organizations, users, sync servers, feeds, enabled modules, and any custom objects or taxonomies. Read access to the instance and its configuration lets us compare settings with the new build. The platform owner signs off on the backup, and the security lead approves the scope of read access.
Some decisions cannot be delegated to the implementation team. Each organization needs a named owner who confirms which events and attributes are kept, archived, or dropped, and who approves changes to that organization's data. Sharing rules need a decision too: distribution levels, sharing groups, and any sync filtering that should carry over to the new instance. The information security lead usually signs off on sharing and retention rules, and each organization owner signs off on their own data. Record these decisions in writing before cutover, because an undocumented rule is hard to reproduce.
Sync partners and feeds depend on the instance staying reachable and consistent. Provide a list of every sync partner and feed, with a named technical contact for each and whether the connection is push, pull, or both. Provide a staging environment that matches production closely enough to test the 2.4 to 2.5 upgrade or the rebuild, including the same modules and integrations. The maintenance window must be agreed with partners in advance. Confirm the window length with your operations team, and get each partner contact to acknowledge the window in writing.
If events are coming from another threat intelligence platform, provide that platform's exports and the field mapping you expect. The exports should keep original identifiers, timestamps, sharing markings, and tags, because these determine how records are rebuilt in MISP. Confirm with the owner of the source platform that the exports are permitted and complete. The data owner and the security lead sign off on the mapping before any production import runs.
Common questions about MISP migration and upgrades
Can our team upgrade MISP from 2.4 to 2.5 without outside help?
Yes, many teams can, if they have Linux administration skills, a tested backup and a staging copy of the instance. The MISP project provides an upgrade script for Ubuntu, and it recommends MISP 2.5 with its installer on Ubuntu 24.04. The steps that cause the most trouble are custom modules, sync connections, and database and PHP compatibility. Check the release notes for your exact starting version before you begin, and write a rollback plan that you have rehearsed.
What makes a MISP migration take longer or cost more?
The main drivers are the size of the database and attribute count, the number of sync partners and feeds, and the number of custom modules or SIEM and IDS integrations that must be retested. Cost also rises when the source server is end of life, when the operating system or database changes, or when events come from another threat intelligence platform and need field mapping. Change windows and the number of staff who must validate analyst workflows add time. Ask any quote to itemize these drivers so you can see which ones it assumes.
Do sharing groups and distribution settings survive a MISP rebuild?
They can, but only when the rebuild restores the database and configuration deliberately. Organizations, sharing groups, roles, distribution levels and sync server settings are stored in the instance, so a restore that carries them over keeps them intact. Confirm that event and organization UUIDs, and sync credentials, survive the move, since sync partners may need to accept new keys. Test this in staging by comparing a sample of events, sharing groups and a sync pull before cutover.
What do we need to provide for a MISP migration engagement?
You need a named technical owner, administrator access to the current server, and a current, restorable backup. The engagement also needs an inventory of sync partners, feeds, custom modules and integrations, plus approval for a change window. Analysts or threat intelligence leads should be available to check that sharing and workflows behave as expected after cutover. Agree on these responsibilities in the written scope so that delays in access or review are visible and tracked.
Can a partner take over a live MISP instance safely?
Yes, a partner can take over a live instance, but the handover needs defined access, a read-only review, and a written runbook before any change is made. Typical steps include credential rotation, a parallel run on a copy, and an agreed cutover window. The impact on users and sync partners depends on the design and the change window, so ask for those details in writing rather than assuming the handover is invisible to users. Acceptance criteria should be listed in the scope.
Why do DeployOpen engagements use a fixed-scope written quote?
Most DeployOpen engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. A migration has unknowns such as data volume, custom code and the number of sync partners, so the written scope states those assumptions and the process for a change request if they prove wrong. This gives both sides a clear reference for what is included, what is excluded, and what must be decided first. Ask that the quote list exclusions explicitly.
How DeployOpen runs MISP migrations
DeployOpen plans, builds, documents and supports self-hosted MISP inside your own infrastructure, including moves from MISP 2.4 to 2.5, rebuilds on new servers and imports from other threat intelligence platforms. The work is scoped in writing first so sharing settings and organization data are accounted for before any cutover begins.
How we scope
- The written scope lists which instances, events, attributes, feeds and sync partners are included in the migration or upgrade.
- We inventory organizations, roles, sharing groups and distribution levels so existing sharing settings can be verified after the move.
- Scope names the source platform, target MISP version and the database and web server stack that will be used on the target.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We stand up the target MISP instance in your environment, following the installation method you approve, and test it before any data is moved.
- Source data is exported and imported in stages, with counts and sample records compared against the original instance.
- Sharing settings, sync connections and authentication configuration are rebuilt and checked against the documented inventory.
- Integrations such as SIEM exports, PyMISP scripts and SSO are re-tested on the new instance before cutover is approved.
How we hand over
- You receive runbooks covering the cutover steps, rollback steps and the configuration decisions made during the work.
- Migration evidence, including record counts, validation results and the list of changed settings, is delivered as documentation.
- We walk your administrators through the target instance so they can operate it, check sync status and apply routine updates.
- Open items, such as sync partners that need to reconnect or feeds that need new keys, are recorded with owners named.
How we support
- Ongoing support and upgrades are available as a retainer after handover, covering patching and later MISP release upgrades.
- Retainer scope is agreed in writing and can include testing of upgrades against your modules, feeds and sync partners.
- Support covers the MISP instance and related components in your infrastructure, with the boundaries set out in the agreement.
- Before committing to a support model, confirm with your team how sync partners and feed owners will be notified during maintenance windows.
