No-code integration platform for rich bi-directional sync
Zero downtime migration to tool of your choice
Keep Historical Data, Without Slowing Down Your Tools
Migrate or restructure Azure DevOps Instances
Real-time, context-rich data lake for AI or analytics
By Role
Accelerate delivery with clear insights
Transform smarter with a connected digital thread
Confident transitions for every enterprise change
By Initiative
Modernize and move to cloud without disruption
Modernize legacy systems for a connected enterprise
Build a compliant digital thread for complex environments
Build the foundation for smarter AI
By Domain
No-code integration across teams & systems
Enable collaboration between IT, support & business teams
Connect PLM & engineering teams for smarter products
Ensure regulatory compliance from start to release
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
Evaluate before you buy
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
Moving between Azure DevOps organizations or tenants? This guide covers moves, merges, and splits, what migrates, your options, and the five stages to run it. OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) supports it with history, user identity mapping across tenants, and delta migration, so teams keep working.
A successful ServiceNow to JSM migration requires clear scope, clean data, accurate field and user mapping, and a preconfigured JSM target. Test with a pilot, migrate in phases while ServiceNow stays live, retry failed records, and reconcile counts and IDs. Cut over only after validation and acceptance. OpsHub Migration Manager supports phased migration and automatically retries failed records.
A ServiceNow to JSM migration should preserve support history, including incidents, requests, work notes, SLAs, and audit records, without data loss or service disruption. Missing tickets exposed internal notes, and inconsistent SLA history may surface weeks later. A controlled cutover prepares the target and mappings, runs both systems in parallel, and switches to JSM only after validation. Until then, ServiceNow remains the system of record and fallback.
Decide what moves, what is archived and what is left behind before any tool is chosen. Scope the migration by record type and age. Move open incidents and request items, and the recent closed history the business still uses. Archive or leave older closed records that carry risk without operational value. Clean the source first: remove duplicates and test records where retention rules allow and resolve orphaned attachments and stale references.
Risk it prevents: Personal data exposed in JSM, and old clutter burying the records agents need
Migrating everything by default moves years of closed tickets, and the personal data buried in them, into a new system with new permissions. Agents then search through noise to find live work, and sensitive data sits where it was never meant to be. Scoping and cleaning first keep the target lean and keep regulated data out of it.
Agree on the mapping and obtain service-owner sign-off before migration. Define how ServiceNow fields, statuses, assignment groups, and users map to JSM equivalents, including how account-less and former-employee authors are handled to preserve historical attribution. Pay particular attention to comment visibility: map internal ServiceNow work notes to JSM internal comments and customer-facing additional comments to customer-visible replies. Detailed entity mapping is covered separately.
Risk it prevents: Customers seeing internal work notes, and tickets landing with the wrong owner
Get the visibility mapping wrong, and a customer opens a migrated ticket and reads an engineer’s private note about their account. Get identity mapping wrong, and migrated tickets lose their assignee, so work lands nowhere and nothing is owned. A signed-off mapping, settled before the run, is what prevents both.
Configure JSM before loading data by creating the service project, request types, fields, and workflows, as these must be set up in JSM rather than transferred from ServiceNow. Use a company-managed project for shared custom fields, add agents with visible email addresses, pre-create fields without native equivalents, enable customer sign-up, and increase attachment limits. Use a ServiceNow account with read access to required tables, and disable notifications and automation during loading, re-enabling them afterward.
Risk it prevents: Customers flooded with notifications about tickets closed years ago
Load thousands of historical tickets with notifications live, and every customer is emailed about incidents resolved long ago. The migration reads like a spam campaign, and trust in the new portal is damaged on day one. Turning notifications and automation off during the load prevents it.
Run a pilot in a test JSM project to validate mappings, data integrity, and migration time. Include representative incidents, requests, fields, comments, attachments, images, relationships, and former-employee records, accounting for ServiceNow API pagination and rate limits. Before proceeding, verify matching record counts and IDs, intact fields and relationships, correct comment visibility, accessible attachments, no customer notifications, unchanged source records, and completion within the planned window. A designated reviewer must approve the results.
Risk it prevents: Starting the full run without evidence that the plan works at volume
Without a pilot, the first real test of the plan is the full run itself, and any adjustment for API limits or slow records happens mid-move. A pilot plus a full-volume rehearsal settles those questions early, so the team starts the full run with confidence and a measured timeline.
Migrate in stages while keeping ServiceNow live: move historical data first, then transfer records created or changed during the migration in subsequent passes. Running both systems in parallel avoids a risky big-bang cutover. OpsHub Migration Manager (OMM) supports phased, incremental migration to carry ServiceNow changes into JSM, with optional reverse sync to send JSM changes back to ServiceNow, keeping the source available as a fallback until final cutover.
Risk it prevents: service desks going offline, or ServiceNow and JSM drifting apart during the move
A big-bang cutover takes the service desk offline for the switch, and any ticket raised or updated during the window is at risk of being missed. Without a way to keep the two systems aligned, they drift, and the migrated data no longer matches the source. Phased migration with a reverse sync keeps the systems aligned until cutover.
Treat completeness as something to prove, not assume. Plan for failed records by surfacing and retrying them without rerunning the entire migration or affecting successful records. OMM automatically detects and retries failed records. Then reconcile source and target counts and record IDs by type, spot-check comments, attachments, and parent-child links, and preserve original ServiceNow record IDs for traceability.
Risk it prevents: Records going missing with no error, and matching counts hiding missing comments, attachments and links
A record skipped by the run raises no error, so a migration can look complete when it is not. Count the totals only, and a ticket that arrived without its attachments or its history still passes as done. Reconciling by count and ID, and spot-checking content, is the difference between looking complete and being complete.
Cut over only after agreed acceptance criteria are met, with a designated owner approving the go/no-go decision based on counts, required fields, relationships, and content. Protect the audit trail by keeping ServiceNow read-only for a defined period and retaining it until acceptance and retention requirements are met. Verify with a standard user account that records cannot be edited and have legal or compliance review the final retention and decommissioning plan.
Risk it prevents: Audit evidence lost once ServiceNow is switched off
Decommission the source before the target is proven and accepted, and any gap in the migrated history becomes permanent. If an auditor later asks for a record that did not come across cleanly, the evidence is gone. Keeping ServiceNow read-only until acceptance and retention rules allow its retirement is what protects the audit trail.
ServiceNow to JSM migrations often fail quietly through missing records, incomplete mappings, or unverified data. Follow these seven preparation steps to reduce risk and make cutover controlled and verifiable. OMM supports phased migration and automatic retries of failed records without rerunning the entire migration
Ans1) Yes, if ServiceNow remains the system of record until migration approval. If acceptance fails, teams can continue working in ServiceNow while JSM data is corrected or migration rerun. This does not automatically undo data already migrated to JSM, so confirm the tool’s rollback capabilities and define a recovery plan beforehand.
Ans 2) A migration reads from ServiceNow and writes to JSM, so the source records are not meant to change. Keep ServiceNow in read-only mode during validation to protect them and confirm the read behavior of the chosen tool. Verify this in the pilot rather than assuming it.
Ans 3) A pilot should use data that reflects real tickets, including fewer common ones, so the result proves the plan for the full dataset. Use a representative sample of production records and avoid carrying unnecessary personal data into a test target. Keep the sample small enough to repeat quickly after a fix.
Ans 4) They are different. A one-time migration moves records from ServiceNow into JSM and ends, while a historical sync keeps two systems aligned while both stay in use. A migration can use a reverse sync during the transition, carrying changes made in JSM back to ServiceNow until cutover, but the goal is still a single move to JSM.
Ans 5) Switch off ServiceNow only after the migration passes acceptance and after retention and audit requirements allow it. Keep it available in read-only mode for a defined period as a fallback and an evidence source. Have the compliance team confirm the retention period before decommissioning.
Have more questions about your use case?
See how OpsHub looks like in your environment
