Azure DevOps에서 Jira로 이동하는 것은 데이터를 실제로 매핑하기 시작하기 전까지는 간단해 보입니다.

문제는 작업 항목 (Work items)을 내보내는 것이 아닙니다. 소프트웨어 프로젝트를 조직하는 두 가지 서로 다른 방식을 번역하는 것이 문제입니다. Azure DevOps와 Jira는 서로 다른 이슈 계층 구조 (Issue hierarchies), 워크플로 (Workflows), ID 모델 (Identity models), 그리고 프로젝트 구조를 사용합니다. 단순히 한 곳에서 다른 곳으로 데이터를 복사하기만 한다면, 관계가 누락되거나, 히스토리가 손실되거나, 더 이상 의미가 없는 워크플로가 생성될 가능성이 높습니다.

기업 합병, Atlassian 생태계로의 전환, 또는 광범위한 도구 통합 등으로 인해 발생하는 동일한 마이그레이션 패턴을 반복해서 보아왔습니다.

이 가이드는 그 과정을 단계별로 안내합니다.

요약 (TL;DR)

성공적인 Azure DevOps에서 Jira로의 마이그레이션은 일반적으로 다음을 포함합니다:

• 마이그레이션 전 Azure DevOps 프로젝트 감사 (Auditing)
• 작업 항목 유형 (Work item types)을 Jira 이슈 유형 (Issue types)으로 매핑
• 워크플로 (Workflows), 반복 (Iterations), 커스텀 필드 (Custom fields) 번역
• Microsoft Entra ID와 Jira 계정 간의 사용자 ID 매핑
• 적절한 마이그레이션 방식 선택 (CSV, REST APIs, 또는 마이그레이션 도구)
• 먼저 파일럿 마이그레이션 (Pilot migration) 실행
• 전환 (Cutover) 전 모든 사항 검증
• 두 시스템을 무기한으로 운영하는 대신 계획된 날짜에 Jira로 전환

마이그레이션 자체는 대개 어려운 부분이 아닙니다. 계획이 어렵습니다.

1단계: Azure DevOps 프로젝트 감사하기

Jira를 건드리기 전에, 정확히 무엇을 마이그레이션하고 있는지 이해해야 합니다.

다음 항목들을 수집하는 것부터 시작하세요:

• 작업 항목 유형 (Work item types)
• 작업 항목 수
• 커스텀 필드 (Custom fields)
• 첨부 파일 (Attachments)
• 댓글 (Comments)
• 영역 경로 (Area Paths)
• 반복 (Iterations)
• 부모-자식 관계 (Parent-child relationships)
• 연결된 작업 항목 (Linked work items)

이 시기는 Azure DevOps 프로젝트를 정리하기에도 좋은 때입니다.

다음 사항들을 확인하세요:

• 깨진 링크 (Broken links)
• 누락된 필수 필드 (Missing required fields)
• 유효하지 않은 사용자 (Invalid users)
• 더 이상 사용되지 않는 커스텀 필드 (Obsolete custom fields)
• 더 이상 존재하지 않는 첨부 파일 (Attachments)

마이그레이션 전에 이를 정리하는 것이 나중에 수정하는 것보다 훨씬 쉽습니다.

2단계: Azure DevOps 작업 항목을 Jira 이슈 유형으로 매핑하기

첫 번째 설계 결정 사항은 Azure DevOps 작업 항목(work items)을 Jira로 어떻게 변환할지 결정하는 것입니다.

일반적인 매핑은 다음과 같습니다:

가장 큰 고민거리는 보통 Feature(기능)입니다.

Azure DevOps와 달리, Jira에는 기본 Feature 이슈 유형(issue type)이 포함되어 있지 않습니다. 대부분의 조직은 다음 중 하나를 선택합니다:

• Feature를 Epic(에픽)으로 매핑하거나,
• 사용자 정의 Feature 이슈 유형을 생성하거나
• 마이그레이션이 시작되기 전에 해당 결정을 내립니다.
• 마이그레이션 도중에 이를 변경하면 불필요한 재작업이 발생합니다.

3단계: 워크플로 (workflows) 변환

워크플로가 완벽하게 일치하는 경우는 드뭅니다.

예를 들어:

Azure DevOps
New (신규)
↓
Active (활성)
↓
Resolved (해결됨)
↓
Closed (닫힘)

일반적인 Jira 워크플로
To Do (할 일)
↓
In Progress (진행 중)
↓
Done (완료)

만약 Azure DevOps 프로세스에 다음과 같은 사용자 정의 상태(custom states)가 포함되어 있다면:

• In Review (검토 중)
• QA Testing (QA 테스트 중)
• Blocked (차단됨)
• Ready for Release (릴리스 준비 완료)

이러한 상태들을 Jira의 사용자 정의 상태(custom statuses)로 만들지, 아니면 기존 상태에 매핑할지 결정해야 합니다.

사용자 정의 필드(custom fields)에도 동일하게 적용됩니다. 모든 필드는 Jira 내에 목적지가 있어야 합니다. 매핑되지 않은 필드가 반드시 오류를 발생시키는 것은 아니지만, 마이그레이션 후에 단순히 나타나지 않게 됩니다.

4단계: 반복(iterations) 및 영역 경로(area paths) 매핑

Azure DevOps는 Jira에 직접적으로 존재하지 않는 두 가지 개념을 사용합니다.

• Iterations (반복)
• Iterations는 일반적으로 Jira의 Sprint (스프린트)가 됩니다.

여러 팀이 Iterations를 공유하는 경우, Jira 보드(boards)가 이를 올바르게 나타내는지 확인하십시오.

Area Paths (영역 경로)

Area Paths는 종종 다음과 같이 변환됩니다:

• Components (컴포넌트)
• Labels (레이블)
• Custom fields (사용자 정의 필드)

올바른 선택은 현재 조직에서 Area Paths를 어떻게 사용하는지에 따라 달라집니다.

5단계: 사용자 ID (user identities) 매핑

이 단계는 자주 간과되곤 합니다.

• Azure DevOps는 Microsoft Entra ID를 통해 사용자를 식별합니다.
• Jira Cloud는 Atlassian 계정 ID를 사용하여 사용자를 식별합니다.

이러한 ID들은 서로 호환되지 않습니다.

마이그레이션 전에 Azure DevOps 사용자(users)와 Jira 계정(accounts) 간의 매핑(mapping)을 구축하십시오.

이메일 주소(Email addresses)가 일반적으로 가장 안전한 매칭 방법입니다.

사용자 매핑(user mapping)이 없으면 다음과 같은 문제가 발생할 수 있습니다:

• 담당자(assignees) 누락
• 잘못된 보고자(reporters)
• 소유권 이력(ownership history) 유실

6단계: 마이그레이션 접근 방식 선택

단 하나의 최선인 마이그레이션 방법은 없습니다.

올바른 선택은 데이터의 종류와 보존해야 할 이력(history)의 양에 따라 달라집니다.

옵션 1: CSV 가져오기 (CSV import)

다음의 경우에 가장 적합합니다:

• 소규모 프로젝트
• 단순한 백로그 (backlogs)
• 최소한의 이력 데이터

장점:

• 1. 사용하기 쉬움
• 2. 코딩이 필요 없음

한계:

• 제한된 이력
• 댓글(comments) 포함 불가
• 제한적인 첨부 파일(attachment) 지원
• 관계 매핑(Relationship mapping)이 어려울 수 있음

옵션 2: REST API

Azure DevOps와 Jira 모두 포괄적인 REST API를 제공합니다.

이 접근 방식은 최대의 유연성을 제공합니다.

다음 사항들을 직접 처리해야 합니다:

• 인증 (Authentication)
• 페이지네이션 (Pagination)
• 속도 제한 (Rate limits)
• 첨부 파일 (Attachments)
• 댓글 (Comments)
• 관계 (Relationships)
• 재시도 로직 (Retry logic)
• 검증 (Validation)

강력한 방법이지만, 그만큼 엔지니어링 노력(engineering effort)이 필요합니다.

옵션 3: 전용 마이그레이션 도구 (Dedicated migration tools)

**OpsHub Migration Manager (OMM)**와 같이 특정 목적을 위해 제작된 마이그레이션 도구는 두 시스템에 직접 연결되어 마이그레이션 프로세스의 상당 부분을 자동화합니다.

이러한 마이그레이션 도구(OMM 등)는 일반적으로 다음을 지원합니다:

• 필드 매핑 (Field mapping)
• 워크플로 매핑 (Workflow mapping)
• 사용자 매핑 (User mapping)
• 첨부 파일 (Attachments)
• 댓글 (Comments)
• 전체 이력 (Complete history)
• 관계 보존 (Relationship preservation)

데이터 충실도(data fidelity)가 중요한 대규모 마이그레이션의 경우, 이들이 종종 선호되는 옵션입니다.

OMM을 통한 Azure DevOps에서 Jira로의 마이그레이션에 대해 자세히 알아보기.

7단계: 파일럿 마이그레이션 (Pilot migration) 실행

처음부터 모든 것을 마이그레이션하지 마십시오.
다음 항목을 선택하십시오:

• 하나의 프로젝트
• 하나의 팀
• 대표적인 하위 집합 (Representative subset)

그런 다음 마이그레이션된 모든 이슈 (issue)를 원본과 비교하십시오.
다음 사항을 검증하십시오:

• 필드 (Fields)
• 댓글 (Comments)
• 첨부 파일 (Attachments)
• 상태 (Status)
• 히스토리 (History)
• 링크 (Links)
• 부모-자식 관계 (Parent-child relationships)

이 단계에서 대부분의 매핑 (mapping) 문제가 발견됩니다.

8단계: 전체 마이그레이션 검증

파일럿이 성공하면, 더 큰 규모의 마이그레이션을 신중하게 검증하십시오.

다음 사항을 확인하십시오:

• 작업 항목 (Work item) 개수가 일치하는지
• 첨부 파일이 올바르게 열리는지
• 댓글이 완전한지
• 작성자 (Authors)가 정확한지
• 날짜가 보존되었는지
• 링크가 여전히 작동하는지
• 스프린트 (Sprint) 할당이 정확한지
• 사용자 정의 필드 (Custom fields)가 올바르게 마이그레이션되었는지

자동화된 보고서에만 의존하지 마십시오.

실제 이슈를 무작위로 점검(Spot-check)하십시오.

9단계: 전환 (Cutover) 계획

결국 명확한 전환이 필요합니다.

전환 날짜를 선택하십시오. 그 시점부터:

• Azure DevOps에서 작업 생성을 중단합니다.
• 진행 중인 작업을 Jira로 이동합니다.
• 과거 참조가 필요한 경우 Azure DevOps를 읽기 전용 (read-only)으로 유지합니다.

두 시스템을 모두 활성 소스로 운영하는 것은 대개 동기화 문제와 혼란을 야기합니다.

무료 마이그레이션 데모 슬롯을 예약하세요.

일반적인 마이그레이션 실수

이러한 문제들은 많은 Azure DevOps에서 Jira로의 마이그레이션 중에 나타납니다:

• 댓글과 히스토리 (history) 보존이 중요한 상황에서 CSV를 사용하는 경우
• 사용자 정의 필드 (custom fields) 매핑을 잊는 경우
• 사용자 ID 매핑 (user identity mapping)을 무시하는 경우
• 파일럿 마이그레이션 (pilot migration)을 건너뛰는 경우
• 연결된 작업 항목 (linked work items)을 마이그레이션 범위에서 제외하는 경우
• 워크플로 (workflows)가 자동으로 변환될 것이라고 가정하는 경우

대부분의 마이그레이션 문제는 마이그레이션 자체 때문에 발생하지 않습니다.

그것은 계획 단계의 가정들 때문에 발생합니다.

자주 묻는 질문 (Frequently Asked Questions)

Q1) Azure DevOps의 댓글을 Jira로 마이그레이션할 수 있나요?

답 1) 네. 하지만 CSV 임포트 (import) 방식은 댓글 히스토리를 보존하지 못합니다. API 기반 마이그레이션 및 전용 마이그레이션 도구들은 일반적으로 댓글, 작성자, 그리고 타임스탬프 (timestamps)를 마이그레이션할 수 있습니다.

Q2) Azure DevOps의 Feature가 Jira로 직접 매핑되나요?

답 2) 아니요. 대부분의 팀은 Feature를 Epic으로 매핑하거나, Jira의 사용자 정의 이슈 유형 (custom Jira issue type)을 생성합니다.

Q3) 사용자는 어떻게 매핑해야 하나요?

답 3) 가장 신뢰할 수 있는 방법은 마이그레이션을 시작하기 전에 이메일 주소를 사용하여 Azure DevOps 사용자를 Jira 계정과 일치시키는 것입니다.

Q4) Azure DevOps에서 Jira로의 마이그레이션에는 시간이 얼마나 걸리나요?

답 4) 다음 요소들에 따라 달라집니다:

• 작업 항목 (work items)의 수
• 첨부 파일 (attachments)
• 히스토리 데이터 (historical data)
• 사용자 정의 사항 (customizations)
• 검증 노력 (validation effort)

파일럿 테스트를 포함한 단계별 마이그레이션이 모든 것을 한꺼번에 마이그레이션하는 것보다 일반적으로 더 예측 가능합니다.

Q5) 마이그레이션을 테스트하는 가장 안전한 방법은 무엇인가요?

답 5) 소규모 프로젝트나 대표적인 데이터 세트에서 파일럿을 실행하여 결과를 철저히 검증한 다음, 매핑이 확인되면 규모를 확대하십시오.

마치며

Azure DevOps에서 Jira로의 마이그레이션은 단순히 한 플랫폼에서 다른 플랫폼으로 데이터를 복사하는 것이 아닙니다.

그것은 팀이 업무를 조직하고, 협업하며, 진행 상황을 추적하는 방식을 번역하는 과정입니다.

마이그레이션 전에 작업 항목 유형 (work item types), 워크플로 (workflows), 사용자 정의 필드 (custom fields), 사용자, 그리고 프로젝트 구조를 매핑하는 데 시간을 투자하는 것이, 나중에 누락되거나 일관성 없는 데이터를 복구하려고 시도하는 것보다 훨씬 더 많은 시간을 절약해 줄 것입니다.

이전(move)이 기업 합병, Jira를 통한 전사적 표준화, 또는 더 광범위한 도구 통합(tool consolidation)에 의해 추진되든 관계없이, 세심한 계획과 점진적인 검증(incremental validation)은 마이그레이션을 훨씬 더 예측 가능하게 만들고 스트레스를 훨씬 덜 받게 해줍니다.

만약 이 마이그레이션을 계획 중이며 워크플로(workflows) 매핑, 히스토리(history) 보존, 또는 적절한 마이그레이션 접근 방식 선택에 대해 궁금한 점이 있다면 댓글로 남겨주세요. 함께 논의해 봅시다.