Create a controlled source inventory and preserve the original data before deduplicating anything. Your first migration deliverable should be a defensible mapping, not a cleaned spreadsheet with no record of what changed.
What should the GRC data migration checklist cover?
Inventory each source separately:
- Spreadsheets and local databases.
- Existing GRC modules.
- Document and evidence repositories.
- Ticketing and remediation systems.
- Identity and organisational reference data.
- Regulatory-content libraries.
- Reporting extracts and archived committee packs.
For every source, record its business owner, technical custodian, extraction method, record volume, attachment volume, sensitivity, update frequency, retention treatment and known quality problems. Record extraction dates and preserve a read-only original.
What target data structure should you propose?
Use this as a vendor-neutral starting model, then map it to the selected product’s supported design.
| Object | Minimum proposed fields | Relationships to preserve |
|---|---|---|
| Entity | Stable ID, type, name, parent, owner, active dates | Processes, services, applications and legal entities |
| Obligation | Authority, citation, version, effective date, applicability owner | Policies, control objectives and entities |
| Risk | Stable ID, statement, category, owner, entity, assessment date, methodology version | Assessments, controls, events and actions |
| Control objective | Stable ID, intended outcome, scope and version | Obligations and control implementations |
| Control implementation | ID, objective, entity, operator, reviewer, frequency and status | Evidence, tests, exceptions and findings |
| Test or assessment | Period, procedure, performer, reviewer, outcome and approval | The version of the object assessed and its evidence |
| Evidence | ID, source, file or reference, period, classification and custodian | Relevant tests and controls, with access restrictions |
| Finding or issue | ID, description, severity, origin, owner and status | Controls, risks, tests and remediation |
| Action or exception | Owner, approver, due or expiry date, rationale and closure evidence | Finding, control or risk |
How should you handle duplicates and local variants?
Do not merge records solely because their titles match. Compare the activity, entity, owner, frequency, population, procedure and evidence.
Synthetic example:
| Source record | Proposed treatment | Reason |
|---|---|---|
| Access review — Retail — quarterly | Retain local implementation | Local population and owner |
| Access review — Insurance — quarterly | Retain local implementation under the same objective | Similar purpose, different execution |
| Duplicate of Retail record with the same population and period | Merge only after owner approval | Possible duplicate, requiring confirmation |
| Central identity-service review relied on by both entities | Model shared ownership and reliance separately | A centrally operated control is not the same as two locally operated controls |
ServiceNow’s Australia documentation explicitly supports common controls and reliant entities. It also notes that, for the described risk-control relationships, only active relationships are maintained and historical ones are removed. That is a reason to test point-in-time reporting and retained history in the proposed configuration—not to assume that a current relationship view is a historical record. (servicenow.com)
For risk ratings, preserve the original value, scale and assessment date. Do not convert every legacy “high” into one new numeric value without an approved mapping and a record of the transformation.
How do you migrate audit evidence and control history?
Choose a treatment for each record class:
- Migrate as active records: items needed for ongoing work.
- Migrate as historical records: material needed inside the new workflow or reporting model.
- Retain in a controlled archive: material that must remain retrievable but need not be recreated as live transactions.
- Dispose under an approved schedule: only after retention and legal-hold checks.
Keep source IDs and original dates separately from new-system creation metadata. Require a historical retrieval demonstration before accepting the archive strategy.
IBM’s OpenPages 9.1 FastMap documentation illustrates why this matters: FastMap does not import attachments or signatures, and it cannot preserve system creation-date information through that process. These are limitations of that import route, not proof that OpenPages has no other migration options. (ibm.com)
For HIPAA Security Rule documentation, HHS states that required documentation must be retained until six years after creation or the date it was last in effect, whichever is later. Do not turn that into an unsupported six-year rule for every record or technical log in the organisation. (hhs.gov)
What evidence proves migration readiness?
Create a defect register containing source record, defect, business consequence, treatment, owner, due date and approval. Suggested pre-contract checks are:
- Stable IDs exist or can be assigned repeatably.
- Critical records have confirmed owners.
- Parent-child and many-to-many relationships are understood.
- Attachment extraction has been tested.
- Historical treatment has been approved.
- Restricted evidence has a target access design.
- A sample can be loaded, reconciled and exported again.
A sample proves only what was tested. Use deliberately difficult records—missing owners, long text, reopened findings, inherited controls and restricted attachments—rather than only clean rows.
Exit gate: the team can explain what will move, what will remain archived, what will change and how each decision will be reconciled.
Sources cited on this page
- servicenow.com ↗www.servicenow.com
- ibm.com ↗www.ibm.com
- hhs.gov ↗www.hhs.gov