The GRC Migration Cutover Checklist

40 items across five phases - the complete sequence for moving a live compliance program between platforms without creating gaps your auditor will find first.

This checklist works for any modern-platform migration (Vanta ↔ Drata) and adapts cleanly to a legacy migration off Archer or spreadsheets. Print it, or work through it phase by phase as you go.

// Phase 1 of 5 - 10 itemsPre-Migration

Export and archive the full source platform.Your insurance policy - the source of truth you'll reference if anything looks wrong later.
Audit evidence storage format - files vs. links.Link-based evidence has no file to transfer. It's consistently the #1 late surprise, discovered mid-migration instead of planned for.
Build a complete integration inventory with owners.Every connector needs someone accountable for reconnecting it - a list nobody owns is a list that gets missed.
Baseline your framework and control count.You need a real number to reconcile against once the migration is done, not a guess.
Notify your auditor of the planned change.Some auditors need 60 or more days to adjust their process - surface this early, not after the fact.
Procure the destination tenant and verify plan tier.Confirm API access, integration limits, and framework coverage before you sign - not after you find the gap.
Build a stakeholder map.Compliance, IT, security, and any framework owners who need visibility or sign-off at each phase.
Select a migration window against the audit calendar.Never inside 90 days of your next audit - the stabilization window alone erodes that runway.
Define rollback criteria before you start.Know in advance what would trigger reverting to the source platform, so it's a decision, not a panic.
Write a communications plan.Who tells whom, and when, as each phase completes - including your auditor and any affected employees.

// Phase 2 of 5 - 10 itemsExecution

Migrate personnel records first.Compliance tasks auto-assign from personnel records, so every later import depends on this being right.
Migrate vendor records.Usually the fastest win in the sequence and rarely blocks anything downstream.
Migrate controls using your mapping document.The intellectual core of the migration - reference your mapping constantly, not from memory.
Migrate policies and re-establish approval workflows.Approval history and timestamps from the source platform don't carry over.
Migrate evidence files last.The most time-intensive step, and the one most likely to derail a timeline if sequenced too early.
Complete a pre-flight review sign-off before going live.A second set of eyes catches mapping errors before they propagate into production.
Run a deduplication verification pass.Imports frequently create near-duplicate records that need merging before they cause reporting noise.
Route policies through formal re-approval.Reviewers need to actively re-approve in the new system - it isn't automatic.
Spot-check evidence-to-control re-association.Verify a real sample, not just that the total count matches.
Confirm personnel compliance tasks auto-assigned correctly.Check that both new hires and existing staff show the expected pending tasks.

// Phase 3 of 5 - 8 itemsStabilization

Reconnect every integration per your inventory.Work the list systematically - this is exactly the step people underestimate and rush.
Hold a 24–48 hour test-settling window before triaging.Early failures are usually sync noise, not real findings. Reviewing too early creates false remediation work.
Triage failing tests after the settling window closes.Separate legitimate findings from configuration artifacts - don't conflate the two.
Manually re-upload link-based evidence.The item most likely to be forgotten if it wasn't explicitly flagged during pre-migration.
Reassign orphaned controls to owners.Imports sometimes drop or blank owner assignments - an unowned control is a control nobody is maintaining.
Verify HRIS sync is pulling current headcount.A stale personnel sync creates false compliance gaps that look like real findings.
Confirm framework-specific test coverage matches the source.Some tests don't have a clean 1:1 equivalent on the new platform - know which ones before your auditor asks.
Document every manual override made during stabilization.Your auditor will ask why a test was overridden - have the answer ready, not reconstructed later.

// Phase 4 of 5 - 7 itemsValidation

Reconcile control counts side-by-side with the source export.The numbers should match, or the gap should be fully explainable.
Verify framework mapping against your original mapping document.Confirm nothing was dropped or misassigned in translation.
Walk the new platform with your auditor.Surface unfamiliarity before fieldwork begins, not during it.
Review the exceptions report.Every control that didn't migrate cleanly needs a documented reason, not a shrug.
Confirm evidence continuity.Every control has evidence attached - a count that adds up is not the same as evidence that actually exists.
Test the destination platform's reporting output.Trust center, audit exports, and dashboards should reflect real, current data before you rely on them.
Get written auditor sign-off that the transition is acceptable.This is your record of record if questions come up later in the audit cycle.

// Phase 5 of 5 - 5 itemsDecommission

Pull a final archive from the source platform.The last complete snapshot before access closes for good.
Confirm contract termination terms in writing.Notice periods and wind-down obligations vary significantly by vendor - get it in writing.
Revoke source platform access for all users.Don't leave stale credentials active on a platform you no longer control.
Check data-retention obligations before deleting anything.Some compliance regimes require 3 to 7 years of record retention - confirm before you assume you can delete.
Write a retro / lessons-learned doc.The next migration - or the next person who inherits this program - benefits from what you learned.