The artifacts that disappear the day you serve notice are not in your contract — they live in your incumbent's platform, and retrieving them is a race with a hard deadline.
A critical assumption before you read further
This brief addresses migrations where the incumbent MDR provider operates out of their own proprietary platform — meaning your alert history, investigation narratives, suppression tuning, and detection logic live in infrastructure they own and control. If your MDR provider instead connects to and operates out of a platform you own, most of the extraction challenges described here do not apply in the same way: you retain custody of the data and configuration by default. Confirm which model you are operating under before treating this guidance as applicable to your situation.
What makes a provider migration different from an onboarding
Bringing on an MDR provider when you have no incumbent is a standard onboarding challenge. A migration is an entirely different problem. Migration is an extraction under a closing window: the incumbent controls the platform where your alert history, investigation narratives, suppression tuning, and contextual enrichment currently live, and their commercial incentive to make retrieval easy diminishes the moment notice is given.
The non-obvious point is that the irreplaceable artifacts are not your logs — they are your interpreted environment. The detection logic has been tuned against your noise floor. Analyst notes describe the specific behavior of your specific user population. Suppression rules encode months of decisions about what your environment generates that is not a threat. None of that transfers automatically, and your incoming provider cannot reconstruct it from raw telemetry.
Leaders often treat migration as a vendor swap and underestimate the institutional knowledge problem. The consequence is that the incoming provider starts cold in an environment the outgoing provider spent months learning, and that gap is measured in detection latency during the period when your environment is most exposed.
Extracting evidence and detection content from the incumbent
Migration portability table
| Artifact | Why it matters after cutover | Extraction difficulty | What to secure before notice is given |
|---|---|---|---|
| Historical alert and incident records | Required for trend analysis, regulatory audit, and ongoing investigation continuity | High — often locked in proprietary case management with no export API | Request bulk export in a structured format (JSON, CSV); confirm field completeness before notice |
| Investigation narratives and analyst notes | Encode environment-specific context that cannot be reconstructed from telemetry alone | Very high — frequently stored as free text in closed platforms with no structured export | Request written summaries of all open and recently closed cases; assign analyst time to manual transcription if needed |
| Custom detection logic | Directly determines what the incoming provider can fire from day one | Medium — rules may be exportable but written in a platform-specific language requiring translation | Request logic in its native syntax; document intent separately so it can be re-implemented in the new platform's language |
| Tuning and suppression state | Defines the known-good baseline; without it, the incoming provider operates with high false-positive volume | High — suppression lists are often implicit in platform configuration rather than explicit rule sets | Document every active suppression with the business justification that drove it; treat this as a configuration export |
| Raw or retained telemetry | Required for retrospective hunting and to satisfy retention obligations under regulatory frameworks | Variable — depends on whether the MDR contract includes raw log custody or only processed alerts | Confirm custody terms before notice; if logs are provider-held, initiate transfer or archive to your own storage immediately |
| Asset and identity context built during the relationship | Asset criticality tagging, identity-to-role mappings, and environment segmentation context inform triage and priority | Medium — often embedded in platform enrichment rather than exportable asset inventory | Export all enrichment tables and asset tagging in a portable format; cross-reference against your own CMDB and IAM records |
The extraction deadline is not your contract end date — it is the moment notice creates an adversarial dynamic. Where your contract terms permit, initiating export requests before formal notice may preserve some leverage, but most MDR providers will recognize what a systematic export request signals regardless of whether formal notice has been given. Do not assume pre-notice requests will go unnoticed; plan your extraction timeline accordingly and verify completeness as quickly as possible once initiated.
A note on platform ownership as a migration risk control
If you are planning a migration and have flexibility in how you structure the incoming engagement, this is the point at which platform ownership deserves direct consideration. An MDR provider that operates out of a platform you own — where your organization holds the license, the data, and the configuration — eliminates the extraction problem described throughout this brief. Detection logic, suppression tuning, investigation history, and telemetry remain in your custody by default.
The operational tradeoff is that platform ownership typically requires more internal capability to manage, and not all MDR providers support this model. But for organizations that have been through a provider migration and experienced the extraction friction firsthand, shifting to a customer-owned platform model is the structural fix that prevents the same problem from recurring. Evaluate this alongside provider selection, not after a new contract is signed.
Running two providers at once
Dual-provider overlap is the only state in which you can validate the incoming provider's detection fidelity against a known baseline. The tradeoff is direct: overlap costs more and creates coordination complexity, but a hard cutover without overlap means the incoming provider's first weeks in production are also the period of highest detection uncertainty.
It is also worth stating plainly that running two MDR providers concurrently is not always operationally feasible. If your telemetry architecture does not support splitting or duplicating log streams to two separate platforms simultaneously, a true side-by-side overlap may not be achievable without infrastructure changes. Confirm whether your logging pipeline supports dual-feed before structuring a migration plan that depends on it.
Where overlap is feasible, both providers will generate alerts from the same telemetry stream. Without explicit deconfliction, you get duplicated tickets, competing escalation paths, and analyst time consumed by reconciliation. The operational control is a written authority matrix that specifies which provider owns triage, escalation, and containment for which asset classes or detection categories during the overlap window.
NIST SP 800-137 requires that an ISCM strategy explicitly assign who monitors what, at what frequency, and who acts on the output — leaving that implicit during a dual-provider state creates the exact accountability gap the framework targets. (Source: NIST SP 800-137, Information Security Continuous Monitoring ISCM, https://csrc.nist.gov/pubs/sp/800/137/final)
The incoming provider should not take containment authority over production systems until you have confirmed they can correctly classify your environment's known-good behavior — that is, until their false-positive rate on tuned content reaches a level you have defined in advance. What that threshold is depends on your environment's noise characteristics and your tolerance for delayed response; name the number before overlap starts, not during it.
Authority and continuity during cutover
In-flight cases at the cutover moment are a continuity-of-authority problem, not an investigation handoff craft problem. The operational question here is: who holds authority to contain, communicate, and close a case that opened under the incumbent and carries over to the incoming provider?
NIST SP 800-61 Rev. 3 frames incident response as a continuous capability defined by preparation — specifically by whether roles, coordination paths, and evidence-handling procedures are documented before they are needed, not at the moment they are needed. (Source: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations, https://csrc.nist.gov/pubs/sp/800/61/r3/final) A case that transfers between providers at cutover without documented authority is exactly the scenario that preparation is supposed to prevent. The consequence of ambiguity is not just friction — it is a window where an active incident can stall because neither provider is certain they have authority to act.
Your cutover runbook should name the following before the authority transition date: who holds containment authority for each open case; how investigation handoff is documented in writing; what escalation path your internal team uses if both providers are unresponsive; and at what point the incoming provider assumes unilateral authority.
NIST CSF 2.0's GOVERN function makes accountability assignment a first-class control outcome. (Source: NIST Cybersecurity Framework CSF 2.0, https://www.nist.gov/cyberframework) Treat the cutover authority matrix as a GOVERN deliverable, not an operational afterthought.
The coverage gap you are actually managing
A zero-gap migration is not achievable in most environments by default. The gap's size is determined by four factors: how completely you extracted the incumbent's tuning state; how much environment context you transferred in a form the incoming provider can act on; how long the overlap window runs; and how quickly the incoming provider can tune to your noise floor using the transferred artifacts.
The gap is acceptable — not eliminated — when you can define its boundaries. That means knowing which detection categories are covered from day one by transferred logic, which categories the incoming provider will cover with generic content while tuning progresses, and which categories have no coverage during the transition. That last category is your residual risk, and it should drive compensating controls: elevated logging verbosity, increased internal analyst attention, or temporary restrictions on high-risk activity during the gap window.
For telemetry depth and retention considerations that affect what the incoming provider can detect from the endpoint side. What determines acceptable coverage here is not the incoming provider's capability in isolation — it is that capability applied to the specific state of your transferred artifacts, your environment's complexity, and the length of time you can sustain overlap.
Sources
- NIST SP 800-137, Information Security Continuous Monitoring (ISCM): https://csrc.nist.gov/pubs/sp/800/137/final
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations: https://csrc.nist.gov/pubs/sp/800/61/r3/final
- NIST Cybersecurity Framework (CSF) 2.0: https://www.nist.gov/cyberframework
