Choose a migration treatment for each record class; do not accept “CSV migration included” as a complete scope. An implementation-provider webinar from Edgile explicitly includes historical fields, attachments, custom legacy applications and configuration-versus-customisation decisions in its migration agenda. This is useful delivery context, but it is vendor-side material rather than an independent success-rate study. (edgile.com)
| Migration approach | When to evaluate it | Main question to resolve | Required acceptance test |
|---|---|---|---|
| Lift and shift | Existing definitions and records are sufficiently reliable | Are you preserving useful history or reproducing defects? | Reconcile records, relationships, attachments and permissions against the source |
| Cleanse and redesign before import | Duplicate controls, incompatible scoring or missing ownership are material | Who approves merges, exclusions and changed meanings? | Trace every transformed record to its source and approved rule |
| Current-state migration plus historical archive | Live workflows and historical records need different treatment | Can historical evidence remain accessible and defensible? | Retrieve a complete prior-period assessment without the old production application |
| Phased coexistence | Several business units or specialist systems cannot move together | Which system is authoritative during each phase? | Reconcile one reporting period while workflows span both systems |
What belongs in the GRC data migration checklist?
For each object, require a decision on:
- Stable source and target identifiers.
- Owner, legal entity, business unit and access classification.
- Relationships among obligations, risks, controls, tests, evidence and findings.
- Original timestamps and the distinction between imported history and new platform events.
- Attachments, versions, comments, approvals and rejected submissions.
- Active, closed, superseded and deleted records.
- Retention, legal holds, archive access and permitted disposal.
- Transformation rules, reconciliation tolerances and signed acceptance.
For how to move from spreadsheets to GRC software, the recommended first deliverable is a data dictionary and ownership decision—not a bulk upload. For incumbent replacement, add a configuration inventory and historical-evidence retrieval test.
IBM documents object-and-relationship CSV exports, but that description alone does not establish a complete package of attachments, configuration and audit history. Our recommended exit test therefore goes further: reconstruct a representative assurance case outside the source platform and document what is missing. (ibm.com)
Sources cited on this page
- edgile.com ↗edgile.com
- ibm.com ↗www.ibm.com