ITSM Migration Partners: Scope the Data Left Behind
A migration can finish with every destination test passed and still leave the client unable to retrieve an old ticket. The reason is simple: nobody was assigned the data outside the migration scope. As a delivery partner, raise that decision in discovery and give it an owner before the SOW is signed.
Why the migration SOW leaves a gap
A migration SOW is built around the destination: active tickets, current configuration, live integrations, users, and the recent history the new platform needs. That is sensible. Moving every historical record can increase mapping effort, cutover time, testing, and cost without helping the destination run.
Closed incidents can explain a recurring fault. An approval may be needed to reconstruct a change decision. Ask the client which records it still uses or must retain, and let its records and legal owners set the period. Record the answer in discovery rather than assuming a standard number of years.
Make the boundary clear before go-live
Consider a client asking for a change approval and its attachment six months after cutover. This is an illustrative handover test: can the service desk find both without the old platform or the migration consultant? If the answer depends on someone rebuilding the record, the operating model needs more work.
Compare each option against that test. A CSV can work for a small, simple dataset if it carries the required context and has an agreed retrieval process. Keeping the source live can work too, with ongoing licensing, security and support costs. Show the client the scope and cost of each workable option.
Add these questions to discovery
- Which source platforms, versions and instance owners are involved?
- Which tables, record categories, attachments and time periods are excluded from the live migration?
- Who approves retention, legal holds and disposal for each category?
- Who will retrieve records after handover, and what output will they need?
- Who owns extraction, storage, encryption, backup and failed-record resolution?
- Which reconciliation, attachment, access and retrieval checks define acceptance?
- What is the last source-access date, and how much time remains for testing and fixes?
Make the historical workstream explicit
Give each workstream a named client owner and delivery owner. The following split makes the handover visible:
- Migration: the delivery team moves the agreed data and configuration; the destination service owner accepts the live service.
- Historical records: the data lead delivers the retained scope, mappings and exception report; the records owner accepts retrieval against the approved requirements.
- Decommissioning: the platform owner coordinates access and shutdown; the accountable client owner signs off after migration and retained-history acceptance.
Use both dataset reconciliation and record tests. Report expected, delivered and failed counts for the same extraction scope. Check attachments and related records, then ask intended users to retrieve difficult examples. Agree retrieval-time targets with the client and record actual results. A sample proves those examples work; it does not prove the entire export is complete.
Where Cortex Archive fits for partners
Cortex Archive provides a self-hosted interface to supported historical ITSM data, including ServiceNow, Cherwell, Ivanti Neurons for ITSM and Jira Service Management Data Center. Users can search and browse supported records. The source database can use read-only credentials, with Cortex configuration stored separately. Scope against the client’s actual data and the product version you will deploy. For JSM Data Center, validate custom fields, Assets, issue-security requirements and large change histories.
For ServiceNow, Cortex 3.2.0 release notes describe a Sync Utility for acquiring exports via API. The extraction report and record tests still need to demonstrate what the delivery contains.
Synapse’s partner offering can support this historical-access workstream. Agree who performs extraction, configures the archive, resolves data gaps and handles support after go-live. Confirm any commercial terms directly with Synapse.
What good handoff looks like
Hand over the approved record inventory, retention decisions, source and archive configuration, extraction report, accepted gaps and test evidence. Add operating instructions: who grants access, investigates a missing record, restores a backup and authorizes disposal. Have that team perform a retrieval and recovery exercise before the project closes.
Frequently Asked Questions
Should the migration partner migrate every historical ITSM record?
Not necessarily. Move what the destination needs and preserve what the organization must retain or still expects to use. The key is to make the decision explicit and validated rather than leaving it to the decommissioning team.
Is a CSV export enough for historical ITSM data?
Sometimes for a narrowly defined use case. It is usually weak when users need relationships, readable reference values, comments, attachments, or record-level context. Test the required retrieval scenario before accepting a flat export.
Who sets the retention period?
The client does, with input from records, compliance, legal, security, and the relevant business owner. A migration partner can facilitate the inventory but should not prescribe a universal period.
Who owns extraction and archive acceptance?
Name both roles in the SOW. A delivery or data lead should own extraction and reconciliation; the client’s accountable records or business owner should accept the result. The team operating the archive needs the configuration, evidence and recovery instructions before handover.
How should partners handle access across clients or business units?
Define the permitted record scope for each user group and test allowed and denied access. Verify that search results, attachments and exports respect those boundaries. Signing in successfully proves identity; it does not prove every record-level restriction has been reproduced.
When should the historical workstream start?
During discovery, before the SOW is signed. Source access, extraction, validation, and approvals become harder once decommissioning is underway.
Scoping historical access for a client? Review Cortex Archive for MSPs and migration teams and bring the retained-data scope into discovery.