Back to Migration Scenarios
Migration Overview
VersionOne to Azure DevOps is one of the most complex enterprise migration paths. VersionOne's deep
portfolio hierarchy (Theme → Initiative → Epic → Story → Task → Test) must be carefully mapped to
Azure DevOps' flatter structure. This migration requires extensive planning, custom field transformation,
and careful handling of organizational hierarchies.
Complexity Note:
This migration is classified as CRITICAL complexity due to VersionOne's unique data model, extensive
custom fields, and complex portfolio management structures. We strongly recommend a dedicated migration
consultant and extended pilot phase.
What Gets Migrated
Portfolio Hierarchy
Themes, Initiatives, Epics mapped to ADO Epic hierarchy
Backlog Items
Stories, Defects, Tasks with full history
Sprints & Releases
Sprint schedules, release plans, and timebox data
Team Structure
Teams, members, and role assignments
Test Assets
Test sets, test cases, and test execution results
Custom Attributes
100+ custom fields with data type transformation
Prerequisites & Requirements
Source System (VersionOne)
- VersionOne Edition: Ultimate, Enterprise, or Team Edition
- API Access: VersionOne REST Data API v1 or Meta API
- Access Token: Admin-level access token from VersionOne settings
- Data Export Rights: Permissions to query all portfolio items, backlog items, and custom attributes
- API Version: VersionOne 2018 or later recommended
Target System (Azure DevOps)
- Process Template: Agile or custom process with Epic hierarchy support
- Inherited Process: Ability to customize work item types and add custom fields
- PAT Token: Full scopes for Work Items, Test Management, and Analytics
- Storage Quota: Sufficient for attachments and work item count
Critical Requirement:
VersionOne migrations require custom Azure DevOps process templates. You cannot use default Agile,
Scrum, or CMMI templates without customization. OpsMigrator will help create the necessary custom fields.
Setting Up Connectors
1 VersionOne Connector Setup
Generate VersionOne Access Token
- Log in to VersionOne as Administrator
- Navigate to Admin → Applications → Application Manager
- Click Add Application
- Configure:
- Name: OpsMigrator Integration
- Client Type: Service Account
- Scopes: query:*, story:read, epic:read, defect:read, test:read, member:read
- Copy the generated Client ID and Secret
Configure VersionOne Connector
{
"connectorType": "VersionOne",
"name": "Production V1",
"baseUrl": "https://www.versionone.com/YourInstance",
"authentication": {
"authMethod": "OAuth",
"clientId": "YOUR_CLIENT_ID",
"clientSecret": "YOUR_CLIENT_SECRET",
"scope": "query:*"
},
"rateLimiting": {
"maxRequestsPerSecond": 20,
"retryAttempts": 5,
"backoffMultiplier": 3
},
"options": {
"apiVersion": "2018",
"includeClosedItems": true,
"includeTests": true,
"includeCustomAttributes": true,
"maxDepth": 6,
"batchSize": 100
}
}
2 Azure DevOps Connector Setup
(Same as Jira Cloud → ADO migration - see that documentation for PAT generation)
{
"connectorType": "AzureDevOps",
"name": "Production ADO",
"baseUrl": "https://dev.azure.com/your-organization",
"authentication": {
"authMethod": "PAT",
"secretValue": "YOUR_PAT_TOKEN"
},
"options": {
"targetProject": "MigratedFromV1",
"processTemplate": "CustomAgile_V1Migration",
"createCustomFields": true,
"preserveHierarchy": true,
"bypassRules": true
}
}
Portfolio Hierarchy Mapping
VersionOne's 6-level hierarchy must be intelligently collapsed into Azure DevOps' 3-level structure.
Hierarchy Transformation Strategy
| VersionOne Level |
Azure DevOps Mapping |
Strategy |
| Theme |
Epic (L3) |
Highest portfolio level mapped to Level 3 Epic |
| Initiative |
Epic (L2) |
Child of Theme Epic |
| Epic |
Epic (L1) |
Child of Initiative Epic |
| Story |
User Story |
Child of Epic, standard mapping |
| Task |
Task |
Child of Story, direct mapping |
| Test |
Test Case |
Linked to Story via Tested By relationship |
| Defect |
Bug |
Direct mapping, linked to affected items |
Hierarchy Preservation:
OpsMigrator maintains all parent-child relationships during transformation. Custom tags are added
to identify original VersionOne levels (e.g., "V1-Theme", "V1-Initiative", "V1-Epic").
Alternative Flattening Strategy
For organizations preferring simpler hierarchy:
- Option A: Merge Theme + Initiative into single L2 Epic
- Option B: Use Tags to represent Theme/Initiative instead of Epic levels
- Option C: Custom "PortfolioLevel" field to preserve original structure
Decision Required:
Hierarchy mapping strategy must be decided during planning phase. Changing mid-migration requires
complete restart. OpsMigrator AI recommends Option A for most organizations.
Migration Process
1 Discovery & Analysis (3-5 days)
- Connect to VersionOne and scan entire portfolio structure
- Analyze custom attribute usage across 100+ fields
- Generate hierarchy transformation plan
- Identify red flags and dependencies
- Calculate migration complexity score
2 Azure DevOps Process Customization (2-3 days)
- Create custom process inherited from Agile
- Add VersionOne-specific custom fields (typical: 40-60 fields)
- Configure work item types for hierarchy support
- Set up area paths and iteration paths
- Configure workflow states matching V1 statuses
3 Configuration Phase (3-4 days)
- Custom Attribute Mapping: Map each V1 custom attribute to ADO field
- User Mapping: Critical - V1 member IDs to ADO user identities
- Team Mapping: V1 teams to ADO teams with area path assignments
- Sprint Mapping: V1 timeboxes to ADO iterations
- Status Workflow: Map V1 status values to ADO states
4 Pilot Migration (5-7 days)
- Select 1-2 small teams (2,000-5,000 items)
- Execute portfolio-aware migration (top-down hierarchy)
- Deep validation of hierarchy preservation
- User acceptance testing with pilot teams
- Refine mappings based on feedback
5 Production Migration (7-14 days)
- Migrate in phases by portfolio level:
- Phase 1: Themes and Initiatives (Epic L3, L2)
- Phase 2: Epics (Epic L1)
- Phase 3: Stories and Defects
- Phase 4: Tasks
- Phase 5: Test Cases and Relationships
- Validate each phase before proceeding to next
- Monitor for memory/performance issues
Time Expectation:
Large VersionOne instances (100K+ items) may take 3-4 weeks. This is normal due to API rate limits
and validation requirements. Budget adequate time for this migration.
Custom Field Transformation
VersionOne organizations typically have 80-150 custom attributes. OpsMigrator intelligently transforms
these to Azure DevOps custom fields.
Common Custom Attribute Patterns
| V1 Attribute Type |
ADO Field Type |
Transformation Notes |
| Text |
String (Single Line) |
Direct copy, 255 char limit enforced |
| LongText |
String (Multi Line / HTML) |
Preserve formatting |
| Number |
Double / Integer |
Preserve precision |
| Date |
DateTime |
Timezone conversion applied |
| Relation (Single) |
Identity |
User mapping required |
| Relation (Multiple) |
Tags / Custom Multi-User |
May require custom field |
| State |
Picklist (String) |
Allowed values created |
| Boolean |
Boolean |
Direct mapping |
Custom Attribute Consolidation
OpsMigrator AI identifies opportunities to consolidate redundant custom attributes:
- Similar Attributes: Merge attributes with >90% name similarity
- Unused Attributes: Flag attributes with <1% population for exclusion
- Duplicate Values: Identify picklists with duplicate allowed values
- Recommendation Engine: Suggest consolidation to stay within ADO limits
Red Flags & Critical Issues
Deep Hierarchy Cycles
Issue: Circular portfolio relationships detected
Mitigation: Break cycles, log warnings, notify for manual review
Custom Field Overflow
Issue: >1024 custom attributes (ADO limit)
Mitigation: Mandatory consolidation or data archival
Orphaned Portfolio Items
Issue: Epics/Themes without parent relationships
Mitigation: Create "Unassigned" Epic at top level
Member Identity Gaps
Issue: V1 members without matching ADO users
Mitigation: Critical - must resolve before migration
Historical Data Volume
Issue: Excessive change history (>1M records)
Mitigation: Archive old history or increase timeout limits
Test Asset Complexity
Issue: V1 test structure doesn't map to ADO test plans
Mitigation: Flatten test hierarchy, use test suites
Migration Blockers:
Unlike other migrations, VersionOne migrations have potential blockers that must be resolved:
- Custom field count exceeding ADO limits (must consolidate)
- Missing user mappings for critical members (must create accounts)
- Corrupted hierarchy data (must clean source data)
OpsMigrator will halt migration if blockers detected. Manual intervention required.
Best Practices
Pre-Migration Best Practices
- Data Cleanup: Archive inactive projects, close obsolete items (critical for V1)
- Custom Attribute Audit: Document purpose of each custom attribute before migration
- Hierarchy Review: Validate portfolio structure integrity in VersionOne
- User Census: Comprehensive user mapping file prepared in advance
- Dedicated Consultant: Strongly recommended for first-time V1 migrations
During Migration
- Phase-by-Phase Validation: Never proceed to next phase without validation
- Memory Monitoring: Watch for memory issues with large hierarchies
- Relationship Audits: Spot-check parent-child relationships frequently
- Performance Tuning: Adjust batch sizes if timeouts occur
Post-Migration
- Extensive Training: V1 → ADO requires significant user re-training
- Query Migration: Recreate V1 saved queries as ADO work item queries
- Dashboard Recreation: V1 dashboards must be manually recreated in ADO
- Integration Updates: Update integrations pointing to V1 APIs
Success Story:
A Fortune 100 financial services company migrated 287,000 VersionOne items to Azure DevOps over
4 weeks with 96.8% data accuracy using OpsMigrator with dedicated consulting.
Frequently Asked Questions
Why is this migration so complex?
VersionOne's data model is fundamentally different from Azure DevOps. Deep portfolio hierarchies,
extensive custom attributes, and tight team-portfolio coupling require sophisticated transformation
logic. Most organizations underestimate the effort required.
Can we use the default Agile template?
No. VersionOne migrations require custom process templates with additional custom fields and hierarchy
support. OpsMigrator will create this for you, but attempting to use default templates will result
in significant data loss.
How long will our team be unable to work?
Zero downtime. Teams continue working in VersionOne during migration. We recommend a 1-week parallel
running period post-migration for user adoption, then cutover to Azure DevOps.
What happens to VersionOne integrations?
All integrations must be reconfigured to Azure DevOps APIs. OpsMigrator provides an integration mapping
guide, but actual reconfiguration is customer responsibility. Budget 1-2 weeks for integration updates.
Is there a simplified migration option?
Yes - you can choose to flatten the portfolio hierarchy (merge Themes/Initiatives) and exclude
rarely-used custom attributes. This reduces complexity to "High" instead of "Critical" and can save
1-2 weeks of migration time.
What's the recommended team size for this migration?
Minimum: Migration Lead (1), Azure DevOps Admin (1), VersionOne Admin (1), OpsMigrator Consultant (1).
Recommended: Add Testing Lead (1), Change Management (1) for smoother execution.
Do you offer dedicated consulting for VersionOne migrations?
Yes, and we strongly recommend it. VersionOne migrations have numerous decision points requiring
expertise. Our Enterprise plan includes a dedicated migration architect for the entire project lifecycle.
Contact admin@opsmigrator.in for consultation.
Need Expert Help with VersionOne Migration?
VersionOne migrations are complex. Let our certified migration architects guide you through every step.
Back to All Migration Scenarios