# Gate 2: Can we migrate, connect and eventually leave?

**Test representative records and dependencies before asking anyone to stand behind a migration price.** Separate data cleansing, transformation, import, historical retention and validation in the implementation scope.

KPMG’s implementation guidance explicitly distinguishes data rationalisation and cleansing from migration strategy. Its inclusion of testing and post-production support is also a useful reminder to avoid treating migration as a file-upload task. ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

### What belongs in a GRC data migration checklist?

| Area | What to inspect | Evidence to retain |
|---|---|---|
| Identity | Duplicate identifiers, conflicting names and records appearing in multiple repositories | A source-to-target identifier crosswalk |
| Ownership | Missing owners, departed employees, shared mailboxes and ambiguous business-unit responsibility | An approved ownership register |
| Relationships | Risk-to-control, control-to-test, finding-to-action and entity relationships | Reconciled relationship counts and exception reports |
| Historical records | Original dates, authors, approvals, changes and closed findings | An agreed history-preservation or archive design |
| Evidence | Actual files versus links, versions, classification and access restrictions | A file manifest and retrieval test |
| Disposition | Records to migrate, merge, archive, exclude or reject | An approved, mutually exclusive disposition ledger |

### What should the readiness checklist contain?

- [ ] Select representative examples across workflows, entities, permissions and record ages—not only clean records.
- [ ] Use synthetic or properly redacted material for external testing; exclude credentials, patient information and identifiable sensitive findings.
- [ ] Assign every sampled source record a disposition and retain the mapping where several records become one.
- [ ] Identify who resolves duplicates and taxonomy conflicts; do not let an import script silently make those decisions.
- [ ] Preserve original event information without presenting imported history as activity generated natively by the new platform.
- [ ] Test attachments and historical retrieval independently of the main record import.
- [ ] Document each integration’s source of truth, supported objects, direction, frequency, authentication, failure handling and maintenance owner.
- [ ] Agree how the full dataset will be profiled and reconciled after the sample exercise.

**A sample establishes observed defects and testable hypotheses. It does not certify the entire estate.**

### Why should we test exit before purchase?

Because the export mechanisms need examining individually. For example, LogicGate documents that its CSV and XLSX table exports contain attachment names rather than the files themselves; bulk attachments use a separate ZIP download. It also documents an API for retrieving record audit events. Those are distinct capabilities to validate—not evidence that one export reconstructs the whole environment. ([help.logicgate.com](https://help.logicgate.com/hc/en-us/articles/4402683131668-Export-Data-from-Table-Reports))

Require a portability demonstration covering records, relationships, files, relevant history and configuration documentation. Ask an administrator to reconstruct a sample outside the platform and explain any missing context.

**Output:** migration backlog, data crosswalk, integration dependency register and export test report.

**Proceed when:** unresolved work has an owner, an estimation basis and an agreed treatment in the statement of work.

**Hold when:** the proposal says only that migration or integrations are included, without defining objects, volumes, responsibilities and acceptance evidence.