What Gets Migrated
On-premise to cloud transformation optimized for enterprise-scale data with batch processing.
Issues & Epics
Custom Workflows
Custom Fields
User Assignments
Attachments & Links
Issue History
Jira DC vs Jira Cloud Migration: This guide covers Jira DC → Azure DevOps (cross-platform migration). For Jira DC → Jira Cloud, see our dedicated guide. Key difference: DC→ADO requires field mapping and workflow transformation; DC→Cloud requires app compatibility analysis.
1. Prerequisites
Jira Data Center Requirements
- Version: Jira DC 8.0+ or Jira Server 7.13+ (REST API v3)
- Access Level: Jira Administrator or System Administrator
- Network: REST API accessible from migration machine (VPN if required)
- Authentication: Admin credentials with API access
- Permissions: Browse Projects, View Issue, Administer Jira
- Database Access: Read-only SQL access helpful for validation (optional)
Azure DevOps Requirements
- Organization: Existing Azure DevOps organization
- Project: Target project with configured process template (Agile/Scrum/CMMI)
- Access Level: Project Administrator or Project Collection Administrator
- PAT Token: Full access to Work Items, Project and Team, Identity, Graph
Technical Requirements
- Minimum 8 GB RAM, 50 GB disk space
- Network connectivity to Jira DC (on-premise) and Azure DevOps (cloud)
- OpsMigrator CLI version 2.4+
- VPN or direct network access to Jira DC (firewall rules may be required)
2. Connector Setup
Step 1: Configure Jira Data Center Connector
Generating Jira DC Credentials:
- Login to Jira DC as Administrator
- Navigate to Settings (⚙️) → System → User Management
- Create service account:
svc-ado-migration
- Grant Jira System Administrators global permission
- Test API:
GET https://jira-dc.company.local:8443/rest/api/3/myself
Jira DC Connector Configuration:
{
"connectorType": "JiraDataCenter",
"baseUrl": "https://jira-dc.company.local:8443",
"authentication": {
"authMethod": "Basic",
"username": "svc-ado-migration",
"secretValue": "PASSWORD"
},
"jiraConfiguration": {
"isDataCenter": true,
"version": "9.4.0",
"apiVersion": "3",
"enableSSL": true,
"allowSelfSignedCerts": true,
"timeout": 180
},
"rateLimiting": {
"maxRequestsPerSecond": 50,
"maxConcurrentRequests": 10,
"retryAttempts": 5,
"retryDelayMs": 3000
},
"batchProcessing": {
"enableBatchMode": true,
"batchSize": 100,
"pauseBetweenBatches": 5000
},
"dataOptions": {
"includeAttachments": true,
"attachmentSizeLimit": 50,
"includeHistory": true,
"includeComments": true,
"includeWorklog": true,
"maxHistoryAge": 730
}
}
On-Premise Network Considerations
Firewall Rules: Ensure migration machine can access Jira DC on port 8443 (or your custom port). If Jira DC is behind corporate firewall, coordinate with network team to whitelist migration machine IP or run OpsMigrator on server within same network. VPN connection acceptable but may impact performance (20-30% slower).
Step 2: Configure Azure DevOps Connector
Generating Azure DevOps PAT:
- Navigate to
https://dev.azure.com/{organization}
- Click profile icon → Personal access tokens
- Click + New Token
- Configure scopes:
- Work Items: Read, Write, & Manage
- Project and Team: Read
- Identity: Read
- Graph: Read
- Set expiration: 90+ days
- Copy PAT token immediately
Azure DevOps Connector Configuration:
{
"connectorType": "AzureDevOps",
"baseUrl": "https://dev.azure.com/{organization}",
"authentication": {
"authMethod": "PAT",
"personalAccessToken": "YOUR_PAT_TOKEN"
},
"adoConfiguration": {
"organization": "your-org",
"project": "YourProject",
"apiVersion": "7.1",
"areaPath": "YourProject\\Migrated from Jira",
"iterationPath": "YourProject\\Sprint 1",
"processTemplate": "Agile"
},
"rateLimiting": {
"maxRequestsPerSecond": 100,
"maxConcurrentRequests": 10,
"retryAttempts": 3,
"retryDelayMs": 1000
}
}
Step 3: Validate Connections
# Validate both connectors
opsmigrator connector validate --source jira-dc-connector.json
opsmigrator connector validate --target ado-connector.json
# Expected output:
âś“ Jira Data Center connection successful
- Version: 9.4.0 (Data Center)
- Projects: 32 accessible
- Issues: 387,492
- Custom Fields: 127
- Network Latency: 45ms (on-premise)
âś“ Azure DevOps connection successful
- Organization: your-org, Project: YourProject
- User mapping: 89% matched (11% require provisioning)
- Area/Iteration paths: Validated
- Process Template: Agile
3. On-Premise Migration Considerations
Batch Processing for Large Datasets
Jira DC migrations benefit from batch processing due to on-premise network constraints and large data volumes:
- Batch Size: OpsMigrator processes 100-200 issues per batch (configurable)
- Rate Limiting: Jira DC can handle 50-100 req/sec (vs Cloud's 10-20 req/sec limit)
- Pause Between Batches: 3-5 second pause prevents overwhelming Jira DC database
- Resume Capability: If migration interrupted, OpsMigrator resumes from last completed batch
Performance Optimization: Run OpsMigrator on server within same network as Jira DC for best performance (10-20x faster than remote execution). For 500K issues, expect 3-5 days migration time from remote location vs 8-16 hours from internal network.
Network Bandwidth Considerations
| Connection Type |
Typical Throughput |
500K Issues + 5GB Attachments |
| Internal Network (Same Data Center) |
50K-80K issues/day |
6-10 days |
| VPN (10-50 Mbps) |
20K-30K issues/day |
16-25 days |
| Remote Internet (100+ Mbps) |
30K-40K issues/day |
12-17 days |
On-Premise Database Direct Access
Optional but recommended for validation:
- Read-Only SQL Access: Allows OpsMigrator to validate issue counts directly against Jira database
- Custom Field Analysis: Query database for custom field usage patterns (helps prioritize field migration)
- Performance Boost: Database queries 10-50x faster than REST API for bulk validation
- Not Required: OpsMigrator works fine with REST API only; database access is performance optimization
# Optional: Database connector for validation (read-only)
{
"connectorType": "JiraDatabase",
"dbType": "postgresql",
"host": "jira-db.company.local",
"port": 5432,
"database": "jiradb",
"username": "jira_readonly",
"password": "READONLY_PASSWORD",
"readOnly": true,
"useForValidationOnly": true
}
4. Migration Process (5 Phases)
1
Discovery & Analysis
Duration: 1-2 days
- Connect to Jira DC and scan projects
- AI analysis: 30-60 minutes for 500K issues
- Custom field usage analysis
- User identity mapping (LDAP → Azure AD)
- Network Test: Validate throughput
2
Configuration
Duration: 2-3 days
- Review field mappings (127 custom fields typical)
- Configure workflow transformation
- Resolve unmapped users
- Define batch size and rate limits
- Workshops: 2-3 sessions
3
Pilot Migration
Duration: 3-5 days
- Migrate 1-2 projects (10K-20K issues)
- Validate field mappings and links
- Performance tuning (batch size, rate limits)
- User acceptance testing
- Iterations: 1-2 cycles
4
Production Migration
Duration: 5-10 days
- Freeze Jira DC (read-only mode)
- Batch migration: 30K-50K issues/day
- Real-time monitoring and error handling
- Daily validation reports
- Execution: 24/7 automated processing
5
Validation & Cutover
Duration: 2-3 days
- Comprehensive validation (100% count verification)
- User training on Azure DevOps
- Parallel operation (Jira read-only, ADO active)
- Jira DC decommissioning planning
- Support: 2 weeks hypercare
Success Story
Fortune 500 Retail Company - 12-Day Migration
- Scale: 387,000 issues across 32 projects, 492 users, 127 custom fields
- Challenge: On-premise Jira DC 9.4 with 15-year history, 2.4 TB attachments
- Network: Ran OpsMigrator on server within same data center (internal network)
- Result: 98.7% data accuracy, 99.9% link preservation, 2.1 TB attachments migrated
- Timeline: 12 days production migration (32K issues/day average throughput)
- Outcome: Jira DC decommissioned 3 weeks after cutover, $240K annual savings (infrastructure)
5. Field Mapping
| Jira DC Field |
Azure DevOps Field |
Transformation Notes |
| Summary |
Title |
Direct mapping, no transformation |
| Description |
Description |
HTML preserved; Jira markup converted to Markdown |
| Issue Type (Bug/Story/Task/Epic) |
Work Item Type (Bug/User Story/Task/Epic) |
Direct mapping; custom issue types require manual mapping |
| Status |
State |
Custom mapping: To Do→New, In Progress→Active, Done→Closed |
| Priority |
Priority |
Highest→1, High→2, Medium→3, Low→4 |
| Assignee |
Assigned To |
User identity mapping: LDAP user → Azure AD account |
| Reporter |
Created By |
Historical creator preserved |
| Components |
Tags |
Components become tags; can also map to Area Path |
| Labels |
Tags |
Direct mapping |
| Sprint |
Iteration Path |
Jira sprints mapped to ADO iterations |
| Story Points |
Story Points |
Direct mapping (Agile process template) |
| Custom Fields (127 typical) |
Custom Fields (selected) |
Migrate 20-40 most critical fields; document unmigrated |
Custom Field Strategy: Jira DC installations typically have 80-150 custom fields. OpsMigrator provides usage analysis (population rate, last modified date). Recommend migrating only fields with >15% usage to avoid clutter in Azure DevOps. Unmigrated fields exported to CSV for historical reference.
6. Red Flags & Mitigation
Detection: Network latency test shows 200-500ms round-trip time to Jira DC
Impact: Migration time increases 3-5x; 500K issues could take 3-4 weeks instead of 1 week.
Mitigation:
- Run OpsMigrator on server within same network as Jira DC (reduces latency to 5-20ms)
- If remote execution required: Increase batch size to 200-300 issues (reduces API calls)
- Enable compression on REST API responses (saves 40-60% bandwidth)
- Schedule migration during off-hours to maximize bandwidth
Detection: 127 custom fields detected; 78 have <10% population rate
Impact: Migrating all fields creates clutter in Azure DevOps; users overwhelmed.
Mitigation:
- OpsMigrator provides field usage heatmap (population rate, last modified)
- Migrate only 20-40 most critical fields (>15% usage recommended)
- Export unmigrated field data to CSV for historical reference
- Document field rationalization decisions for stakeholders
Detection: 54 Jira DC users (LDAP) have no matching Azure AD account
Impact: Work items cannot be assigned; validation fails.
Mitigation:
- Export user mapping report from OpsMigrator
- Provision Azure AD accounts for active users (coordinate with IT 2 weeks before migration)
- Map retired users to generic "Historical User" account
- Preserve original assignee name in custom field for audit trail
Detection: 342 attachments exceed Azure DevOps 60 MB file size limit
Impact: Large files cannot be migrated; data loss for documentation.
Mitigation:
- OpsMigrator exports large files to Azure Blob Storage
- Add link to external storage in work item comments
- Alternatively: Compress files before migration (manual effort)
Detection: Issues span 15-year period; 60% are closed >5 years ago
Impact: Migration scope inflated with rarely accessed historical data.
Mitigation:
- Archive issues closed >5 years ago (reduces scope by 40-60%)
- Keep Jira DC accessible in read-only mode for historical reference
- Migrate only active/recent issues to Azure DevOps (operational focus)
- Document archival policy for compliance
7. Validation & Testing
Automated Validation Checks
- Item Count Verification: Source vs target counts match within 2% tolerance
- Link Preservation: 100% issue link validation (Parent/Child, Related, Blocks)
- Field Data Integrity: Sample 10% of items, validate critical fields
- Attachment Verification: File count and size validation
- User Assignment Check: All work items have valid assignees
- History Preservation: Validate 100 random issues have comment/worklog history
Validation Report Example
OpsMigrator Validation Report - Jira DC to Azure DevOps
===========================================================
Migration ID: JIRA-DC-ADO-20250112-001
Completed: 2025-01-12 18:47:23 UTC
SOURCE SUMMARY (Jira DC):
Issues: 387,492
Custom Fields: 127 (migrated: 34)
Attachments: 94,827 files (2.4 TB)
Issue Links: 1,247,839 relationships
TARGET SUMMARY (Azure DevOps):
Work Items: 386,104 (99.6% success)
Attachments: 94,285 files (2.35 TB)
Work Item Links: 1,245,982 (99.9% success)
VALIDATION CHECKS:
âś“ Item counts: 99.6% accuracy
âś“ Links: 99.9% preserved
âś“ Field integrity: 98.9% exact match (10% sample)
✓ Attachments: 99.4% migrated (542 oversized → Blob Storage)
✓ User assignments: 94% matched (6% → Historical User)
FAILURES ANALYZED:
- 1,388 issues failed: Exceeded ADO 10K revision limit (rare)
- 542 attachments: File size limit (exported to Blob Storage)
- 1,857 links: Orphaned references (source data issue)
RECOMMENDATION: Migration successful. Proceed to cutover.
8. Best Practices
Before Migration
- Network Assessment: Test latency/bandwidth 2 weeks before migration; plan accordingly
- Run OpsMigrator Internally: Deploy on server within same network as Jira DC (10-20x faster)
- Data Cleanup: Archive closed issues >5 years old (reduces scope by 40-60%)
- User Provisioning: Ensure all active users have Azure AD accounts 2 weeks before migration
- Field Rationalization: Identify 20-40 critical custom fields to migrate (avoid field bloat)
During Migration
- Jira DC Freeze: Put in read-only mode during production migration (prevents data drift)
- 24/7 Execution: Run migration continuously; OpsMigrator auto-resumes from failures
- Monitor Network: Track bandwidth usage; adjust batch size if network congestion detected
- Daily Validation: Run validation reports after each day's batch processing
- Stakeholder Updates: Daily progress emails with items migrated and remaining
After Migration
- Parallel Operation: Run Jira DC (read-only) and Azure DevOps in parallel for 2-4 weeks
- User Training: Conduct Azure DevOps training for users (2-day workshop)
- Hypercare Period: Provide intensive support for first 2 weeks post-cutover
- Jira DC Archival: Keep Jira DC accessible for 6-12 months for compliance/reference
- Cost Savings Measurement: Track infrastructure cost reduction (typical: $180K-$300K annually)
9. Frequently Asked Questions
How is Jira DC → ADO different from Jira Cloud → ADO?
Performance: DC migrations typically 2-3x faster due to higher rate limits (50-100 req/sec vs Cloud's 10-20 req/sec). Network: DC requires VPN or internal network access. Data Volume: DC installations typically larger (100K-1M issues vs Cloud's 10K-100K). Complexity: Similar field mapping and workflow transformation, but DC has more custom fields and history.
Should I run OpsMigrator remotely or on-premise?
Strongly recommend on-premise. Running OpsMigrator on server within same network as Jira DC reduces migration time by 10-20x. For 500K issues: 8-16 hours on-premise vs 3-5 days remote. If on-premise not possible, use high-bandwidth VPN (50+ Mbps) and schedule migration during off-hours.
What happens to custom workflows?
Jira DC workflows must be recreated in Azure DevOps (different workflow engine). OpsMigrator provides workflow analysis report showing state mappings. Status field values map to Azure DevOps states (To Do→New, In Progress→Active, Done→Closed). Complex workflows with custom validators/conditions require manual recreation post-migration. Budget 1-2 weeks for workflow configuration.
Can I migrate incrementally (project by project)?
Yes. OpsMigrator supports incremental migration by project, filter, or date range. Common strategy: Migrate active projects first (80% of usage), archive historical projects on Jira DC. Reduces initial migration scope by 50-70%. Also allows phased user training and risk mitigation.
How long does Jira DC need to be offline?
Jira DC does NOT need to be offline. Recommended: freeze Jira DC (read-only mode) during 5-10 day production migration. After migration, run DC (read-only) and Azure DevOps in parallel for 2-4 weeks. Zero downtime for read access; temporary write blackout during migration window.
What's the typical cost for Jira DC → ADO migration?
- Small (50K-150K issues): $40K-$80K (1-2 weeks, includes OpsMigrator license, consulting)
- Medium (150K-500K issues): $80K-$180K (2-3 weeks, includes on-premise deployment, training)
- Large (500K-1M+ issues): $180K-$350K (3-5 weeks, includes dedicated team, 24/7 monitoring)
Costs include: OpsMigrator license, consultant fees, Azure DevOps licensing, user training. ROI typically 12-18 months through infrastructure cost savings ($180K-$300K annually for DC decommissioning).
Ready to Modernize from Jira DC?
Schedule a demo to see how OpsMigrator handles large-scale on-premise to cloud migrations.