Jira cross-instance merge & split services for Cloud and Data Center

We plan, test, and execute complex Jira & JSM merges and splits with clean data and clear timelines.

Jira cross-instance m erge & split hero infographic

you can trust our experts

Enterprise-grade support backed by Atlassian certifications


Recognition and expertise:
Double Platinum Partner (Solution and Marketplace)
Finalist for Atlassian Partner of the Year 2024–2025 (Emerging Markets)
Extensive experience with Jira, Confluence, Jira Service Management, and Assets
50+ Atlassian-certified professionals across all key products
Comprehensive support ecosystem:
Full-service offering covering audits, licensing, implementations, migrations, integrations, and custom app development
22,500+ app installations on the Atlassian Marketplace
More than 11 million end users supported globally

Jira merge and split services

Jira cross-instance work we do

Logo image

Merge multiple Jira sites (Cloud↔Cloud, DC↔Cloud, DC↔DC)

Map and consolidate issue types, fields, workflows, and permissions into a clean target. Dry-run the merge, set a freeze window, and preserve issues, comments, history, and attachments.
Logo image

Split a single Jira into new sites (divestitures/regions)

Define scope by project, team, label, or date; export safely with full history and links. Apply re-key/redirect strategy; separate users, groups, and permissions for the new orgs.
Logo image

Combine or separate Jira Service Management projects

Keep SLAs, queues, request types, portals, and knowledge base links (rebuild where needed). Retain customer accounts/Organizations; carry over email channels, automations, and Assets/CMDB refs where supported.
Logo image

Rationalize configurations (issue types, screens, schemes, custom fields)

Remove duplicates and standardize names; create lean, reusable schemes. Document governance rules and ownership to cut admin effort going forward.
Logo image

Unify identities (Atlassian Access/SSO or DC directories)

Plan domain claims and SCIM/LDAP mapping; resolve duplicate or orphaned accounts. Align groups and project roles; enforce least-privilege access in the target site.
Logo image

Handle Marketplace apps and automations

Build a support matrix; migrate or re-create app data, post functions, and rules. Validate after cutover: automations, links, and reports; note limits and apply workarounds.

What you gain

Post-merge/split outcomes


Clean target configuration
Final, de-duplicated schemes, fields, workflows, and permissions—documented in a mapping pack and “as-built” diagram.
Clear naming standards and ownership so new projects slot in without conflicts.
Preserved data integrity
Scheduled, encrypted backups with clear retention by data class and region; immutable/offsite copy where required.
Least-privilege access, monitoring, and alerts.
Predictable cutover
Agreed freeze window, rehearsed timing, backups/snapshots, and a tested rollback path.
A step-by-step runbook with roles, comms templates, and decision points.
Lower admin overhead
Fewer custom fields/schemes and reusable workflows; lighter automation footprint.
Faster admin tasks and indexing, plus reduced app/license sprawl.
Compliance-aware delivery
Least-privilege access, NDA by default, and segregated credentials with access logs.
Audit pack: before/after configs, approvals, residency notes, and verification reports.
Simple and transparent process
How we work, end-to-end
Discovery and assessment
  • Export configs from each instance: projects, fields, workflows, schemes, permissions, users/groups, apps, automations, integrations.
  • Score risk and complexity; flag blockers (app gaps, data residency), and recommend the best path (Cloud↔Cloud, DC↔Cloud, DC↔DC).
Target design and mapping
  • Define the end state: project structure, issue types, fields, workflows, permission schemes, naming standards, and governance.
  • Build mapping rules: field merge/rename, status transitions, SLA calendars/metrics, role/group mapping, issue key strategy, and retention rules.
Pilot in sandbox
  • Run a dry-run on a representative set (incl. JSM): migrate data, automations, SLAs, queues, and Assets/CMDB where used.
  • Validate with SMEs: record counts, sample issues, attachments, comments, history, links, and permissions; refine scripts and mappings.
Production readiness
  • Prepare the cutover plan: freeze window, change ticket, comms templates, backups/snapshots, rollback scenarios, and success criteria.
  • Lock down access and tooling: service accounts, API tokens, IP allowlists, timed runbook, and go/no-go checklist with approvals.
Cutover and validation
  • Execute migration, re-index, reconnect integrations and email channels, and apply SSO/user updates as planned.
  • Run post-cutover checks: SLAs/queues, issue counts, links/attachments, permissions; fix-forward exceptions and log defects.
Stabilize and optimize
  • Hypercare period: fast triage, small fixes, performance tuning, and cleanup of legacy fields/schemes.
  • Handover: as-built docs, admin runbooks, governance guardrails, and a prioritized improvement backlog (optional training).

Book Your Jira Merge/Split Consultation

Book a scoping call


We will reply in 24 hours with detailed information. Our expert will invite you for a meeting (or e-mail you) to determine the exact scope of your needs.

Call our consultant

Consultant image

Katarzyna Dorosz-Żurkowska

Head of Atlassian Services

Our consultant is at your disposal for any additional questions.

FAQ

Have questions? We have the answers

  • Can you merge Jira Cloud and Data Center instances?

    Yes. We handle Cloud↔Cloud, DC↔Cloud, and DC↔DC merges. We map fields, workflows, and permissions into a clean target and preserve issues, comments, attachments, and history.

  • Will we lose any data during a merge or split?

    No data is dropped without sign-off. We carry over issues, comments, attachments, SLAs, and request data where supported. Validation checks – record counts, spot audits, and logs – prove the transfer.

  • How do you handle Jira Service Management (JSM) projects?

    We migrate SLAs, queues, request types, portals, and knowledge base links. Customer accounts and organizations are retained, and where Atlassian limits apply, we rebuild with workarounds.

  • What about Marketplace apps and automations?

    We inventory app data and backup options. Where vendor backups are available, we use them; otherwise we rebuild with exports, scripts, or config-as-code. Automations and post-functions are validated after cutover.

  • How do you make sure the cutover goes smoothly?

    We run dry-runs in a sandbox to time the process and fix gaps. The final cutover follows a rehearsed runbook with a freeze window, backups, rollback plan, and go/no-go checklist.

  • What happens after the migration?

    We provide a hypercare period for fixes and performance tuning. You also receive as-built documentation, admin runbooks, and governance guardrails so your teams can operate confidently.

  • Do you have security/compliance documentation we can use for vendor due diligence (audits, certifications, privacy)?

    Yes. Deviniti’s Trust Center provides downloadable security and compliance documentation for vendor due diligence, including:

    • ISO/IEC 27001 certificate (ISMS)
    • ISO/IEC 27017 certificate (cloud security controls guidance)
    • SOC 2 Type 1 report
    • Privacy & Security Overview
    • CAIQ Lite – Apps (Cloud Security Alliance questionnaire)
    • Cloud Hosting Locations & Data Residency Options
    • Information Security Policy (AUP)

    For GDPR due diligence, Deviniti provides a Data Processing Agreement (DPA) under GDPR Article 28. As a general rule, personal data processing takes place within the EU/EEA. Where international transfers are necessary, Deviniti uses lawful transfer mechanisms (e.g., EU adequacy decisions and Standard Contractual Clauses) with additional safeguards. For products that support it, you can also choose service delivery exclusively via infrastructure located in the EEA.