Moving from ServiceNow to Jira Service Management is less about copying tickets and more about deciding what your service operation should look like afterward. For teams in banking, healthcare, and government, it also has to survive an audit. This 90-day plan is how we sequence the work so the cutover is quiet and the evidence trail stays intact.
Before day one: decide what you are actually moving
Inventory every ServiceNow module in use: incident, problem, change, request catalog, knowledge, CMDB, and any custom applications. For each one, decide whether it moves to Jira Service Management, moves to another tool, or retires. Then get written agreement from compliance on how long closed records must be retained and where they will live. In practice, many regulated teams migrate open and recent records and archive the rest in a read-only, searchable store.
First 30 days: design and foundation
- Map processes, not fields. Redesign request types, workflows, SLAs, and approval steps for Jira Service Management instead of recreating every ServiceNow state.
- Design the service and asset model. Decide how CMDB classes map to Assets object schemas and which relationships auditors and change approvers actually rely on.
- Set up identity and access through your identity provider, with groups for agents, approvers, and customers. Document least-privilege roles.
- Choose the migration tooling. Atlassian Marketplace offers several ServiceNow import apps, and some teams use CSV or API scripts. Either way, run a sample export early to find attachment, comment, and user mapping issues.
Days 31 to 60: build, migrate test data, and validate
- Build service projects, queues, SLAs, and automation in a sandbox, including notifications and escalation rules.
- Rebuild integrations with monitoring, identity, HR, and DevOps tools, and confirm alert routing for on-call teams.
- Run at least two trial migrations and reconcile record counts, SLA history, attachments, and audit fields against the source.
- Run user acceptance testing with agents, approvers, and a few real requesters. Capture sign-off as evidence.
- Prepare the knowledge base in Confluence so the self-service portal has answers on day one.
Final 30 days: cutover and stabilization
- Freeze changes in ServiceNow and run the final delta migration over a planned window.
- Next, switch the front door: email channels, portal links, and phone menus point to Jira Service Management.
- Run hypercare for two to four weeks with daily triage, a clear escalation path, and a published list of known issues.
- Close out evidence: reconciliation reports, access reviews, UAT sign-off, and the archive location for historical records.
- Decommission ServiceNow only after compliance confirms the archive meets retention requirements.
Controls auditors will ask about
| Control area | What to show |
|---|---|
| Change management | Approval workflow, segregation of duties, and change history |
| Access control | Role design, provisioning through the identity provider, and periodic access reviews |
| Data integrity | Migration reconciliation reports and sample-based validation |
| Record retention | Archive location, retention period, and retrieval procedure |
| Service levels | SLA definitions and reporting continuity across the cutover |
Frequently asked questions
Is 90 days realistic?
For incident, request, and change with a moderate catalog, yes. Large custom applications, heavy CMDB integrations, or many business units usually need a phased approach over several releases.
Should we migrate all historical tickets?
Usually not. Instead, migrate open work and a recent window that agents need for context, and keep the full history in a read-only archive that meets your retention rules.
Can we run both tools in parallel?
For a short period, yes, but keep it brief. Otherwise, two front doors confuse requesters and split your reporting.
How VTPMO can help
We plan and deliver service management moves for regulated organizations, from process design through cutover and audit evidence. See our Jira Service Management services and Atlassian cloud migration services, or talk with us about a migration assessment.