Desk365 to Jira Service Management Migration

MIGRATION OVERVIEW

Why teams migrate from Desk365 to Jira Service Management

The core problem

Migrating from Desk365 to Jira Service Management (JSM) has no native or automated migration path, requiring custom extraction and transformation scripts built against both platforms' REST APIs. Desk365 uses a flat, Microsoft 365-native ticket structure, while JSM is built on Jira's issue-tracking engine where every ticket is an issue tied to a project, issue type, and workflow — creating fundamental data model mismatches that cannot be resolved through simple field mapping. Key custom work includes converting Desk365 HTML and plain-text descriptions into Atlassian Document Format (ADF), resolving user accounts to JSM accountIds, pre-creating workflow statuses and custom field option IDs in JSM before import, and implementing adaptive rate-limit handling against Jira Cloud's three concurrent rate-limiting systems. Comment visibility, customer portal visibility via Request Type assignment, and department access-model redesign add additional layers of technical complexity.

Why this matters for your migration

KEY CHALLENGES

What makes this migration complex

These are the architectural mismatches and technical hurdles specific to a Desk365 to Jira Service Management migration.

Most Critical

Atlassian Document Format Conversion

Desk365 exports ticket descriptions as plain text or HTML, but the Jira Cloud v3 REST API requires all multi-line text fields in ADF, a JSON-based document structure, necessitating a full HTML-to-ADF parsing and conversion layer before any data can be imported.

Blocks all downstream imports if mapped wrong

Request Type Assignment Gap

Desk365 tickets imported as standard Jira issues without a Customer Request Type value will not appear in the JSM customer portal and will not trigger end-user email notifications, requiring every migrated issue to be explicitly assigned a valid requestTypeId.

Jira Cloud Rate Limit Complexity

Jira Cloud enforces three simultaneous rate-limiting systems — a per-hour points-based quota, a per-second burst limit using a token bucket algorithm, and per-issue write frequency limits — requiring migration scripts to implement adaptive exponential backoff rather than fixed throughput targets.

Comment Visibility Preservation

CSV and JSON bulk importers make all imported comments public in JSM, so private Desk365 internal notes can only be preserved as internal comments by using the JSM Service Desk API with the public: false flag on each comment.

Department Access Model Redesign

Desk365 departments control ticket form visibility, knowledge base visibility, and customer routing within a nested company structure, but JSM has no direct equivalent, requiring a deliberate redesign using a combination of components, queues, organizations, and custom fields depending on how departments are used.

Archived Ticket Completeness Risk

Desk365 requires separate exports from the All Tickets view and the Archived Tickets view, and failing to export archived tickets is a common cause of incomplete migrations resulting in missing historical ticket data in JSM.

COMPLETE COVERAGE

Intelligent Human-Verified Data Mapping

Our migration engineer precisely maps every data point from Desk365 to Jira Service Management, ensuring perfect continuity for your customer support operations.

Tickets

Requests (Issues)

Contacts

Customers

Companies

Organizations

Agents

Users (Agents)

Groups

Ticket Conversations

Request Comments

Ticket Attachments

Request Attachments

Knowledge Base Articles

Ticket Types

Request Types

Ticket Statuses

Workflow Statuses

Ticket Priorities

Priorities

Custom Fields

SLA Policies

Not Available

Satisfaction Ratings

Not Available

Looking for more entity mappings?

Contact our team

MIGRATION RISK ASSESSMENT

Every migration risk, already solved

Migration between platforms is full of edge cases. Our engineers have identified every risk from Desk365 to Jira Service Management and built proven solutions for each one.

High complexity

Ticket Descriptions

Every ticket description must be converted from Desk365's plain text or HTML output into Atlassian Document Format before import, and skipping or incorrectly implementing this conversion causes descriptions to render as literal markup text in the JSM portal.

Solved
Private Notes / Internal Comments

Bulk import methods make all comments public by default, meaning internal Desk365 notes can only be migrated with correct visibility by using the JSM Service Desk API with explicit public: false flags on each comment.

Solved
Custom Fields

Custom field values must be submitted using JSM's internal customfield_XXXXX identifiers and option IDs rather than display values, requiring all custom fields and their option sets to be pre-created in JSM and their IDs resolved before the migration script runs.

Solved
CSAT / Survey Data

JSM has no native CSAT data model compatible with Desk365's survey ratings, so historical satisfaction scores must be stored as read-only custom fields on migrated issues or exported separately to Confluence, and cannot be written into JSM's native satisfaction fields.

Solved
Departments

Desk365 departments control visibility and routing at the company level and have no direct JSM equivalent, requiring a deliberate access model redesign using components, queues, organizations, or custom fields depending on how each department was functionally used.

Solved

Custom engineering

Tickets

Core ticket fields map reasonably well, but status values must be pre-created in the JSM workflow, Issue Type and Request Type assignments require deliberate mapping, and created dates default to import time unless the bulk import pipeline is used to preserve historical timestamps.

Handled
Contacts / Customers

Each Desk365 contact must exist as a JSM customer account before tickets are imported, requiring email-to-accountId resolution and programmatic customer creation via API for any contacts not already present in the target Jira instance.

Handled
Companies / Organizations

Desk365 companies map to JSM Organizations for basic customer grouping, but when company or department fields also drive routing logic or asset ownership, a structural redesign is required rather than a direct data copy.

Handled
Attachments

Attachments must be downloaded from Desk365 and re-uploaded to JSM as a two-step API operation per ticket, making attachment migration volume-sensitive and a common source of script timeout failures at scale.

Handled
Knowledge Base Articles

Desk365 knowledge base content follows a Categories-Folders-Articles hierarchy extracted via three separate API endpoints, and must be restructured into Confluence space and page hierarchy since JSM's native knowledge base is powered by Confluence rather than a standalone article store.

Handled

What Our Customers Say

Real migration stories

Direct Review

“Overall a great experience. We had to go back a few times to get everything just right, which was totally expected. The transition was smooth, and there was no data loss.”

Direct Review

“One of the easiest migrations I've ever been through. The team took care of everything — all our data, customer interactions and macros. The process was clear, straightforward and we felt supported all the way. An absolutely seamless experience for our support team and our customers.”

Direct Review

“Fantastic at both guiding us through the process and helping us fix things as they come up and dial them in.”

Reviewed on G2

“The ease of the process and that ClonePartner was informing me what was going on at every step. If you're on the fence, do it. ClonePartner are great!”

Direct Review

“They were SO helpful. We had a few hiccups because our migration was in the middle of the process, but they were really flexible and did multiple delta migrations for us. We were able to map a lot of our old ticket data so it's usable for comparisons in the future.”

See all customer stories →

CUSTOM MIGRATION

Fully customizable engineer-led migration

Tailor your migration from Desk365 to Jira Service Management exactly to your needs with our flexible customization options. Our experts will configure the perfect migration plan for your business.

Migration Filters

Data Types

ZERO DOWNTIME

Your timeline. Our engineers.

A dedicated engineer runs your migration, planned around your schedule and your data.

No babysitting a wizard. Avoid debugging errors yourself.

Looking for a more detailed migration timeline?

Contact our team

Speed

The migration timeline depends on both our turnaround time and yours.

We can complete a migration in under a day when the accounts are connected and the sample migration is approved promptly.

Background Sync

We also support migrating the newest records first, so you can go live faster while the rest of the data is synced in the background.

Data Volume Impact

Larger data volumes may require longer migration windows.

Continuous Operation

Weekend migrations minimize disruption to your customer service operations.

MIGRATION TIMELINE

Your Desk365 to Jira Service Management migration, step by step

See how long your migration will take from start to finish. Drag the slider to estimate based on your data volume.

How many records are you migrating?

<10K 50K 100K 250K 500K 1M 2M 5M 10M+

Checklist ~3 days

Sample 1 day

Review ~2 days

Full 2 days

Delta 1 day

Your team ClonePartner

Estimated total

~9 business days

Migration Checklist

1 day · ClonePartner ~2 days · Your team

We prepare the optimal data mapping as a shareable spreadsheet. Your team reviews, approves, and adds any customizations.

Sample Migration

1 day · ClonePartner

We run a test migration with a representative sample of your data to verify mapping accuracy and identify any potential issues before the full run.

Review & Approve

~2 days · Your team

Your team reviews the sample migration results, confirms data accuracy and mapping, and gives the go-ahead for the full migration.

Full Migration

2 days · ClonePartner

We execute the complete migration of all your data to your new Jira Service Management, with real-time progress tracking and comprehensive logging.

Delta Migration

1 day · ClonePartner

We capture and transfer any new data that was added or updated during the main migration to ensure no data is lost. This final sync keeps everything current.

Pros and cons of different migration options

Choosing the right approach is key because migrating from Desk365 to Jira Service Management isn't just about moving data – it's about protecting customer relationships.

Feature / Criteria	ClonePartner	Automated Tools	CSV Import	In-house migration
Custom Scripting for complex data	✓ Engineers build & maintain	✗ No	⚠ Manual	✓ Yes – but costly
Sandbox & Pilot Migrations	✓ Full sandbox + pilot plans	⚠ Limited	✗ No	⚠ Often Informal
Manual validation & reconciliation	✓ Automated + manual QA	✗ No	✓ Yes (Manual)	✓ Heavy manual effort
Backup & rollback plan	✓ Robust procedures	✗ No	✗ No	⚠ Often incomplete
Handles automation and integrations	✓ Full support	⚠ Partial	✗ No	⚠ Possible but fragmented
Post-migration engineer support	✓ Dedicated engineers	✗ No	✗ No	⚠ Limited SLA
Adaptable to API changes	✓ Proactive adaptation	✗ No	⚠ Manual fixes	⚠ Slower response
Turnaround / SLA predictability	✓ Predictable SLAs	⚠ Fast but brittle	⚠ Slow and manual	⚠ Often slower
Data Security & Compliance	✓ High – enterprise grade	⚠ Medium (depends)	⚠ Low (manual)	⚠ Hidden gaps common
Pricing predictability	✓ Transparent & fixed	⚠ Low (per-job)	⚠ Low (manual hours)	⚠ High/variable OPEX
End-to-end project management	✓ Full E2E delivery & PM	✗ No	✗ No	⚠ Often partial
Business impact & opportunity cost	✓ No diversion of staff	✗ No	✗ No	⚠ Diverts engineering

What does an Engineer-led migration mean anyway?

Speed & Accuracy: Our Blended Method

We blend automation (smart scripts, bulk APIs) with human expertise for speed without risk. Our engineers manually check every mapping, validation, and exception.

You get:

Speed of automation for bulk record migration
Precision of engineers verifying integrity and business logic
Pilot migrations and sandbox testing to catch issues early
Real-time validation reports and rollback readiness

Result: 50x faster migrations than manual imports — with near-zero error rates.

Handling the Tricky Tech and API Details

The Desk365 and Jira Service Management APIs each behave differently, which is where our engineers shine. We build custom logic to handle the data quirks where generic tools typically break.

We handcraft API logic for:

Field mapping and transformation
Pagination, rate-limit handling, and throttling
Preserving conversation threads, attachments, and internal notes
Syncing custom fields, SLAs, and macros without breaking structure

Our scripts: Natively retry failed calls, re-queue large attachments, and ensure data parity.

No Guesswork

We don't just promise smooth migrations—we measure and prove them. Every client receives a Migration Validation Report with all metrics.

Typical results across projects:

100% record-count parity between your Desk365 data and Jira Service Management
Zero downtime during staged cutovers
99.9% attachment integrity (verified via checksum)
Full automation and preservation of all business rules

Our standard: Includes full SLA preservation and 30 days of engineer-assigned support post go-live.

We Adapt to Your Setup (Not the Other Way Around)

No two teams configure Desk365 or Jira Service Management exactly the same way—with unique automations and data. We customize every migration script to fit your exact workflow, tags, and triggers.

Our engineers adapt for:

Custom fields, ticket forms, and workflows
Multi-brand or multi-language setups
Historical imports and partial (date-based) migrations
Integration re-mapping for CRMs, chat, or feedback tools

The promise: If your data doesn't fit a standard template, we build one just for you.

Enterprise-Grade Security & Compliance

Your customer data is precious. Our migration process maintains the highest standards of security and regulatory compliance.

SOC 2 Type II

Independently audited compliance with rigorous security standards

ISO 27001

Certified information security management system

GDPR

Full compliance with EU data protection regulations

HIPAA

Certified for handling protected health information

AES-256 Encryption

Bank-grade encryption for all stored credentials

Latest TLS

Secure transfer protocol for all data in transit

Role-Based Access

We follow role-based access control for every migration project

Scheduled Deletion

Automatic data purging after migration completion

FAQ

Frequently Asked Questions

Everything you need to know about migrating from Desk365 to Jira Service Management. Can't find what you're looking for? Talk to our team.

Will Desk365 private notes stay private after migrating to Jira Service Management?

Not if you use Jira's CSV or JSON importers — imported comments become public in JSM. To preserve internal/public visibility, use the JSM request comment API, which accepts a public true/false flag on each comment. ([support.atlassian.com](https://support.atlassian.com/jira-cloud-administration/docs/import-data-from-a-csv-file/))

How do I handle Desk365 ticket descriptions in JSM?

JSM's v3 REST API requires descriptions in Atlassian Document Format (ADF), a JSON structure. Desk365 exports descriptions as HTML or plain text. You need a conversion layer — dumping raw HTML into an ADF field renders as literal markup text in the portal.

Do I need to export archived tickets from Desk365 separately?

Yes. Desk365 requires separate exports from the All Tickets view and the Archived Tickets view to get complete history. Missing the archived export is a common cause of incomplete migrations. ([help.desk365.io](https://help.desk365.io/en/articles/export-tickets/))

Can I keep Microsoft Teams ticketing workflows after moving to JSM?

Yes, but you need to rebuild them. JSM provides Teams integration through Atlassian Assist. Key constraints: a Jira site can connect to only one Teams tenant, request types with unsupported required fields block chat intake, and ticket creation requires an emoji reaction or bot interaction rather than auto-capturing every message.

How long does a Desk365 to Jira Service Management migration take?

It depends on ticket volume, attachment size, and custom field complexity. A straightforward migration under 10,000 tickets can complete in 1–3 days. Complex migrations with deep custom fields, knowledge base content, private note handling, and full conversation history typically take 1–2 weeks of engineering work.

How long does the Desk365 to Jira Service Management migration take?

Most migrations complete within 1–5 business days, depending on data volume and complexity. We provide a detailed timeline after the initial assessment and can often complete small migrations in under 24 hours.

Will my team lose access to Desk365 during the migration?

No. Your source system remains fully operational throughout the entire migration. We run the migration in the background with zero downtime to your current operations.

Will there be downtime when migrating from Desk365 to Jira Service Management?

No. Our migration process is designed for zero downtime. We use a staged approach with background sync and a fast cutover, ensuring no disruption to your live business operations.

How do I validate that everything migrated correctly?

Every client receives a Migration Validation Report with comprehensive metrics including record-count parity, attachment integrity verification via checksum, and full audit logs. We also offer unlimited sample migrations so you can verify before committing.

Do I need professional help for this migration?

While simple migrations can sometimes be handled in-house, professional help ensures zero data loss, proper field mapping, and preservation of relationships between records. Our engineer-led approach catches edge cases that automated tools miss.

Does ClonePartner provide guidance before committing?

Yes. We provide a free consultation and assessment. We'll review your data structure, discuss your requirements, and provide a detailed migration plan and fixed-price quote before you commit to anything.

Still have questions?

Book a free 30-minute consultation with our migration engineers. We'll walk you through the exact approach for your Desk365→Jira Service Management migration.

Contact our team

Ready to start your
Jira Service Management Migration?

Join hundreds of businesses who have successfully migrated with ClonePartner. Let's discuss your migration needs and build a plan that works for you.

Book free consultation

Attention to Detail

We meticulously handle every aspect of your migration, ensuring no data is lost during transfer and mapping every field correctly between platforms.

Custom Solutions

Every business is unique. We tailor your migration strategy to match your specific requirements, workflows, and data structures.

Security & Compliance

Your customer data is handled with enterprise-grade security protocols, ensuring compliance with GDPR, HIPAA, and industry standards.

Migrate from Desk365 to Jira Service Management with precision & ease

Why teams migrate from Desk365 to Jira Service Management

What makes this migration complex

Atlassian Document Format Conversion

Request Type Assignment Gap

Jira Cloud Rate Limit Complexity

Comment Visibility Preservation

Department Access Model Redesign

Archived Ticket Completeness Risk

Intelligent Human-Verified Data Mapping

Every migration risk, already solved

Real migration stories

Fully customizable engineer-led migration

Your timeline. Our engineers.

Your Desk365 to Jira Service Management migration, step by step

Pros and cons of different migration options

What does an Engineer-led migration mean anyway?

Speed & Accuracy: Our Blended Method

Handling the Tricky Tech and API Details

No Guesswork

We Adapt to Your Setup (Not the Other Way Around)

Enterprise-Grade Security & Compliance

Frequently Asked Questions

Ready to start yourJira Service Management Migration?

Attention to Detail

Custom Solutions

Security & Compliance

Ready to start your
Jira Service Management Migration?