테스트 실행 마이그레이션 수행

아티클
05/21/2024

이제 팀에서 마이그레이션 테스트 실행을 시작한 다음 최종적으로 전체 프로덕션 마이그레이션을 시작하는 프로세스를 시작할 준비가 되었습니다. 이 단계에서는 일반적으로 마이그레이션 프로젝트가 끝날 때 발생하는 다른 작업 외에도 마이그레이션을 큐에 대기하는 최종 단계에 대해 설명합니다.

순차적 단계에서 필수 구성 요소 단계를 강조 표시하는 다이어그램

필수 조건

테스트 실행 마이그레이션을 시작하기 전에 테스트 실행 준비 단계를 완료합니다.

컬렉션 유효성 검사

Azure DevOps Services로 마이그레이션하려는 각 컬렉션의 유효성을 검사합니다. 유효성 검사 단계에서는 크기, 데이터 정렬, ID 및 프로세스를 비롯하여 컬렉션의 다양한 측면을 검사합니다.

데이터 마이그레이션 도구를 사용하여 유효성 검사를 실행합니다.

데이터 마이그레이션 도구를 다운로드합니다.
Zip 파일을 Azure DevOps Server 애플리케이션 계층 중 하나에 복사합니다.
파일의 압축을 풉니다. Azure DevOps Server 인스턴스의 구성 데이터베이스에 연결할 수 있는 한 Azure DevOps Server를 설치하지 않고 다른 컴퓨터에서 도구를 실행할 수도 있습니다.
서버에서 명령 프롬프트 창을 열고 cd 명령을 입력하여 데이터 마이그레이션 도구가 저장된 디렉터리로 변경합니다. 잠시 시간을 내어 도구에 대한 도움말 콘텐츠를 검토합니다.

a. 최상위 도움말 및 지침을 보려면 다음 명령을 실행합니다.
```
 Migrator /help
```
b. 명령에 대한 도움말 텍스트를 봅니다.
```
 Migrator validate /help 
```
컬렉션의 유효성을 처음으로 검사할 때 명령에는 다음과 같은 간단한 구조가 있어야 합니다.
```
 Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
```
예를 들어 DefaultCollection 및 fabrikam 테넌트에 대해 실행하기 위해 Microsoft Entra 테넌트의 이름을 제공하는 경우 {name} 명령은 다음 예제와 같습니다.
```
 Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
```
Azure DevOps Server 이외의 컴퓨터에서 도구를 실행하려면 /connectionString 매개 변수가 필요합니다. 연결 문자열 매개 변수는 Azure DevOps Server 구성 데이터베이스를 가리킵니다. 예를 들어 유효성이 검사된 명령이 Fabrikam 회사에서 실행되는 경우 명령은 다음과 같습니다.
```
 Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
```
Important

데이터 마이그레이션 도구 는 컬렉션의 데이터 또는 구조를 편집하지 않습니다. 문제를 식별하기 위해서만 컬렉션을 읽습니다.
유효성 검사가 완료되면 로그 파일 및 결과를 볼 수 있습니다.

유효성 검사 중에 일부 파이프라인에 파이프라인별 보존 규칙이 포함된 경우 경고가 표시됩니다. Azure DevOps Services는 프로젝트 기반 보존 모델을 사용하며 파이프라인별 보존 정책을 지원하지 않습니다. 마이그레이션을 진행하는 경우 정책은 호스트된 버전으로 전달되지 않습니다. 대신 기본 프로젝트 수준 보존 정책이 적용됩니다. 손실을 방지하기 위해 중요한 빌드를 유지합니다.

모든 유효성 검사가 통과되면 마이그레이션 프로세스의 다음 단계로 이동할 수 있습니다. 데이터 마이그레이션 도구에서 오류에 플래그를 지정하는 경우 계속하기 전에 오류를 수정합니다. 유효성 검사 오류 수정에 대한 지침은 마이그레이션 및 마이그레이션 오류 문제 해결을 참조 하세요.

로그 파일 가져오기

로그 디렉터리를 열면 여러 로깅 파일이 표시될 수 있습니다.

주 로그 파일의 이름은 DataMigrationTool.log. 실행된 모든 항목에 대한 세부 정보가 포함되어 있습니다. 특정 영역에 더 쉽게 집중할 수 있도록 각 주요 유효성 검사 작업에 대한 로그가 생성됩니다.

예를 들어 TfsMigrator가 "프로젝트 프로세스 유효성 검사" 단계에서 오류를 보고하는 경우 ProjectProcessMap.log 파일을 열어 전체 로그를 스크롤하지 않고도 해당 단계에 대해 실행된 모든 항목을 볼 수 있습니다.

상속된 모델을 사용하도록 프로젝트 프로세스를 마이그레이션하려는 경우에만 TryMatchOobProcesses.log 파일을 검토합니다. 상속된 모델을 사용하지 않으려면 Azure DevOps Services로 가져올 수 없으므로 이러한 오류를 무시할 수 있습니다. 자세한 내용은 마이그레이션의 유효성 검사 단계를 참조하세요.

마이그레이션 파일 생성

데이터 마이그레이션 도구는 컬렉션의 유효성을 검사했으며 "통과된 모든 컬렉션 유효성 검사"의 결과를 반환했습니다. 컬렉션을 오프라인으로 마이그레이션하기 전에 마이그레이션 파일을 생성합니다. 명령을 실행 prepare 하면 다음 두 개의 마이그레이션 파일을 생성합니다.

IdentityMapLog.csv: Active Directory와 Microsoft Entra ID 간의 ID 맵을 간략하게 설명합니다.
migration.json: 마이그레이션을 시작하는 데 사용할 마이그레이션 사양을 작성해야 합니다.

준비 명령

이 prepare 명령은 필요한 마이그레이션 파일을 생성하는 데 도움이 됩니다. 기본적으로 이 명령은 컬렉션을 검색하여 ID 맵 로그, IdentityMapLog.csv 채울 모든 사용자 목록을 찾은 다음 Microsoft Entra ID에 연결하여 각 ID의 일치 항목을 찾습니다. 이렇게 하려면 회사에서 Microsoft Entra Connect 도구(이전의 디렉터리 동기화 도구, 디렉터리 동기화 도구 또는 DirSync.exe 도구)를 사용해야 합니다.

디렉터리 동기화가 설정된 경우 데이터 마이그레이션 도구는 일치하는 ID를 찾아 활성으로 표시해야 합니다. 일치하는 항목이 없으면 ID가 ID 맵 로그에 기록으로 표시되므로 사용자가 디렉터리 동기화에 포함되지 않은 이유를 조사해야 합니다. 마이그레이션 사양 파일인 migration.json 마이그레이션 전에 채워야 합니다.

명령 prepare 과 validate 달리 ID 맵 로그 파일을 채우기 위해 Microsoft Entra ID에 연결해야 하므로 인터넷 연결이 필요합니다. Azure DevOps Server 인스턴스에 인터넷 액세스 권한이 없는 경우 해당 컴퓨터에서 도구를 실행합니다. Azure DevOps Server 인스턴스에 대한 인트라넷 연결 및 인터넷 연결이 있는 컴퓨터를 찾을 수 있는 한 이 명령을 실행할 수 있습니다. 명령에 대한 도움말을 prepare 보려면 다음 명령을 실행합니다.

Migrator prepare /help

도움말 설명서에는 Azure DevOps Server 인스턴스 자체 및 원격 컴퓨터에서 명령을 실행 Migrator 하기 위한 지침과 예제가 포함되어 있습니다. Azure DevOps Server 인스턴스의 애플리케이션 계층 중 하나에서 명령을 실행하는 경우 명령에는 다음과 같은 구조가 있어야 합니다.

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

connectionString 매개 변수는 Azure DevOps Server 인스턴스의 구성 데이터베이스에 대한 포인터입니다. 예를 들어 Fabrikam corporation이 명령을 실행하는 prepare 경우 명령은 다음 예제와 같습니다.

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Data Migration Tool이 명령을 실행 prepare 하면 전체 유효성 검사를 실행하여 마지막 전체 유효성 검사 이후 컬렉션에서 변경된 내용이 없는지 확인합니다. 새 문제가 검색되면 마이그레이션 파일이 생성되지 않습니다.

명령 실행이 시작된 직후 Microsoft Entra 로그인 창이 표시됩니다. 명령에 지정된 테넌트 도메인에 속하는 ID로 로그인합니다. 지정된 Microsoft Entra 테넌트가 향후 조직을 지원하려는 테넌트인지 확인합니다. Fabrikam 예제에서 사용자는 다음 예제 스크린샷과 유사한 자격 증명을 입력합니다.

Important

테스트 마이그레이션에는 테스트 Microsoft Entra 테넌트를 사용하고 프로덕션 실행에는 프로덕션 Microsoft Entra 테넌트를 사용하지 마세요. 테스트 Microsoft Entra 테넌트를 사용하면 조직의 프로덕션 Microsoft Entra 테넌트로 프로덕션 실행을 시작할 때 ID 마이그레이션 문제가 발생할 수 있습니다.

데이터 마이그레이션 도구에서 명령을 성공적으로 실행 prepare 하면 결과 창에 로그 집합과 두 개의 마이그레이션 파일이 표시됩니다. 로그 디렉터리에서 로그 폴더와 두 개의 파일을 찾습니다.

migration.json 마이그레이션 사양 파일입니다. 작성하는 데 시간이 걸리는 것이 좋습니다.
IdentityMapLog.csv Microsoft Entra ID에 대한 Active Directory의 생성된 매핑을 포함합니다. 마이그레이션을 시작하기 전에 완전성을 검토합니다.

두 파일은 다음 섹션에서 자세히 설명합니다.

마이그레이션 사양 파일

migration.json 마이그레이션 사양은 마이그레이션 설정을 제공하는 JSON 파일입니다. 여기에는 원하는 조직 이름, 스토리지 계정 정보 및 기타 정보가 포함됩니다. 대부분의 필드는 자동 채워지고 일부 필드는 마이그레이션을 시도하기 전에 입력이 필요합니다.

새로 생성된 마이그레이션 사양 파일의 스크린샷.

migration.json 파일의 표시된 필드와 필요한 작업은 다음 표에 설명되어 있습니다.

필드	설명	필요한 작업
Source	마이그레이션에 사용되는 원본 데이터 파일의 위치 및 이름에 대한 정보입니다.	작업이 필요하지 않습니다. 수행할 하위 필드 작업에 대한 정보를 검토합니다.
위치	DACPAC(데이터 계층 애플리케이션 패키지)를 호스트하는 Azure Storage 계정에 대한 공유 액세스 서명 키입니다.	작업이 필요하지 않습니다. 이 필드는 이후 단계에서 설명합니다.
Files	마이그레이션 데이터를 포함하는 파일의 이름입니다.	작업이 필요하지 않습니다. 수행할 하위 필드 작업에 대한 정보를 검토합니다.
DACPAC	마이그레이션 중에 데이터를 가져오는 데 사용할 컬렉션 데이터베이스를 패키지하는 DACPAC 파일입니다.	작업이 필요하지 않습니다. 이후 단계에서는 컬렉션을 사용하여 이 파일을 만든 다음 Azure Storage 계정에 업로드합니다. 이 프로세스의 뒷부분에서 생성할 때 사용하는 이름에 따라 파일을 업데이트합니다.
대상	마이그레이션할 새 조직의 속성입니다.	작업이 필요하지 않습니다. 수행할 하위 필드 작업에 대한 정보를 검토합니다.
속성	마이그레이션 중에 만들 조직의 이름입니다.	이름을 입력합니다. 마이그레이션이 완료된 후 나중에 이름을 빠르게 변경할 수 있습니다. 참고: 마이그레이션을 실행하기 전에 이 이름으로 조직을 만들지 마세요 . 조직은 마이그레이션 프로세스의 일부로 만들어집니다.
ImportType	실행하려는 마이그레이션 유형입니다.	작업이 필요하지 않습니다. 이후 단계에서 실행할 마이그레이션 유형을 선택합니다.
유효성 검사 데이터	마이그레이션 환경을 구동하는 데 필요한 정보입니다.	데이터 마이그레이션 도구는 "ValidationData" 섹션을 생성합니다. 마이그레이션 환경을 구동하는 데 도움이 되는 정보가 포함되어 있습니다. 이 섹션의 값을 편집하지 마세요. 그렇지 않으면 마이그레이션을 시작하지 못할 수 있습니다.

이전 프로세스를 완료한 후에는 다음 예제와 같은 파일이 있어야 합니다.

부분적으로 완료된 마이그레이션 사양 파일의 스크린샷

이전 이미지에서 Fabrikam 마이그레이션의 플래너는 조직 이름 fabrikam-import를 추가하고 선택한 CUS(중앙 미국)를 마이그레이션의 지리적 위치로 추가했습니다. 플래너가 마이그레이션을 위해 컬렉션을 오프라인으로 전환하기 직전에 수정할 다른 값이 그대로 남아 있었습니다.

참고 항목

테스트 실행 가져오기에는 조직 이름의 끝에 '-dryrun'이 자동으로 추가되므로 마이그레이션 후에 변경할 수 있습니다.

마이그레이션에 지원되는 Azure 지역

Azure DevOps Services는 여러 Azure 지리적 위치에서 사용할 수 있습니다. 그러나 Azure DevOps Services를 사용할 수 있는 모든 위치는 마이그레이션에 지원되지 않습니다. 다음 표에서는 마이그레이션을 위해 선택할 수 있는 Azure 지리적 위치를 나열합니다. 마이그레이션을 위해 해당 지리적 위치를 대상으로 지정하기 위해 마이그레이션 사양 파일에 배치해야 하는 값도 포함됩니다.

지리적 위치	Azure 지리적 위치	가져오기 사양 값
미국	중앙 미국	CUS
유럽	서유럽	WEU
영국	영국 남부	영국
오스트레일리아	오스트레일리아 동부	EAU
남아메리카	브라질 남부	SBR
아시아 태평양	인도 남부	MA
아시아 태평양	동남아시아(싱가포르)	SEA
캐나다	캐나다 중부	CC

ID 맵 로그

ID 맵 로그는 Azure DevOps Services로 마이그레이션하는 실제 데이터와 동일하게 중요합니다. 파일을 검토할 때 ID 마이그레이션이 작동하는 방식과 잠재적인 결과가 수반될 수 있는 결과를 이해하는 것이 중요합니다. ID를 마이그레이션하면 활성 또는 기록으로 전환될 수 있습니다. 활성 ID는 Azure DevOps Services에 로그인할 수 있지만 기록 ID는 로그인할 수 없습니다.

활성 ID

활성 ID는 마이그레이션 후 Azure DevOps Services의 사용자 ID를 참조합니다. Azure DevOps Services에서 이러한 ID는 라이선스가 부여되고 조직의 사용자로 표시됩니다. ID는 ID 맵 로그 파일의 예상 가져오기 상태 열에서 활성으로 표시됩니다.

기록 ID

기록 ID는 ID 맵 로그 파일의 예상 가져오기 상태 열에 매핑됩니다. 파일에 줄 항목이 없는 ID도 기록 상태가 됩니다. 줄 입력이 없는 ID의 예로는 회사에서 더 이상 근무하지 않는 직원이 있을 수 있습니다.

활성 ID와 달리 기록 ID:

마이그레이션 후에는 조직에 액세스할 수 없습니다 .
라이선스가 없습니다 .
조직에서 사용자로 표시되지 않습니다 . 그 기록은 나중에 검색할 수 있도록 조직에서 해당 ID의 이름에 대한 개념만 지속됩니다. 회사에서 더 이상 일하지 않거나 조직에 더 이상 액세스할 필요가 없는 사용자에게 기록 ID를 사용하는 것이 좋습니다.

참고 항목

ID를 기록 으로 가져온 후에는 활성화할 수 없습니다 .

ID 맵 로그 파일 이해

ID 맵 로그 파일은 여기에 표시된 예제와 유사합니다.

데이터 마이그레이션 도구에서 생성된 ID 맵 로그 파일의 스크린샷.

ID 맵 로그 파일의 열은 다음 표에 설명되어 있습니다.

사용자와 Microsoft Entra 관리자는 일치하는 항목이 없음으로 표시된 사용자를 조사하여(Microsoft Entra ID 동기화 확인) 사용자가 Microsoft Entra Connect 동기화에 속하지 않는 이유를 이해해야 합니다.

열	설명
Active Directory: 사용자(Azure DevOps Server)	Azure DevOps Server의 ID에서 사용하는 친숙한 표시 이름입니다. 이 이름을 사용하면 지도의 줄이 참조하는 사용자를 더 쉽게 식별할 수 있습니다.
Active Directory: 보안 식별자	Azure DevOps Server의 온-프레미스 Active Directory ID에 대한 고유 식별자입니다. 이 열은 컬렉션에서 사용자를 식별하는 데 사용됩니다.
Microsoft Entra ID: 예상 사용자 가져오기(Azure DevOps Services)	일치하는 곧 활성 상태가 될 사용자의 예상 로그인 주소 또는 찾을 수 없음(Microsoft Entra ID 동기화 확인)은 Microsoft Entra ID 동기화 중에 ID가 손실되고 기록으로 가져오기를 나타냅니다.
예상 가져오기 상태	예상 사용자 마이그레이션 상태: Active Directory와 Microsoft Entra ID 간에 일치하는 항목이 있는 경우 활성 또는 일치하는 항목이 없는 경우 기록 입니다.
유효성 검사 날짜	ID 맵 로그의 유효성을 마지막으로 검사한 시간입니다.

파일을 읽으면서 예상 가져오기 상태 열의 값이 활성인지 기록인지 확인합니다. 활성 은 마이그레이션 시 이 행의 ID가 올바르게 매핑된다는 것을 나타냅니다. 과거 는 ID가 마이그레이션에 대한 과거가 된다는 것을 의미합니다. 생성된 매핑 파일을 검토하여 완전성과 정확성을 확인해야 합니다.

Important

마이그레이션 시도 간에 Microsoft Entra Connect 보안 ID 동기화가 크게 변경되면 마이그레이션이 실패합니다. 테스트 실행 간에 새 사용자를 추가할 수 있으며 이전에 가져온 기록 ID가 활성화되도록 수정할 수 있습니다. 그러나 이전에 활성으로 가져온 기존 사용자는 변경할 수 없습니다. 이렇게 하면 마이그레이션이 실패합니다. 변경의 예로 테스트 실행 마이그레이션을 완료하고, 적극적으로 가져온 Microsoft Entra ID에서 ID를 삭제하고, 동일한 ID에 대해 Microsoft Entra ID에 새 사용자를 다시 만든 다음, 다른 마이그레이션을 시도할 수 있습니다. 이 경우 활성 ID 마이그레이션은 Active Directory와 새로 만든 Microsoft Entra ID 간에 시도하지만 마이그레이션 오류가 발생합니다.

올바르게 일치하는 ID를 검토합니다. 모든 예상 ID가 있나요? 사용자가 올바른 Microsoft Entra ID에 매핑되어 있나요?

값을 변경해야 하는 경우 Microsoft Entra 관리자에게 문의하여 온-프레미스 Active Directory ID가 Microsoft Entra ID에 대한 동기화의 일부인지 확인하고 올바르게 설정합니다. 자세한 내용은 Microsoft Entra ID와 온-프레미스 ID 통합을 참조하세요.
다음으로 기록으로 레이블이 지정된 ID를 검토합니다. 이 레이블 지정은 다음과 같은 이유로 일치하는 Microsoft Entra ID를 찾을 수 없음을 의미합니다.
- id는 온-프레미스 Active Directory Microsoft Entra ID 간의 동기화를 위해 설정되지 않았습니다.
- ID가 아직 Microsoft Entra ID에 채워지지 않았습니다(예: 새 직원이 있는 경우).
- ID가 Microsoft Entra 인스턴스에 없습니다.
- 해당 ID를 소유한 사용자는 더 이상 회사에서 작동하지 않습니다.

처음 세 가지 이유를 해결하려면 Microsoft Entra ID와 동기화할 의도된 온-프레미스 Active Directory ID를 설정합니다. 자세한 내용은 Microsoft Entra ID와 온-프레미스 ID 통합을 참조하세요. Id를 Azure DevOps Services에서 활성으로 가져오려면 Microsoft Entra Connect를 설정하고 실행해야 합니다.

회사에 더 이상 없는 직원을 기록으로 가져와야 하므로 네 번째 이유를 무시할 수 있습니다.

역사적 정체성(소규모 팀)

참고 항목

이 섹션에서 제안된 ID 마이그레이션 전략은 소규모 팀에서만 고려해야 합니다.

Microsoft Entra Connect가 구성되지 않은 경우 ID 맵 로그 파일의 모든 사용자가 기록으로 표시됩니다. 이러한 방식으로 마이그레이션을 실행하면 모든 사용자가 기록으로 가져옵니다. 사용자를 활성으로 가져오도록 Microsoft Entra Connect를 구성하는 것이 좋습니다.

모든 기록 ID를 사용하여 마이그레이션을 실행하면 신중하게 고려해야 하는 결과가 있습니다. 소수의 사용자와 Microsoft Entra Connect 설정 비용이 너무 높은 것으로 간주되는 팀만 고려해야 합니다.

모든 ID를 기록으로 마이그레이션하려면 이후 섹션에 설명된 단계를 수행합니다. 마이그레이션을 큐에 넣으면 마이그레이션을 큐에 대기하는 데 사용되는 ID가 조직 소유자 조직으로 부트스트랩됩니다. 다른 모든 사용자는 기록으로 가져옵니다. 조직 소유자는 Microsoft Entra ID를 사용하여 사용자를 다시 추가할 수 있습니다. 추가된 사용자는 새 사용자로 처리됩니다. 해당 기록은 소유하지 않으며 이 기록을 Microsoft Entra ID로 다시 배상할 수 있는 방법은 없습니다. 그러나 사용자는 여전히 자신의 미리 허용 기록을 검색하여 조회할 수 있습니다 \<domain>\<Active Directory username>.

데이터 마이그레이션 도구는 전체 기록 ID 시나리오를 감지하면 경고를 표시합니다. 이 마이그레이션 경로 아래로 이동하려는 경우 도구에서 제한 사항에 동의해야 합니다.

Visual Studio 구독

데이터 마이그레이션 도구는 ID 맵 로그 파일을 생성할 때 Visual Studio 구독(이전의 MSDN 혜택)을 검색할 수 없습니다. 대신 마이그레이션 후에 자동 라이선스 업그레이드 기능을 적용하는 것이 좋습니다. 사용자의 회사 계정이 올바르게 연결된 경우 Azure DevOps Services는 마이그레이션 후 첫 번째 로그인 시 Visual Studio 구독 혜택을 자동으로 적용합니다. 마이그레이션 중에 할당된 라이선스에 대해서는 요금이 청구되지 않으므로 나중에 구독을 안전하게 처리할 수 있습니다.

사용자의 Visual Studio 구독이 Azure DevOps Services에서 자동으로 업그레이드되지 않는 경우 테스트 실행 마이그레이션을 반복할 필요가 없습니다. Visual Studio 구독 연결은 마이그레이션 범위 외부에서 발생합니다. 마이그레이션 전후에 회사 계정이 올바르게 연결된 경우 사용자의 라이선스는 다음 로그인 시 자동으로 업그레이드됩니다. 라이선스가 성공적으로 업그레이드되면 다음에 마이그레이션을 실행할 때 사용자가 조직에 대한 첫 번째 로그인 시 자동으로 업그레이드됩니다.

마이그레이션 준비

이제 테스트 실행 마이그레이션에서 실행할 준비가 되었습니다. 팀과 함께 가동 중지 시간을 예약하여 마이그레이션을 위해 컬렉션을 오프라인으로 전환합니다. 마이그레이션을 실행하는 데 동의하면 생성한 필수 자산과 데이터베이스 복사본을 Azure에 업로드합니다. 마이그레이션 준비는 다음 5단계로 구성됩니다.

1단계: 컬렉션을 오프라인으로 전환하고 분리합니다. 2단계: 마이그레이션하려는 컬렉션에서 DACPAC 파일을 생성합니다.
3단계: DACPAC 파일 및 마이그레이션 파일을 Azure Storage 계정에 업로드합니다.
4단계: 스토리지 계정에 액세스하는 SAS 토큰을 생성합니다.
5단계: 마이그레이션 사양을 완료합니다.

참고 항목

프로덕션 마이그레이션 을 수행하기 전에 테스트 실행 마이그레이션을 완료하는 것이 좋습니다. 테스트 실행을 사용하면 마이그레이션 프로세스가 컬렉션에 대해 작동하고 프로덕션 마이그레이션 실패를 일으킬 수 있는 고유한 데이터 셰이프가 없는지 확인할 수 있습니다.

1단계: 컬렉션 분리

컬렉션을 분리하는 것은 마이그레이션 프로세스에서 중요한 단계입니다. 컬렉션에 대한 ID 데이터는 컬렉션이 연결되고 온라인 상태가 되는 동안 Azure DevOps Server 인스턴스의 구성 데이터베이스에 상주합니다. 컬렉션이 Azure DevOps Server 인스턴스에서 분리되면 해당 ID 데이터의 복사본을 가져와서 전송을 위해 컬렉션과 함께 패키지합니다. 이 데이터가 없으면 마이그레이션 의 ID 부분을 실행할 수 없습니다 .

팁

마이그레이션 중에 발생한 변경 내용을 마이그레이션할 방법이 없으므로 마이그레이션이 완료될 때까지 컬렉션을 분리된 상태로 유지하는 것이 좋습니다. 마이그레이션을 위해 백업한 후 컬렉션을 다시 연결하므로 이러한 유형의 마이그레이션에 대한 최신 데이터를 보유할 필요가 없습니다. 오프라인 시간을 완전히 방지하려면 테스트 실행에 오프라인 분리를 사용하도록 선택할 수도 있습니다.

테스트 실행에 대해 가동 중지 시간이 0이 발생하도록 선택하는 비용을 평가하는 것이 중요합니다. 컬렉션 및 구성 데이터베이스의 백업을 수행하고 SQL 인스턴스에서 복원한 다음 분리된 백업을 만들어야 합니다. 비용 분석은 분리된 백업을 직접 수행하는 데 몇 시간만 걸리는 것이 결국 더 낫다는 것을 증명할 수 있습니다.

2단계: DACPAC 파일 생성

DACPAC는 컬렉션을 Azure DevOps Services로 이동하기 위한 빠르고 비교적 쉬운 방법을 제공합니다. 그러나 컬렉션 데이터베이스 크기가 특정 임계값을 초과하면 DACPAC 사용의 이점은 줄어들기 시작합니다.

참고 항목

데이터 마이그레이션 도구에 DACPAC 메서드를 사용할 수 없다는 경고가 표시되면 SQL Azure VM(가상 머신) 메서드를 사용하여 마이그레이션을 수행해야 합니다. 이 경우 2~5단계를 건너뛰고 테스트 실행 준비 단계, 대용량 컬렉션 마이그레이션 섹션의 지침을 따르고 마이그레이션 유형을 계속 확인합니다. 데이터 마이그레이션 도구에 경고가 표시되지 않는 경우 이 단계에서 설명한 DACPAC 메서드를 사용합니다.

DACPAC 는 데이터베이스를 단일 파일로 패키지하고 SQL Server의 다른 인스턴스에 배포할 수 있도록 하는 SQL Server의 기능입니다. DACPAC 파일을 Azure DevOps Services로 직접 복원할 수도 있으므로 컬렉션의 데이터를 클라우드에서 가져오는 패키징 방법으로 사용할 수 있습니다.

Important

SqlPackage.exe 사용하는 경우 .NET Framework 버전의 SqlPackage.exe 사용하여 DACPAC를 준비해야 합니다. .NET Framework 버전의 SqlPackage.exe 설치하려면 MSI 설치 관리자를 사용해야 합니다. 해당 버전이 Azure DevOps Services와 호환되지 않는 DACPAC를 생성할 수 있으므로 dotnet CLI 또는 .zip(Windows .NET 6) 버전의 SqlPackage.exe 사용하지 마세요.
SqlPackage 버전 161은 기본적으로 데이터베이스 연결 암호화하며 연결되지 않을 수 있습니다. 로그인 프로세스 오류가 표시되면 SqlPackage 문의 연결 문자열 추가 ;Encrypt=False;TrustServerCertificate=True 합니다.

SqlPackage 릴리스 정보에서 최신 MSI 설치 관리자를 사용하여 SqlPackage.exe 다운로드하고 설치합니다.

MSI 설치 관리자를 사용하면 SqlPackage.exe 다음과 유사한 %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\경로에 설치됩니다.

DACPAC를 생성할 때는 DACPAC가 저장된 디스크와 DACPAC를 생성하는 컴퓨터의 디스크 공간이라는 두 가지 고려 사항을 염두에 두어야 합니다. 작업을 완료하기에 충분한 디스크 공간이 있는지 확인하려고 합니다.

패키지를 만들 때 SqlPackage.exe 패키지 요청을 시작하는 컴퓨터의 C 드라이브에 있는 임시 디렉터리에 컬렉션의 데이터를 일시적으로 저장합니다.

드라이브 C가 너무 작아서 DACPAC를 만들 수 없습니다. 컬렉션 데이터베이스에서 가장 큰 테이블을 찾아 필요한 공간을 예측할 수 있습니다. DACPAC는 한 번에 하나의 테이블을 만듭니다. 생성을 실행하기 위한 최대 공간 요구 사항은 컬렉션 데이터베이스에서 가장 큰 테이블의 크기와 거의 동일합니다. 생성된 DACPAC를 저장하여 C를 구동하는 경우 유효성 검사 실행에서 DataMigrationTool.log 파일에 보고된 컬렉션 데이터베이스의 크기를 고려합니다.

DataMigrationTool.log 파일은 명령이 실행 될 때마다 컬렉션에서 가장 큰 테이블의 목록을 제공합니다. 컬렉션에 대한 테이블 크기의 예제는 다음 출력을 참조하세요. 가장 큰 테이블의 크기를 임시 디렉터리를 호스트하는 드라이브의 여유 공간과 비교합니다.

Important

DACPAC 파일 생성을 계속하기 전에 컬렉션이 분리되어 있는지 확인합니다.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

임시 디렉터리를 호스트하는 드라이브에 적어도 여유 공간이 있는지 확인합니다. 그렇지 않은 경우 환경 변수를 설정하여 임시 디렉터리를 리디렉션해야 합니다.

SET TEMP={location on disk}

또 다른 고려 사항은 DACPAC 데이터가 저장되는 위치입니다. 저장된 위치를 멀리 떨어진 원격 드라이브로 가리키면 생성 시간이 길어질 수 있습니다. SSD(반도체 드라이브)와 같은 빠른 드라이브를 로컬에서 사용할 수 있는 경우 DACPAC 저장 위치로 드라이브를 대상으로 지정하는 것이 좋습니다. 그렇지 않으면 원격 드라이브가 아니라 컬렉션 데이터베이스가 있는 컴퓨터에 있는 디스크를 사용하는 것이 항상 더 빠릅니다.

이제 DACPAC의 대상 위치를 식별하고 충분한 공간이 있는지 확인했으므로 이제 DACPAC 파일을 생성할 차례입니다.

명령 프롬프트 창을 열고 SqlPackage.exe 위치로 이동합니다. DACPAC를 생성하려면 자리 표시자 값을 필수 값으로 바꾼 다음 다음 명령을 실행합니다.

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

데이터 원본: Azure DevOps Server 컬렉션 데이터베이스를 호스트하는 SQL Server 인스턴스입니다.
초기 카탈로그: 컬렉션 데이터베이스의 이름입니다.
targetFile: 디스크의 위치 및 DACPAC 파일 이름입니다.

Azure DevOps Server 데이터 계층 자체에서 실행되는 DACPAC 생성 명령은 다음 예제에 나와 있습니다.

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

명령의 출력은 Foo.dacpac라는 컬렉션 데이터베이스 Foo에서 생성된 DACPAC 파일입니다.

마이그레이션을 위한 컬렉션 구성

Azure VM에서 컬렉션 데이터베이스를 복원한 후 Azure DevOps Services가 데이터베이스에 연결하여 데이터를 마이그레이션할 수 있도록 SQL 로그인을 구성합니다. 이 로그인은 단일 데이터베이스에 대한 읽기 액세스만 허용합니다.

시작하려면 VM에서 SQL Server Management Studio를 연 다음 가져올 데이터베이스에 대해 새 쿼리 창을 엽니다.

데이터베이스의 복구를 단순으로 설정합니다.

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

데이터베이스에 대한 SQL 로그인을 만들고 해당 로그인을 'TFSEXECROLE'에 할당합니다.

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Fabrikam 예제에 따라 두 SQL 명령은 다음 예제와 같습니다.

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

참고 항목

VM의 SQL Server Management Studio에서 SQL Server 및 Windows 인증 모드를 사용하도록 설정합니다. 인증 모드를 사용하도록 설정하지 않으면 마이그레이션이 실패합니다.

VM을 대상으로 마이그레이션 사양 파일 구성

SQL Server 인스턴스에 연결하는 방법에 대한 정보를 포함하도록 마이그레이션 사양 파일을 업데이트합니다. 마이그레이션 사양 파일을 열고 다음을 업데이트합니다.

원본 파일 개체에서 DACPAC 매개 변수를 제거합니다.

변경 전의 마이그레이션 사양은 다음 코드에 나와 있습니다.

변경 후의 마이그레이션 사양은 다음 코드에 나와 있습니다.

필요한 매개 변수를 입력하고 사양 파일에서 원본 개체 내에 다음 속성 개체를 추가합니다.

"Properties":
{
    "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
}

변경 내용을 적용한 후 마이그레이션 사양은 다음 예제와 같습니다.

SQL Azure VM을 참조하는 마이그레이션 사양의 스크린샷

마이그레이션 사양은 이제 마이그레이션에 SQL Azure VM을 사용하도록 구성되었습니다. Azure DevOps Services로 마이그레이션하기 위한 나머지 준비 단계를 진행합니다. 마이그레이션이 완료되면 SQL 로그인을 삭제하거나 암호를 회전해야 합니다. Microsoft는 마이그레이션이 완료된 후 로그인 정보를 유지하지 않습니다.

3단계: DACPAC 파일 업로드

참고 항목

SQL Azure VM 메서드를 사용하는 경우 연결 문자열만 제공해야 합니다. 파일을 업로드할 필요가 없으며 이 단계를 건너뛸 수 있습니다.

DACPAC는 기존 컨테이너 또는 마이그레이션 작업을 위해 특별히 만든 컨테이너일 수 있는 Azure Storage 컨테이너에 배치되어야 합니다. 컨테이너가 올바른 지리적 위치에 만들어지도록 하는 것이 중요합니다.

Azure DevOps Services는 여러 지리적 위치에서 사용할 수 있습니다. 이러한 위치로 가져올 때 마이그레이션을 성공적으로 시작할 수 있도록 데이터를 올바르게 배치하는 것이 중요합니다. 데이터를 가져오는 것과 동일한 지리적 위치에 배치해야 합니다. 다른 위치에 데이터를 배치하면 마이그레이션을 시작할 수 없습니다. 다음 표에는 스토리지 계정을 만들고 데이터를 업로드하기 위한 허용되는 지리적 위치가 나와 있습니다.

원하는 마이그레이션 지리적 위치	스토리지 계정 지리적 위치
중앙 미국	중앙 미국
서유럽	서유럽
영국	영국 남부
오스트레일리아 동부	오스트레일리아 동부
브라질 남부	브라질 남부
인도 남부	인도 남부
캐나다 중부	캐나다 중부
아시아 태평양(싱가포르)	아시아 태평양(싱가포르)

Azure DevOps Services는 미국의 여러 지리적 위치에서 사용할 수 있지만 중앙 미국 위치만 새 Azure DevOps Services를 허용합니다. 현재는 데이터를 다른 미국 Azure 위치로 마이그레이션할 수 없습니다.

Azure Portal에서 Blob 컨테이너 를 만듭니다. 컨테이너를 만든 후 컬렉션 DACPAC 파일을 업로드합니다.

마이그레이션이 완료되면 AzCopy 또는 Azure Storage Explorer 와 같은 다른 Azure Storage 탐색기 도구와 같은 도구와 함께 제공되는 Blob 컨테이너 및 함께 제공되는 스토리지 계정을 삭제합니다.

참고 항목

DACPAC 파일이 10GB보다 큰 경우 AzCopy를 사용하는 것이 좋습니다. AzCopy는 빠른 업로드를 위해 다중 스레드 업로드를 지원합니다.

4단계: SAS 토큰 생성

SAS(공유 액세스 서명) 토큰은 스토리지 계정의 리소스에 대한 위임된 액세스를 제공합니다. 토큰을 사용하면 마이그레이션을 실행하기 위해 데이터에 액세스하는 데 필요한 가장 낮은 수준의 권한을 Microsoft에 부여할 수 있습니다.

Azure Portal을 사용하여 SAS 토큰을 생성할 수 있습니다. 보안 관점에서 다음 작업을 수행하는 것이 좋습니다.

SAS 토큰에 대한 권한으로 읽기 및 목록만 선택합니다. 다른 권한은 필요하지 않습니다.
만료 시간을 7일 이내로 설정합니다.
Azure DevOps Services IP에 대한 액세스만 제한합니다.
SAS 키를 비밀로 처리합니다. 컨테이너에 저장한 데이터에 대한 읽기 및 목록 액세스 권한을 부여하기 때문에 키를 안전하지 않은 위치에 두지 마세요.

5단계: 마이그레이션 사양 완료

프로세스의 앞부분에서 마이그레이션 사양 파일(migration.json이라고 함)을 부분적으로 작성했습니다. 이 시점에서 마이그레이션 유형을 제외한 나머지 모든 필드를 완료하기에 충분한 정보가 있습니다. 마이그레이션 유형은 마이그레이션 섹션의 뒷부분에서 설명합니다.

migration.json 사양 파일의 원본에서 다음 필드를 완료합니다.

위치: 스크립트에서 생성한 SAS 키를 붙여넣은 다음 이전 단계에서 복사합니다.
Dacpac: .dacpac 파일 확장자를 포함한 파일의 이름이 스토리지 계정에 업로드한 DACPAC 파일과 같은지 확인합니다.

최종 마이그레이션 사양 파일은 다음 예제와 같습니다.

완료된 마이그레이션 사양 파일의 스크린샷.

마이그레이션 유형 확인

가져오기는 테스트 실행 또는 프로덕션 실행으로 큐에 대기할 수 있습니다. ImportType 매개 변수는 마이그레이션 유형을 결정합니다.

TestRun: 테스트 목적으로 테스트 실행을 사용합니다. 시스템은 45일 후에 테스트를 삭제합니다.
ProductionRun: 결과 마이그레이션을 유지하고 마이그레이션이 완료된 후 Azure DevOps Services에서 조직 전체 시간을 사용하려는 경우 프로덕션 실행을 사용합니다.

팁

테스트 실행 마이그레이션을 먼저 완료하는 것이 좋습니다.

실행 조직 테스트

테스트 실행 조직은 팀이 컬렉션의 마이그레이션을 테스트하는 데 도움이 됩니다. 프로덕션 마이그레이션을 실행하려면 먼저 완료된 테스트 실행 조직을 삭제해야 합니다. 모든 테스트 실행 조직에는 제한된 존재가 있으며 설정된 기간 후에 자동으로 삭제됩니다. 조직이 삭제되는 시기에 대한 정보는 마이그레이션이 완료된 후 받아야 하는 성공 전자 메일에 포함됩니다. 이 날짜를 기록하고 그에 따라 계획해야 합니다.

테스트 실행 조직은 삭제되기까지 45일이 있습니다. 지정된 기간 후에 테스트 실행 조직이 삭제됩니다. 프로덕션 마이그레이션을 수행하기 전에 필요한 만큼 테스트 실행 가져오기를 반복할 수 있습니다.

테스트 실행 삭제

새 테스트를 시도하기 전에 이전 테스트 실행을 삭제합니다. 팀이 프로덕션 마이그레이션을 수행할 준비가 되면 테스트 실행 조직을 수동으로 삭제해야 합니다. 두 번째 테스트 실행 마이그레이션 또는 최종 프로덕션 마이그레이션을 실행하기 전에 이전 테스트 실행에서 만든 이전 Azure DevOps Services 조직을 삭제해야 합니다. 자세한 내용은 조직 삭제를 참조 하세요.

팁

사용자가 더 성공적인 테스트 실행 마이그레이션을 수행하는 데 도움이 되는 선택적 정보입니다. 이전 테스트 실행에서 리소스를 정리하는 데 필요한 추가 시간을 감안할 때 첫 번째 테스트 다음에 수행되는 마이그레이션은 더 오래 걸릴 것으로 예상됩니다.

삭제하거나 이름을 변경한 후 조직 이름을 사용할 수 있게 되는 데 최대 1시간이 걸릴 수 있습니다. 자세한 내용은 마이그레이션 후 작업 문서를 참조하세요.

마이그레이션 문제가 발생하는 경우 마이그레이션 및 마이그레이션 오류 문제 해결을 참조 하세요.

마이그레이션 실행

이제 팀에서 마이그레이션을 실행하는 프로세스를 시작할 준비가 되었습니다. 프로덕션 실행 마이그레이션을 시도하기 전에 성공적인 테스트 실행 마이그레이션으로 시작하는 것이 좋습니다. 테스트 실행 가져오기를 사용하면 프로덕션 실행에 들어가기 전에 마이그레이션이 어떻게 보이는지 미리 확인하고, 잠재적인 문제를 식별하고, 경험을 얻을 수 있습니다.

참고 항목

롤백 시와 같이 컬렉션에 대해 완료된 프로덕션 실행 마이그레이션을 반복해야 하는 경우 다른 마이그레이션을 큐에 넣기 전에 Azure DevOps Services 고객 지원에 문의하세요.

Azure 관리자는 사용자가 새 Azure DevOps 조직을 만들지 못하도록 할 수 있습니다. Microsoft Entra 테넌트 정책이 켜져 있으면 마이그레이션이 완료되지 않습니다. 시작하기 전에 정책이 설정되지 않았거나 마이그레이션을 수행하는 사용자에 대한 예외가 있는지 확인합니다. 자세한 내용은 Microsoft Entra 테넌트 정책을 통해 조직 만들기 제한을 참조하세요.
Azure DevOps Services는 파이프라인별 보존 정책을 지원하지 않으며 호스트된 버전으로 전달되지 않습니다.

롤백 계획에 대한 고려 사항

최종 프로덕션 실행을 수행하는 팀의 일반적인 관심사는 마이그레이션에 문제가 있는 경우 롤백 계획입니다. Azure DevOps용 데이터 마이그레이션 도구에 제공하는 마이그레이션 설정을 테스트할 수 있도록 테스트 실행을 수행하는 것이 좋습니다.

최종 프로덕션 실행에 대한 롤백은 매우 간단합니다. 마이그레이션을 큐에 대기하기 전에 Azure DevOps Server에서 팀 프로젝트 컬렉션을 분리하면 팀 구성원이 사용할 수 없게 됩니다. 어떤 이유로든 프로덕션 실행을 롤백하고 팀 구성원을 위해 온-프레미스 서버를 다시 온라인 상태로 만들어야 하는 경우 그렇게 할 수 있습니다. 팀 프로젝트 컬렉션을 온-프레미스에 다시 연결하고 팀이 잠재적인 오류를 이해하기 위해 다시 그룹화되는 동안 정상적으로 계속 작동한다는 것을 팀에 알릴 수 있습니다.

그런 다음, 원인을 확인할 수 없는 경우 오류의 원인을 이해하는 데 도움이 되도록 Azure DevOps Services 고객 지원에 문의할 수 있습니다. 자세한 내용은 문제 해결 문서를 참조 하세요. 고객 지원 티켓은 다음 페이지에서 https://aka.ms/AzureDevOpsImportSupport열 수 있습니다. 문제가 제품 그룹 엔지니어가 이러한 사례를 참여하도록 요구하는 경우 정기적인 업무 시간 동안 처리된다는 점에 유의해야 합니다.

Azure DevOps Server에서 팀 프로젝트 컬렉션을 분리하여 마이그레이션을 준비합니다.

SQL 데이터베이스의 백업을 생성하기 전에 데이터 마이그레이션 도구를 사용하려면 컬렉션을 Azure DevOps Server(SQL 아님)에서 완전히 분리해야 합니다. Azure DevOps Server의 분리 프로세스는 컬렉션 데이터베이스 외부에 저장된 사용자 ID 정보를 전송하고 새 서버 또는 이 경우 Azure DevOps Services로 이동할 수 있도록 이식 가능합니다.

컬렉션을 분리하는 작업은 Azure DevOps Server 인스턴스의 Azure DevOps Server 관리 콘솔에서 쉽게 수행할 수 있습니다. 자세한 내용은 프로젝트 컬렉션 이동, 컬렉션 분리를 참조 하세요.

마이그레이션 큐

Important

계속하기 전에 DACPAC 파일을 생성하거나 컬렉션 데이터베이스를 SQL Azure VM에 업로드하기 전에 컬렉션이 분리되었는지 확인합니다. 이 단계를 완료하지 않으면 마이그레이션이 실패합니다. 마이그레이션이 실패하는 경우 마이그레이션 오류 해결을 참조하세요.

데이터 마이그레이션 도구의 가져오기 명령을 사용하여 마이그레이션을 시작합니다. 마이그레이션 명령은 마이그레이션 사양 파일을 입력으로 사용합니다. 파일을 구문 분석하여 제공된 값이 유효한지 확인하고, 성공하면 Azure DevOps Services로의 마이그레이션을 큐에 대기합니다. 마이그레이션 명령에는 인터넷 연결이 필요하지만 Azure DevOps Server 인스턴스에 대한 연결은 필요하지 않습니다.

시작하려면 명령 프롬프트 창을 열고 디렉터리를 데이터 마이그레이션 도구의 경로로 변경합니다. 도구와 함께 제공되는 도움말 텍스트를 검토하는 것이 좋습니다. 다음 명령을 실행하여 마이그레이션 명령에 대한 지침 및 도움말을 확인합니다.

Migrator import /help

마이그레이션을 큐에 대기하는 명령에는 다음과 같은 구조가 있습니다.

Migrator import /importFile:{location of migration specification file}

다음 예제에서는 완료된 마이그레이션 명령을 보여줍니다.

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

유효성 검사가 통과되면 ID 맵 로그 파일이 빌드된 것과 동일한 Microsoft Entra 테넌트의 멤버인 ID를 사용하여 Microsoft Entra ID에 로그인합니다. 로그인한 사용자는 가져온 조직의 소유자입니다.

참고 항목

각 Microsoft Entra 테넌트는 24시간당 5개의 가져오기로 제한됩니다. 큐에 대기 중인 가져오기만 이 한도에 대해 계산됩니다.

팀에서 마이그레이션을 시작하면 마이그레이션을 대기 중인 사용자에게 이메일 알림이 전송됩니다. 마이그레이션을 대기한 후 약 5~10분 후에 팀은 조직으로 이동하여 상태를 확인할 수 있습니다. 마이그레이션이 완료되면 팀이 로그인하도록 지시되고 이메일 알림이 조직 소유자 전송됩니다.

데이터 마이그레이션 도구는 마이그레이션 전에 수정해야 하는 오류에 플래그를 지정합니다. 이 문서에서는 마이그레이션을 준비할 때 발생할 수 있는 가장 일반적인 경고 및 오류에 대해 설명합니다. 각 오류를 수정한 후 마이그레이션기 유효성 검사 명령을 다시 실행하여 해결 방법을 확인합니다.

다음 단계

마이그레이션 오류 해결

다음을 통해 공유

테스트 실행 마이그레이션 수행

필수 조건

컬렉션 유효성 검사

로그 파일 가져오기

마이그레이션 파일 생성

준비 명령

마이그레이션 사양 파일

마이그레이션에 지원되는 Azure 지역

ID 맵 로그

활성 ID

기록 ID

ID 맵 로그 파일 이해

역사적 정체성(소규모 팀)

Visual Studio 구독

마이그레이션 준비

1단계: 컬렉션 분리

2단계: DACPAC 파일 생성

마이그레이션을 위한 컬렉션 구성

VM을 대상으로 마이그레이션 사양 파일 구성

3단계: DACPAC 파일 업로드

4단계: SAS 토큰 생성

5단계: 마이그레이션 사양 완료

마이그레이션 유형 확인

실행 조직 테스트

테스트 실행 삭제

마이그레이션 실행

롤백 계획에 대한 고려 사항

Azure DevOps Server에서 팀 프로젝트 컬렉션을 분리하여 마이그레이션을 준비합니다.

마이그레이션 큐

다음 단계

피드백

추가 리소스

다음을 통해 공유

테스트 실행 마이그레이션 수행

필수 조건

컬렉션 유효성 검사

로그 파일 가져오기

마이그레이션 파일 생성

준비 명령

마이그레이션 사양 파일

마이그레이션에 지원되는 Azure 지역

ID 맵 로그

활성 ID

기록 ID

ID 맵 로그 파일 이해

역사적 정체성(소규모 팀)

Visual Studio 구독

마이그레이션 준비

1단계: 컬렉션 분리

2단계: DACPAC 파일 생성

마이그레이션을 위한 컬렉션 구성

VM을 대상으로 마이그레이션 사양 파일 구성

3단계: DACPAC 파일 업로드

4단계: SAS 토큰 생성

5단계: 마이그레이션 사양 완료

마이그레이션 유형 확인

실행 조직 테스트

테스트 실행 삭제

마이그레이션 실행

롤백 계획에 대한 고려 사항

Azure DevOps Server에서 팀 프로젝트 컬렉션을 분리하여 마이그레이션을 준비합니다.

마이그레이션 큐

다음 단계

관련된 문서

피드백

추가 리소스