Migrate Phishing Simulation Data: 2026 Switch Guide
How to migrate phishing simulation data when switching platforms in 2026: export steps, risk score gaps, and what compliance evidence to protect.
DefendWise
DefendWise
Switching phishing simulation vendors doesn't have to mean starting your risk data from zero, but most MSPs find out the hard way that it does — because nobody asked for a real export before the old contract ended.
Migrating phishing simulation data when switching platforms means exporting four data sets before the old contract lapses — campaign history, click and report rates, employee risk scores, and training completion records — then mapping each one into the new platform's schema so historical baselines survive the switch. The real gap isn't the export button; it's that most vendors only hand over CSV summaries, not raw timestamped click data, which means the risk trend line breaks clean at the migration date instead of continuing.
TL;DR
- Migrate phishing simulation data by exporting campaign history, click rates, risk scores, and completion records before contract end.
- Most vendors cap exports at summary CSVs — request timestamped raw click data in writing 30-60 days before cancellation.
- Risk score baselines rarely translate between platforms because scoring algorithms differ, so expect a reset unless the new vendor imports raw events.
- Compliance evidence for SOC 2, HIPAA, or cyber insurance needs an unbroken training record — a data gap resets the audit trail.
Why this matters
An MSP switching phishing simulation vendors for 40 subclients isn't just changing a login screen. Every one of those subclients has a risk history tied to compliance evidence — insurance renewal packets, SOC 2 evidence requests, HIPAA audit files — and if that history doesn't move cleanly, the MSP is the one explaining the gap to a client's auditor in 2026, not the vendor that made the export hard.
Before you evaluate anti-phishing software before switching vendors, get the migration question answered in writing. Vendors that stall on export terms are telling you something about lock-in before you've even signed the new contract.
How do you migrate phishing simulation data when switching platforms
The process breaks into six steps, and skipping the audit step is where most migrations go wrong.
- Audit what you actually have — pull a full inventory of campaign logs, click/report timestamps, training completion certificates, and risk scores per subclient before you touch the export tool.
- Request full export 30-60 days before contract end — not at cancellation. Vendors slow-walk export requests once a termination notice is filed.
- Normalize the export format — map user, department, campaign date, click timestamp, and report timestamp into a flat structure the new platform can ingest, not the vendor's proprietary schema.
- Import users and org structure first, then layer in historical campaigns — importing history before the user hierarchy exists causes orphaned records in almost every platform.
- Reconcile risk score baselines — expect a reset unless the receiving platform can recompute scores from raw click events rather than a vendor's pre-calculated number.
- Verify compliance evidence still ties together — confirm training completion dates line up with the audit period your client needs covered, not just the calendar year.
| Data type | Exports cleanly? | Common failure point |
|---|---|---|
| Campaign send/click logs | Usually, as CSV | Missing timestamps, only summary counts |
| Training completion records | Usually | Certificate format doesn't map to new LMS |
| Risk scores | Rarely 1:1 | Proprietary scoring algorithm, no raw data behind it |
| User/org hierarchy | Sometimes | Subclient structure doesn't match new platform's tenancy model |
Campaign history and click-rate data: what actually transfers
Campaign send and click logs are the most portable piece of phishing simulation data, but only if the old vendor exports raw event timestamps rather than aggregated percentages. A CSV that says "12% click rate, Q1 2026" is useless for trend analysis. A CSV with a row per send, per user, per click timestamp, per report timestamp is what lets a new platform rebuild the trend line instead of starting a new one.
Employee risk scores: the hardest data set to migrate
Risk scores are proprietary math, and no two vendors calculate them the same way. Migrating phishing simulation data with an intact risk score is rare — most MSPs end up re-baselining employees in the new platform over the first 60-90 days rather than importing a number that doesn't mean anything under a different formula. The workaround: pull raw click/report events (not the calculated score) and let the new platform recompute the score from source data if it supports that. Vendors that only export the finished score, not the underlying events, are handing you a number with no way to verify or rebuild it.
Training completion records: your compliance evidence trail
Training completion dates are what auditors and cyber insurance underwriters actually ask for, so this data set carries the highest stakes for MSP subclients under SOC 2, HIPAA, or GLBA training obligations. Confirm the export includes completion date, module name, and pass/fail status per user — not just a binary "trained: yes." A completion record without a date range is not evidence of anything in an audit.
Why migration friction varies
Some MSPs migrate a full book of subclients in a weekend. Others spend three months reconciling data because of a handful of predictable friction points:
- Vendor export restrictions — some platforms cap exports to summary reports and require a support ticket for raw data, which slows everything down near a contract deadline.
- Proprietary risk-scoring algorithms — a score computed one way rarely means the same thing on a different platform, forcing a re-baseline.
- Multi-tenant structure mismatches — an MSP's subclient hierarchy in the old platform may not map cleanly to how the new platform organizes tenants and users.
- Compliance framework differences — evidence formatted for PCI DSS doesn't automatically satisfy a HIPAA or NYDFS training requirement, even with the same underlying data.
- Timing — migrating mid-contract under time pressure produces worse data quality than migrating at a planned renewal window.
- Format incompatibility — CSV column naming, date formats, and user identifiers (email vs. employee ID) rarely match without manual cleanup.
MSPs handling this at scale should vet phishing simulation vendors during a security RFP and put data export terms in writing before signing, not after the migration is already underway.
Can you export phishing simulation data as CSV?
Most vendors support CSV export, but the level of detail varies sharply — some give raw per-event data with timestamps, others only hand over aggregated monthly percentages. Ask specifically for click timestamp, report timestamp, and user identifier columns before assuming a CSV export will support a clean migration.
Do you lose historical click-rate data when switching vendors?
You lose the trend continuity, not necessarily the raw numbers, if the old vendor exports full event-level data rather than summary stats. The click rate for March 2026 still happened; the question is whether the new platform can plot it on the same timeline as data collected after the switch.
How long should you keep phishing simulation records after migration?
Keep exported records for at least the length of your longest compliance obligation — often 12-24 months for SOC 2 or cyber insurance renewal cycles, longer for HIPAA. Store the raw export independently of both platforms so an audit request doesn't depend on either vendor still having the data.
MSPs rebuilding risk baselines after a migration often lean on employee risk scores built from phishing simulation data rather than trying to force an old score to carry over. A flat-fee platform like DefendWise removes one variable from this whole process: because pricing isn't tied to seat count, MSPs aren't renegotiating per-user costs at the same time they're reconciling historical data — the migration stays a data problem, not a billing problem.
Migrate your subclients without losing risk history
One flat fee, unlimited seats, no per-user renegotiation mid-migration.
FAQ
What data should you export before switching phishing simulation platforms?
Export campaign send/click logs with timestamps, training completion records with dates, employee risk scores (and the raw events behind them), and your org/subclient user hierarchy. A summary report with no timestamps or raw events is not enough to rebuild a trend line in the new platform.
Is migrating phishing simulation data difficult for MSPs with multiple subclients?
Yes, difficulty scales with subclient count because each subclient's data has to map into the new platform's tenancy structure separately. An MSP with 40 subclients needs a repeatable export-and-import process, not a one-off manual migration.
How much notice should you give a vendor before requesting a data export?
Give 30-60 days notice before contract end. Vendors slow-walk export requests once a cancellation notice is filed, and some require a support ticket for raw event-level data rather than summary CSVs.
Do employee risk scores transfer between phishing simulation platforms?
Risk scores rarely transfer 1:1 because each vendor calculates them with a different formula. The workaround is exporting the raw click and report events, not the finished score, so the new platform can recompute a baseline from source data.
What happens to compliance evidence during a platform migration?
Compliance evidence (SOC 2, HIPAA, PCI DSS, cyber insurance) depends on unbroken training completion records. If the export is missing dates or module names, the audit trail has a gap starting at the migration date, regardless of how good the new platform is.
Can you migrate phishing simulation data mid-contract instead of waiting for renewal?
Yes, but mid-contract migrations under time pressure produce worse data quality than migrations planned around a renewal window, since vendors have less incentive to prioritize the export request.
Should MSPs keep a copy of exported phishing simulation data independent of both platforms?
Yes, store the raw export separately from both the old and new vendor systems. This protects against an audit request landing after the old vendor has deleted the account or the new platform hasn't finished ingesting the historical data.
One last thing
The detail that trips up most migrations isn't the click rate or the training record — it's the user identifier column. Old platforms often key records by internal employee ID; new platforms key by email address. If nobody maps that column before import, half the historical records land as orphaned users with no name attached, and the MSP finds out during the next compliance review, not during the migration itself.