Methodology: built from ServiceNow, Atlassian, Freshservice, Zendesk and BMC Helix documentation, checked on 13 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A test migration should prove, on your own data, that counts reconcile, links and attachments survive, original dates and authors are kept, internal notes stay internal, and a delta sync works under cutover conditions. If a provider can't prove that before you sign, the contract is buying a promise. This test migration checklist is for the ITSM platform owner with a preferred provider and a statement of work waiting: what to test, pass/fail criteria, who signs off, and what goes in the contract.
Key takeaways
- Atlassian says it "strongly recommend[s] performing a trial run" before a Data Center to Cloud migration (Atlassian Support, as of 13 Oct 2026).
- Jira Cloud's CSV importer makes every imported comment public in a Jira Service Management space (Atlassian Support, as of 13 Oct 2026).
- Zendesk says "metrics and SLAs are not supported for imported tickets" (Zendesk developer docs, as of 13 Oct 2026).
- Freshservice's Bulk API rejects an attachment over 40 MB but still creates the ticket (Freshservice support article modified 24 Nov 2025, checked 13 Oct 2026).
- Workflows, automations, business rules, SLA definitions, macros and running SLA timers are rebuilt on the target, not migrated. The test proves your history arrives as data, not that those rules moved.
Demo migration vs test migration
A demo migration proves a connector runs. A test migration proves the provider can handle your hardest records, judged by criteria you wrote. Freshworks describes the demo phase of a ServiceNow to Freshservice move as one that "uses sample data to test mapping rules" (Freshworks, as of 13 Oct 2026). Useful, but when the provider picks the sample, the provider also defines success. Before you sign, reverse that. Three conditions make a test worth signing on:
- Same tooling, mapping and settings as the production run.
- A copy of real production data in a non-production target. Atlassian suggests a trial site, with Premium or Enterprise if you want a sandbox (Atlassian Support, as of 13 Oct 2026).
- Source counts frozen before the run, so there is a fixed number to reconcile against.
Build a test sample that can fail
A random sample reflects your typical records. The test needs your unusual ones, because the edge cases are what you pay a provider to handle. There is no public benchmark for sample size, and we don't suggest one. Every risky shape should appear at least once:
- the oldest records in scope, and every year you plan to move
- incidents linked to problems, changes linked to CIs, parent and child tickets
- long comment threads with mixed public and internal notes, inline images and large attachments
- requesters and agents who have left
- every status, including pending states that pause SLAs
- custom fields, multi-select values and non-English text
List the sample by record ID before the run, so a hard record can't be swapped for an easy one.
Proofs about the data: counts, links and attachments
1. Record counts reconcile
Compare counts by record type, state and year, never as one grand total, which can match while one year is missing and duplicates fill the gap. Every difference goes into an exceptions log with a reason. An unexplained difference is a fail.
Ask for the failed-record list too. Freshservice's Bulk API guide says its errors "cannot be retried automatically" (Freshservice support, as of 13 Oct 2026). A provider that can't show which records failed can't show they were fixed.
2. Relationships survive, in both directions
Open sampled incidents and confirm problem, change and CI links point to migrated records, not text. ServiceNow warns that when a transform map hits a reference that doesn't exist, the raw sys_id can appear in the target record as the display value (ServiceNow docs, as of 13 Oct 2026). The field is filled, but the link goes nowhere. Check from the other end too, and check CI relationship direction.
3. Attachments arrive, open, and sit on the right record
Count attachments per sampled record on both sides, open a handful, then test the limits. A Freshservice attachment over 40 MB is rejected while the ticket is still created: the ticket count reconciles and the evidence is gone. Ask the provider to show you what happens to an over-limit file on your target, and confirm inline images load from the new platform, not the old instance.
Proofs about meaning: dates, people, notes and SLA data
4. Original timestamps are kept
Opened, resolved and closed dates, and each comment's original time, must survive. If they reset to the load date, every aging report and audit query breaks. Import paths differ here (see the table below), so "dates are preserved" is not an answer. Ask which field holds the original date on your target, then check it on sampled records.
5. The right people own the right records
Requester, assignee, group and comment author should map to real user records, including leavers. Comments should show their original authors, not the integration account.
6. Internal notes stay internal
This is the highest-stakes check. An internal note exposed to requesters can reveal a security incident or an HR matter. Jira Cloud's CSV importer makes all imported comments public in a JSM space, and in ServiceNow everyone who can view an incident sees its additional comments, while work note notifications go only to users on the work notes list (vendor docs, as of 13 Oct 2026). So internal notes from the source must land in work notes, never in additional comments. Test it as a requester: log in to the portal as a sampled requester and confirm no internal note is visible.
7. SLA history arrives as data, not as live timers
SLA definitions and timers are rebuilt. What you can test is whether historic outcomes arrive as reportable data without being recalculated wrongly. Atlassian documents that SLAs keep counting on CSV-imported closed issues, because an imported issue's history holds only a creation event (Atlassian KB, updated 26 Sep 2025). Pass means closed history shows no running clocks and outcomes sit in a reportable field.
What each platform's import path keeps or resets
The import path decides what your test migration can prove. Ask the provider which one they will use.
| Target and path | Original dates | Internal vs public notes | Attachments | Limits and side effects |
|---|---|---|---|---|
| ServiceNow Table API and import sets | sys_ fields are auto-generated and can't be updated via the Table API; ask where originals go | Additional comments visible to everyone who can view the incident; internal notes belong in work notes | 1,024 MB default maximum | Unresolved references can show a raw sys_id as the display value; coalesce decides update or insert on re-runs |
| Jira Service Management Cloud, CSV import | Date Created column, format set in the wizard | All imported comments become public | 1 GB default, up to 2 GB per file; URLs must be reachable | About 1,500 work items per file, about an hour each (Atlassian estimate); closed imports keep counting SLAs |
| Jira Cloud and JSM REST APIs | Not addressed in the docs we read; check on samples | Per-comment public or internal flag | Same site limits | Points-based, 65,000 points an hour global pool; 20 writes per 2 seconds and 100 per 30 seconds on one work item |
| Freshservice public and Bulk APIs | created_at described only as "Ticket creation timestamp"; Bulk guide silent | Notes carry a private attribute | 40 MB per ticket or entity; over-limit file rejected, ticket kept | requester_id or email required; Bulk limits marked "[To be confirmed post load testing]"; workflows and business rules not muted |
| Zendesk Ticket Import API | created_at, updated_at, solved_at and per-comment created_at settable | public: false per comment | Not stated on the import page | Up to 100 tickets per bulk request; metrics and SLAs not supported for imported tickets |
Sources: ServiceNow, Atlassian, Freshservice and Zendesk documentation, checked 13 Oct 2026.
Prove the run: throughput and the delta-sync rehearsal
Throughput
Time the test load end to end. The observed rate, scaled to your volume, tells you whether the full load fits your plan. Published limits alone can't: Freshservice marks its Bulk API limits as unconfirmed, and Atlassian's per-work-item write cap slows a long comment thread more than a short ticket (vendor docs, as of 13 Oct 2026). Ask for records per hour by type, throttled requests, and a written projection with its assumptions.
The delta-sync rehearsal
The bulk load runs before cutover. The delta runs inside your freeze window, so rehearse it. BMC Helix's own Remedy to BMC Helix SaaS process includes a "Delta Data Migration (Emulated cutover 1)" stage and a second emulated cutover before go-live (BMC Helix docs, as of 13 Oct 2026).
After the test load, change the source on purpose: new tickets, public and internal comments, status changes, attachments, one closure, one reopen. Run the delta and prove:
- Every change arrives exactly once. In ServiceNow, with no coalesce field "all imported rows are treated as new records" (ServiceNow docs).
- Changes are found reliably. Freshservice's List All Tickets returns only the past 30 days by default; older tickets need updated_since (Freshservice API docs, as of 13 Oct 2026).
- The delta fits the freeze window, measured, not estimated.
- A re-run is safe. Atlassian's migration assistant does not overwrite data already in the Cloud site (Atlassian Support). Ask how a failed delta is repeated.
- No requester gets an email. Zendesk says notifications are sent on updates after import, and Freshservice doesn't mute workflows during Bulk API loads. A delta is an update.
Test migration checklist: pass/fail criteria
These are our recommended checks, not an industry benchmark; no public standard sets pass thresholds for ITSM test migrations. Anything short of "pass" is logged as a defect and fixed before the full load.
| # | Check | How to test | Pass | Fail | Owner |
|---|---|---|---|---|---|
| 1 | Counts | By type, state and year vs frozen source | Every difference explained | Any unexplained difference | Platform owner, provider |
| 2 | Failed records | Review failed-record list | Each failure has reason and fix | Success totals only | Provider |
| 3 | Relationships | Open links from both ends | Resolve to migrated records | Text, one-way or orphaned | Process owners |
| 4 | Attachments | Count, open, inline images | Match, open, load from target | Missing or silently rejected | Service desk lead |
| 5 | Timestamps | Compare dates on samples | Originals in agreed field | Load date as created date | Reporting owner |
| 6 | People | Requester, assignee, author, leavers | Real users or agreed rule | Integration account as author | Service desk lead |
| 7 | Internal notes | Portal login as requester | None visible | Any visible | Security or compliance |
| 8 | SLA data | Closed historic tickets | No running clocks; outcomes reportable | Clocks running on history | Reporting owner |
| 9 | Throughput | Timed run | Written projection fits plan | Estimate, no measured rate | Platform owner |
| 10 | Delta rehearsal | Change, delta, recount | Once, inside window, no emails | Duplicates, misses, notifications | Platform owner, provider |
| 11 | Repeatability | Re-run on clean target | Same results | Different counts | Provider |
Who signs off the test migration
Sign-off is a signed reconciliation report, exceptions log and defect list, with every defect closed or accepted in writing. An email saying "looks good" is not sign-off.
| Role | Signs for |
|---|---|
| ITSM platform owner | Overall acceptance |
| Process owners (incident, problem, change, knowledge) | Sample review and relationships in their area |
| Service desk lead | Agent use of migrated records, people mapping |
| Security, privacy or compliance | Internal notes and test-data handling |
| Reporting owner | Timestamps and SLA history |
| Provider's migration lead | Co-signs reconciliation report and exceptions log |
Atlassian suggests inviting every major user type to acceptance testing and running it again after the production migration (Atlassian Support, as of 13 Oct 2026). Plan two signatures: test, then production.
Put the test migration into the contract
A test migration only protects you if the contract depends on it. Before you sign, the statement of work should include:
- The test migration before signature, or as a first milestone the rest of the contract depends on.
- Your sample list, by record ID, and the pass/fail table as acceptance criteria.
- The same tooling, mapping and configuration for test and production.
- How many re-runs are included, and who pays for more.
- A delta-sync rehearsal measured against your freeze window.
- Deletion of the test copy afterwards.
- A separate rebuild scope for workflows, automations, business rules, SLA definitions and macros.
FAQ
Methodology
We built this test migration checklist from ServiceNow, Atlassian, Freshservice, Zendesk and BMC Helix documentation read on 13 Oct 2026, focusing on what each import path does to dates, comment visibility, attachments and rate limits. The pass/fail criteria are our recommendations, not an industry standard. We did not run hands-on tests.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.