Lakukan migrasi uji coba

Tim Anda sekarang siap untuk memulai proses memulai uji migrasi Anda dan akhirnya migrasi produksi penuh. Dalam fase ini, kita membahas langkah-langkah akhir untuk mengantrekan migrasi selain tugas lain yang biasanya muncul di akhir proyek migrasi.

Prasyarat

Selesaikan fase Siapkan uji coba sebelum Anda memulai migrasi uji coba.

Penting

Untuk memastikan proses migrasi yang lancar, lakukan satu atau beberapa impor uji coba. Impor uji coba berlangsung selama 45 hari untuk pengujian dan validasi. Setelah 45 hari, waktu uji habis dan dihapus, mengharuskan Anda untuk memulai kembali jika diperlukan. Semakin lama waktu yang berlalu antara uji coba dan proses produksi, semakin banyak layanan yang dapat berubah, berpotensi memperkenalkan kesalahan yang dapat dideteksi oleh uji coba baru. Anda dapat menjalankan ulang impor uji coba sebanyak yang diperlukan. Setiap impor dimulai dari keadaan awal database impor, karena perubahan dari satu impor tidak bisa bertahan ke impor berikutnya. Perhatikan poin-poin berikut:

• Anda tidak dapat memperpanjang uji coba tanpa batas waktu
• Anda tidak dapat menaikkan uji coba ke produksi
• Uji coba akan dihapus jika salah satu hal berikut ini terjadi:
  • Pengujian berakhir karena waktu habis
  • Uji coba baru dengan nama yang sama dijalankan
  • Pengoperasian produksi dimulai
  • Organisasi dihapus secara manual melalui pengaturan organisasi

Memvalidasi koleksi

Validasi setiap koleksi yang ingin Anda migrasikan ke Azure DevOps Services. Langkah validasi memeriksa berbagai aspek koleksi Anda, termasuk, tetapi tidak terbatas pada, ukuran, kolaksi, identitas, dan proses.

Jalankan validasi dengan menggunakan Alat Migrasi Data.

1. Unduh Alat Migrasi Data.

2. Salin file zip ke salah satu tingkat aplikasi Azure DevOps Server Anda.

3. Ekstrak file. Anda juga dapat menjalankan alat dari komputer yang berbeda tanpa Azure DevOps Server terinstal, selama komputer dapat terhubung ke database konfigurasi instans Azure DevOps Server.

4. Buka jendela Prompt Perintah di server, dan masukkan perintah cd untuk mengubah ke direktori tempat Alat Migrasi Data disimpan. Luangkan waktu beberapa saat untuk meninjau konten bantuan untuk alat ini.

   a. Untuk melihat bantuan dan panduan tingkat atas, jalankan perintah berikut.

    Migrator /help
   

   b. Lihat teks bantuan untuk perintah .

    Migrator validate /help 
   

5. Sebagai pertama kalinya Anda memvalidasi koleksi, perintah Anda harus memiliki struktur sederhana berikut.

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

   Di sini {name} menyediakan nama penyewa Microsoft Entra Anda; misalnya, untuk menjalankan terhadap DefaultCollection dan fabrikam penyewa, perintahnya akan terlihat seperti contoh berikut.

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Untuk menjalankan alat dari komputer selain Azure DevOps Server, Anda memerlukan parameter /connectionString . Parameter string koneksi menunjuk ke database konfigurasi Azure DevOps Server Anda. Sebagai contoh, jika perintah yang divalidasi dijalankan oleh perusahaan Fabrikam, perintah akan terlihat seperti itu.

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

   Penting

   Alat Migrasi Data tidak mengedit data atau struktur apa pun dalam koleksi. Proses ini membaca kumpulan hanya untuk mengidentifikasi masalah.

7. Setelah validasi selesai, Anda dapat melihat file dan hasil log.

   

   Selama validasi, Anda menerima peringatan jika beberapa alur Anda berisi aturan retensi per alur. Azure DevOps Services menggunakan model retensi berbasis proyek dan tidak mendukung kebijakan retensi per alur. Jika Anda melanjutkan migrasi, kebijakan tidak dibawa ke versi yang dihosting. Sebagai gantinya, kebijakan retensi tingkat proyek default berlaku. Pertahankan build yang penting bagi Anda agar tidak hilang.

Setelah semua validasi berlalu, Anda dapat pindah ke langkah berikutnya dari proses migrasi. Jika Alat Migrasi Data menandai kesalahan apa pun, koreksi sebelum Anda melanjutkan. Untuk panduan tentang memperbaiki kesalahan validasi, lihat Memecahkan masalah kesalahan migrasi dan validasi.

Mengimpor file log

Saat membuka direktori log, Anda mungkin melihat beberapa file pengelogan.

File log utama diberi nama DataMigrationTool.log. Ini berisi rincian tentang semua yang telah dijalankan. Untuk memudahkan Anda fokus pada area tertentu, log dihasilkan untuk setiap operasi validasi utama.

Misalnya, jika TfsMigrator melaporkan kesalahan dalam langkah "Memvalidasi Proses Proyek", Anda dapat membuka file ProjectProcessMap.log untuk melihat semua yang dijalankan untuk langkah tersebut alih-alih harus menggulir seluruh log.

Tinjau file TryMatchOobProcesses.log hanya jika Anda mencoba memigrasikan proses proyek Anda untuk menggunakan model yang diwariskan. Jika Anda tidak ingin menggunakan model yang diwariskan, Anda dapat mengabaikan kesalahan ini, karena tidak mencegah Anda mengimpor ke Layanan Azure DevOps. Untuk informasi selengkapnya, lihat Fase validasi migrasi.

Hasilkan file migrasi

Alat Migrasi Data memvalidasi pengumpulan dan mengembalikan hasil "Semua validasi koleksi lulus." Sebelum Anda mengambil koleksi offline untuk memigrasikannya, buat file migrasi. Saat menjalankan prepare perintah, Anda membuat dua file migrasi:

• IdentityMapLog.csv: Menguraikan peta identitas Anda antara Direktori Aktif dan ID Microsoft Entra.
• migration.json: Mengharuskan Anda mengisi spesifikasi migrasi yang ingin Anda gunakan untuk memulai migrasi Anda.

Persiapkan perintah

prepare Perintah ini membantu menghasilkan file migrasi yang diperlukan. Pada dasarnya, perintah ini memindai koleksi untuk menemukan daftar semua pengguna untuk mengisi log peta identitas, IdentityMapLog.csv, lalu mencoba menyambungkan ke ID Microsoft Entra untuk menemukan kecocokan setiap identitas. Untuk melakukannya, perusahaan Anda perlu menggunakan alat Microsoft Entra Connect (sebelumnya dikenal sebagai alat Sinkronisasi Direktori, alat Sinkronisasi Direktori, atau alat DirSync.exe).

Jika sinkronisasi direktori disiapkan, Alat Migrasi Data harus menemukan identitas yang cocok dan menandainya sebagai Aktif. Jika tidak ada kecocokan, identitas ditandai sebagai Historis di log peta identitas, jadi Anda harus menyelidiki mengapa pengguna tidak disertakan dalam sinkronisasi direktori Anda. File spesifikasi migrasi, migration.json, harus diisi sebelum migrasi.

validate Tidak seperti perintah, preparememang memerlukan koneksi internet, karena perlu terhubung ke ID Microsoft Entra untuk mengisi file log peta identitas. Jika instans Azure DevOps Server Anda tidak memiliki akses internet, jalankan alat dari komputer yang memiliki akses internet. Selama Anda dapat menemukan komputer dengan koneksi intranet ke instans Azure DevOps Server dan koneksi internet, Anda dapat menjalankan perintah ini. Untuk bantuan terkait prepare perintah, jalankan perintah berikut:

Migrator prepare /help

Disertakan dalam dokumentasi bantuan adalah instruksi dan contoh untuk menjalankan Migrator perintah dari instans Azure DevOps Server itu sendiri dan komputer jarak jauh. Jika Anda menjalankan perintah dari salah satu tingkat aplikasi instans Azure DevOps Server, perintah Anda harus memiliki struktur berikut:

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"

Parameter connectionString adalah penunjuk ke database konfigurasi instans Azure DevOps Server Anda. Sebagai contoh, jika perusahaan Fabrikam menjalankan prepare perintah, perintah terlihat seperti contoh berikut:

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

Saat Alat Migrasi Data menjalankan prepare perintah, Alat Migrasi menjalankan validasi lengkap untuk memastikan bahwa tidak ada yang berubah dengan koleksi Anda sejak validasi penuh terakhir. Jika ada masalah baru yang terdeteksi, tidak ada file migrasi yang dihasilkan.

Tak lama setelah perintah mulai berjalan, jendela masuk Microsoft Entra akan ditampilkan. Masuklah dengan identitas yang terkait dengan domain penyewa, sebagaimana ditentukan dalam perintah. Pastikan bahwa penyewa Microsoft Entra yang ditentukan adalah yang Anda inginkan untuk mendukung organisasi Anda di masa depan. Dalam contoh Fabrikam kami, pengguna memasukkan kredensial yang mirip dengan contoh cuplikan layar berikut.

Penting

Jangan gunakan akun Microsoft Entra pengujian untuk migrasi uji coba dan akun Microsoft Entra produksi Anda untuk operasional produksi. Menggunakan tenant Microsoft Entra uji coba dapat mengakibatkan masalah migrasi identitas ketika Anda memulai penggunaan dengan tenant Microsoft Entra produksi milik organisasi Anda.

Saat Anda berhasil menjalankan prepare perintah di Alat Migrasi Data, jendela hasil menampilkan sekumpulan log dan dua file migrasi. Di direktori log, temukan folder log dan dua file:

• migration.json adalah file spesifikasi migrasi. Kami menyarankan agar Anda meluangkan waktu untuk mengisinya.
• IdentityMapLog.csv berisi pemetaan Direktori Aktif yang dihasilkan ke identitas Microsoft Entra. Tinjau untuk kelengkapan sebelum Anda memulai migrasi.

Dua file dijelaskan secara lebih rinci di bagian berikutnya.

File spesifikasi migrasi

Spesifikasi migrasi, migration.json, adalah file JSON yang menyediakan pengaturan migrasi. Ini termasuk nama organisasi yang diinginkan, informasi akun penyimpanan, dan informasi lainnya. Sebagian besar bidang diisi otomatis, dan beberapa bidang memerlukan input Anda sebelum Anda mencoba migrasi.

Bidang migration.json yang ditampilkan dan tindakan yang diperlukan dijelaskan dalam tabel berikut:

Bidang	Deskripsi	Tindakan yang diperlukan
Sumber	Informasi tentang lokasi dan nama file data sumber yang digunakan untuk migrasi.	Tidak diperlukan tindakan. Tinjau informasi untuk tindakan pada subbidang yang perlu diikuti.
Lokasi	Kunci tanda tangan akses bersama untuk akun penyimpanan Azure yang menjadi host paket aplikasi lapis data (DACPAC).	Tidak diperlukan tindakan. Bidang ini tercakup dalam langkah selanjutnya.
Files	Nama file yang berisi data migrasi.	Tidak diperlukan tindakan. Tinjau informasi untuk tindakan pada subbidang yang perlu diikuti.
DACPAC	File DACPAC yang mengemas database koleksi yang akan digunakan untuk membawa data selama migrasi.	Tidak diperlukan tindakan. Di langkah selanjutnya, Anda membuat file ini dengan menggunakan koleksi Anda lalu mengunggahnya ke akun penyimpanan Azure. Perbarui file berdasarkan nama yang Anda gunakan saat Anda membuatnya nanti dalam proses ini.
Target	Karakteristik organisasi baru untuk tujuan migrasi.	Tidak diperlukan tindakan. Tinjau informasi untuk tindakan pada subbidang yang perlu diikuti.
Nama	Nama organisasi yang akan dibuat selama migrasi.	Berikan nama. Nama dapat dengan cepat diubah nanti setelah migrasi selesai. CATATAN: Jangan membuat organisasi dengan nama ini sebelum Anda menjalankan migrasi. Organisasi dibuat sebagai bagian dari proses migrasi.
Jenis Impor	Jenis migrasi yang ingin Anda jalankan.	Tidak diperlukan tindakan. Di langkah selanjutnya, pilih jenis migrasi yang akan dijalankan.
Data Validasi	Informasi yang diperlukan untuk membantu mendorong pengalaman migrasi Anda.	Alat Migrasi Data menghasilkan bagian "ValidationData". Ini berisi informasi untuk membantu mendorong pengalaman migrasi Anda. Jangan* edit nilai di bagian ini, atau migrasi Anda bisa gagal dimulai.

Setelah menyelesaikan proses sebelumnya, Anda harus memiliki file yang terlihat seperti contoh berikut.

Pada gambar sebelumnya, perencana migrasi Fabrikam menambahkan nama organisasi fabrikam-import dan memilih CUS (Amerika Serikat bagian tengah) sebagai lokasi geografis untuk migrasi. Nilai-nilai lainnya dibiarkan apa adanya untuk dimodifikasi tepat sebelum perencana mengalihkannya ke mode offline untuk migrasi.

Catatan

Impor uji coba secara otomatis memiliki akhiran '-dryrun' di akhir nama organisasi, yang dapat Anda ubah setelah migrasi.

Wilayah Azure yang didukung untuk migrasi

Layanan Azure DevOps tersedia di beberapa lokasi geografis Azure. Namun, tidak semua lokasi tempat Layanan Azure DevOps tersedia didukung untuk migrasi. Tabel berikut ini mencantumkan lokasi geografis Azure yang bisa Anda pilih untuk migrasi. Juga disertakan adalah nilai yang perlu Anda tempatkan dalam file spesifikasi migrasi untuk menargetkan geografi tersebut untuk migrasi.

Lokasi geografis	Lokasi geografis Azure	Nilai spesifikasi impor
Amerika Serikat	Amerika Serikat Tengah	CUS
Eropa	Eropa Barat	WEU
Inggris Raya	Inggris Raya Selatan	Kerajaan Inggris-Skotlandia
Australia	Australia Timur	EAU
Amerika Selatan	Brasil Selatan	SBR
Asia Pasifik	India Tengah	Magister Seni
Asia Pasifik	Asia Tenggara (Singapura)	Asia Tenggara
Kanada	Kanada Tengah	CC

Catatan peta identitas

Log peta identitas sama pentingnya dengan data aktual yang Anda migrasikan ke Azure DevOps Services. Saat Anda meninjau file, penting untuk memahami bagaimana migrasi identitas berjalan dan apa yang mungkin menjadi dampak dari hasil potensial. Saat Anda memigrasikan identitas, identitas tersebut dapat menjadi aktif atau historis. Identitas aktif dapat masuk ke Azure DevOps Services, tetapi identitas historis tidak dapat.

Identitas aktif

Identitas aktif mengacu pada identitas pengguna di Azure DevOps Services pascamigrasi. Di Azure DevOps Services, identitas ini dilisensikan dan ditampilkan sebagai pengguna di organisasi. Identitas ditandai sebagai aktif di dalam kolom Status Impor yang Diharapkan pada file log peta identitas.

Identitas sejarah

Identitas historis dipetakan seperti di kolom Expected Import Status dalam file log peta identitas. Identitas tanpa entri baris dalam file juga menjadi bagian dari sejarah. Contoh identitas tanpa entri baris dapat berupa karyawan yang tidak lagi bekerja di sebuah perusahaan.

Tidak seperti identitas aktif, identitas historis:

• Tidak memiliki akses ke sebuah organisasi setelah migrasi.
• Tidak memiliki lisensi.
• Jangan muncul sebagai pengguna di organisasi. Yang bertahan hanya gagasan atas nama identitas tersebut dalam organisasi, sehingga riwayat identitas tersebut dapat dicari nanti. Kami menyarankan agar Anda menggunakan identitas historis untuk pengguna yang tidak lagi bekerja di perusahaan atau yang tidak memerlukan akses lebih lanjut ke organisasi.

Catatan

Setelah identitas diimpor sebagai historis, identitas tidak dapat menjadi aktif.

Memahami file log pemetaan identitas

File log peta identitas mirip dengan contoh yang ditunjukkan di sini:

Kolom dalam file log peta identitas dijelaskan dalam tabel berikut:

Anda dan admin Microsoft Entra Anda harus menyelidiki pengguna yang ditandai sebagai Tidak Ditemukan Kecocokan (Periksa Sinkronisasi ID Microsoft Entra) untuk memahami mengapa mereka bukan bagian dari Sinkronisasi Microsoft Entra Connect Anda.

Kolom	Deskripsi
Direktori Aktif: Pengguna (Azure DevOps Server)	Nama tampilan yang mudah dipahami yang digunakan oleh identitas di Azure DevOps Server. Nama ini memudahkan untuk mengidentifikasi pengguna mana yang dirujuk oleh garis dalam peta.
Direktori Aktif: Pengidentifikasi Keamanan	Pengidentifikasi unik untuk identitas Active Directory lokal di Azure DevOps Server. Kolom ini digunakan untuk mengidentifikasi pengguna dalam koleksi.
Microsoft Entra ID: Pengguna yang Akan Diimpor (Layanan Azure DevOps)	Entah alamat masuk yang diharapkan dari pengguna yang akan segera aktif atau Tidak Ditemukan Kecocokan (Periksa Sinkronisasi ID Microsoft Entra), yang menunjukkan bahwa identitas hilang selama Sinkronisasi ID Microsoft Entra dan diimpor sebagai catatan historis.
Status Impor yang Diharapkan	Status migrasi pengguna yang diharapkan: Aktif jika ada kecocokan antara Direktori Aktif dan ID Microsoft Entra Anda, atau Historis jika tidak ada kecocokan.
Tanggal Validasi	Terakhir kali log peta identitas divalidasi.

Saat Anda membaca file, perhatikan apakah nilai di kolom Status Impor yang Diharapkan adalah Aktif atau Historis. Aktif menunjukkan bahwa identitas pada baris ini dipetakan dengan benar dan menjadi aktif saat migrasi. Historis berarti bahwa identitas menjadi historis pada migrasi. Penting untuk meninjau file pemetaan yang dihasilkan untuk kelengkapan dan kebenaran.

Penting

Migrasi gagal jika perubahan besar terjadi pada sinkronisasi ID keamanan Microsoft Entra Connect Anda di antara upaya migrasi. Anda dapat menambahkan pengguna baru di antara uji coba, dan Anda dapat melakukan koreksi untuk memastikan bahwa identitas historis yang diimpor sebelumnya menjadi aktif. Namun, Anda tidak dapat mengubah pengguna yang sudah ada yang sebelumnya diimpor sebagai aktif. Melakukannya menyebabkan migrasi Anda gagal. Contoh perubahan adalah menyelesaikan migrasi uji coba, menghapus identitas yang diimpor secara aktif dari ID Microsoft Entra, membuat ulang pengguna di ID Microsoft Entra, lalu mencoba migrasi lain. Dalam kasus ini, upaya migrasi identitas aktif terjadi antara Active Directory dan identitas Microsoft Entra yang baru dibuat, tetapi menyebabkan kegagalan migrasi.

1. Tinjau identitas yang cocok dengan benar. Apakah semua identitas yang diharapkan ada? Apakah pengguna dipetakan ke identitas Microsoft Entra yang benar?

   Jika ada nilai yang perlu diperbarui, hubungi administrator Microsoft Entra Anda untuk memastikan identitas Direktori Aktif lokal disinkronkan dengan ID Microsoft Entra dan dikonfigurasi dengan benar. Untuk informasi selengkapnya, lihat Mengintegrasikan identitas lokal Anda dengan ID Microsoft Entra.

2. Selanjutnya, tinjau identitas yang diberi label historis. Pelabelan ini menyiratkan bahwa identitas Microsoft Entra yang cocok tidak dapat ditemukan, karena salah satu alasan berikut:

   • Identitas tidak disiapkan untuk sinkronisasi antara Active Directory lokal dan ID Microsoft Entra.
   • Identitas belum diisi di ID Microsoft Entra Anda (misalnya, ada karyawan baru).
   • Identitas tidak ada di sesi Microsoft Entra Anda.
   • Pengguna yang memiliki identitas tersebut tidak lagi bekerja di perusahaan.

Untuk mengatasi tiga alasan pertama, siapkan identitas Active Directory lokal yang dimaksudkan untuk disinkronkan dengan ID Microsoft Entra. Untuk informasi selengkapnya, lihat Mengintegrasikan identitas lokal Anda dengan ID Microsoft Entra. Anda harus menyiapkan dan menjalankan Microsoft Entra Connect untuk identitas yang akan diimpor sebagai aktif di Azure DevOps Services.

Anda dapat mengabaikan alasan keempat, karena karyawan yang sudah tidak bekerja di perusahaan harus diimpor sebagai historis.

Identitas historis (tim kecil)

Catatan

Hanya tim kecil yang harus mempertimbangkan strategi migrasi identitas yang diusulkan di bagian ini.

Jika Microsoft Entra Connect tidak dikonfigurasi, semua pengguna dalam file log peta identitas ditandai sebagai historis. Menjalankan migrasi dengan cara ini menghasilkan semua pengguna diimpor sebagai historis. Kami sangat menyarankan Agar Anda mengonfigurasi Microsoft Entra Connect untuk memastikan bahwa pengguna Anda diimpor sebagai aktif.

Menjalankan migrasi dengan semua identitas historis memiliki konsekuensi yang perlu dipertimbangkan dengan hati-hati. Hanya tim dengan beberapa pengguna dan di mana biaya pengaturan Microsoft Entra Connect dianggap terlalu tinggi yang perlu mempertimbangkan.

Untuk memigrasikan semua identitas sebagai historis, ikuti langkah-langkah yang diuraikan di bagian selanjutnya. Saat Anda mengantrekan migrasi, identitas yang digunakan untuk mengantrekan migrasi dimasukkan ke dalam organisasi sebagai pemilik organisasi. Semua pengguna lain diimpor sebagai data historis. Pemilik organisasi kemudian dapat menambahkan pengguna kembali dengan menggunakan identitas Microsoft Entra mereka. Pengguna yang ditambahkan diperlakukan sebagai pengguna baru. Mereka tidak memiliki riwayat apa pun, dan tidak ada cara untuk membandingkan kembali riwayat ini ke identitas Microsoft Entra. Namun, pengguna masih dapat mencari riwayat pramigrasi mereka dengan mencari \<domain>\<Active Directory username>.

Alat Migrasi Data menampilkan peringatan jika mendeteksi skenario identitas historis lengkap. Jika Anda memutuskan untuk mengikuti jalur migrasi ini, Anda perlu memberikan persetujuan di dalam alat terhadap batasan tersebut.

Langganan Visual Studio

Alat Migrasi Data tidak dapat mendeteksi langganan Visual Studio (sebelumnya dikenal sebagai manfaat MSDN) saat menghasilkan file log peta identitas. Sebagai gantinya, kami sarankan Anda menerapkan fitur peningkatan lisensi otomatis setelah migrasi. Selama akun kerja pengguna ditautkan dengan benar, Azure DevOps Services secara otomatis menerapkan manfaat langganan Visual Studio mereka pada masuk pertama setelah migrasi. Anda tidak pernah dikenakan biaya untuk lisensi yang ditetapkan selama migrasi, sehingga Anda dapat menangani langganan dengan aman setelahnya.

Anda tidak perlu mengulangi migrasi uji coba jika langganan Visual Studio pengguna tidak ditingkatkan secara otomatis di Azure DevOps Services. Penautan langganan Visual Studio terjadi di luar lingkup migrasi. Selama akun kerja mereka ditautkan dengan benar sebelum atau sesudah migrasi, lisensi pengguna secara otomatis ditingkatkan pada saat masuk berikutnya. Setelah lisensi mereka berhasil ditingkatkan, pada saat Anda menjalankan migrasi berikutnya, pengguna akan ditingkatkan secara otomatis saat pertama kali masuk ke organisasi.

Penyiapan untuk migrasi

Sekarang Anda memiliki segala sesuatu yang siap untuk dijalankan pada migrasi uji coba Anda. Jadwalkan waktu henti dengan tim Anda untuk menonaktifkan koleksi demi migrasi. Saat Anda menyetujui waktu untuk menjalankan migrasi, unggah aset yang diperlukan yang Anda buat dan salinan database ke Azure. Mempersiapkan migrasi terdiri dari lima langkah berikut.

Langkah 1: Ambil koleksi secara offline dan pisahkan. Langkah 2: Buat file DACPAC dari koleksi yang akan Anda migrasikan.
Langkah 3: Unggah file DACPAC dan file migrasi ke akun penyimpanan Azure.
Langkah 4: Buat token SAS untuk mengakses akun penyimpanan.
Langkah 5: Selesaikan spesifikasi migrasi.

Catatan

Sebelum melakukan migrasi produksi, kami sangat menyarankan untuk menyelesaikan migrasi uji coba. Uji coba memungkinkan Anda memvalidasi bahwa proses migrasi berfungsi untuk koleksi Anda dan memastikan tidak ada bentuk atau masalah data unik yang dapat menyebabkan migrasi produksi gagal.

Langkah 1: Lepaskan koleksi Anda

Melepaskan koleksi adalah langkah penting dalam proses migrasi. Data identitas untuk koleksi berada di database konfigurasi instans Azure DevOps Server saat koleksi dilampirkan dan online. Ketika kumpulan dilepas dari instance Azure DevOps Server, mengambil salinan data identitas tersebut dan mengemasnya dengan kumpulan untuk pengiriman. Tanpa data ini, bagian identitas migrasi tidak dapat dijalankan.

Kiat

Biarkan koleksi terlepas hingga migrasi selesai untuk menghindari kehilangan perubahan apa pun yang dilakukan selama migrasi, karena perubahan ini tidak dapat dimigrasikan setelahnya. Setelah mencadangkan koleksi untuk migrasi, Anda dapat memasangnya kembali. Namun, setiap perubahan yang dilakukan setelah proses pencadangan tidak disertakan dalam migrasi, yang mungkin menimbulkan kekhawatiran tentang memiliki data terbaru. Anda dapat menggunakan pencopotan offline untuk uji coba, tetapi proses ini mungkin tidak selaras dengan praktik migrasi yang direkomendasikan. Tinjau dokumentasi tentang melepas secara offline untuk sepenuhnya memahami implikasinya dan bagaimana itu cocok dengan strategi migrasi Anda.

Penting untuk menimbang biaya memilih untuk mengalami waktu henti nol selama uji coba. Ini memerlukan pengambilan cadangan database koleksi dan konfigurasi, memulihkannya pada instans SQL, lalu membuat cadangan yang dilepaskan. Analisis biaya dapat membuktikan bahwa mengambil hanya beberapa jam waktu henti untuk mengambil langsung cadangan terpisah lebih menguntungkan pada akhirnya.

Langkah 2: Membuat file DACPAC

DACPAC menawarkan metode yang cepat dan relatif mudah untuk memindahkan koleksi ke Azure DevOps Services. Namun, setelah ukuran database koleksi melebihi ambang batas tertentu, manfaat menggunakan DACPAC mulai berkurang.

Catatan

Jika Alat Migrasi Data menampilkan peringatan bahwa Anda tidak dapat menggunakan metode DACPAC, Anda harus melakukan migrasi dengan menggunakan metode komputer virtual (VM) SQL Azure. Lewati langkah 2 hingga 5 dalam hal ini dan ikuti instruksi dalam fase Siapkan uji coba, Migrasikan koleksi besar, lalu lanjutkan untuk menentukan jenis migrasi. Jika Alat Migrasi Data tidak menampilkan peringatan, gunakan metode DACPAC yang dijelaskan dalam langkah ini.

DACPAC adalah fitur SQL Server yang memungkinkan database dikemas ke dalam satu file dan disebarkan ke instans SQL Server lainnya. File DACPAC juga dapat dipulihkan langsung ke Azure DevOps Services, sehingga Anda dapat menggunakannya sebagai metode pengemasan untuk mendapatkan data koleksi Anda di cloud.

Penting

• Saat menggunakan SqlPackage.exe, Anda harus menggunakan versi .NET Framework SqlPackage.exe untuk menyiapkan DACPAC. Penginstal MSI harus digunakan untuk menginstal versi .NET Framework dari SqlPackage.exe. Jangan gunakan versi dotnet CLI atau .zip (Windows .NET 6) dari SqlPackage.exe karena versi tersebut mungkin akan menghasilkan DACPAC yang tidak kompatibel dengan layanan Azure DevOps.
• SqlPackage versi 161 mengenkripsi koneksi database secara default dan mungkin tidak tersambung. Jika Anda menerima kesalahan proses masuk, tambahkan ;Encrypt=False;TrustServerCertificate=True ke string koneksi pernyataan SqlPackage.

Unduh dan instal SqlPackage.exe menggunakan Penginstal MSI terbaru dari catatan rilis SqlPackage.

Setelah Anda menggunakan Penginstal MSI, SqlPackage.exe menginstal di jalur yang mirip dengan %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Saat Anda membuat DACPAC, ingatlah dua pertimbangan: disk tempat DACPAC disimpan dan ruang disk pada komputer yang menghasilkan DACPAC. Anda ingin memastikan bahwa Anda memiliki cukup ruang disk untuk menyelesaikan operasi.

Saat membuat paket, SqlPackage.exe untuk sementara menyimpan data dari koleksi Anda di direktori sementara pada drive C mesin tempat Anda memulai permintaan pengemasan.

Anda mungkin menemukan bahwa drive C Anda terlalu kecil untuk mendukung pembuatan DACPAC. Anda dapat memperkirakan jumlah ruang yang Anda butuhkan dengan mencari tabel terbesar dalam database koleksi Anda. DACPAC dibuat satu tabel pada satu waktu. Persyaratan ruang maksimum untuk menjalankan pembuatan kira-kira setara dengan ukuran tabel terbesar dalam database koleksi. Jika Anda menyimpan DACPAC yang dihasilkan ke drive C, pertimbangkan ukuran database koleksi seperti yang dilaporkan dalam DataMigrationTool.log file dari hasil proses validasi.

File DataMigrationTool.log menyediakan daftar tabel terbesar dalam koleksi setiap kali perintah dijalankan. Untuk contoh ukuran tabel untuk koleksi, lihat output berikut. Bandingkan ukuran tabel terbesar dengan ruang kosong pada drive yang menghosting direktori sementara Anda.

Penting

Sebelum Anda melanjutkan pembuatan file DACPAC, pastikan koleksi Anda dapat dilepaskan.

[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

Pastikan bahwa drive yang menghosting direktori sementara Anda memiliki setidaknya ruang kosong sebanyak mungkin. Jika tidak, Anda perlu mengalihkan direktori sementara dengan mengatur variabel lingkungan.

SET TEMP={location on disk}

Pertimbangan lain adalah tempat data DACPAC disimpan. Mengarahkan lokasi yang disimpan ke drive jarak jauh dapat mengakibatkan waktu pembuatan yang lebih lama. Jika drive cepat seperti solid-state drive (SSD) tersedia secara lokal, kami sarankan Anda menargetkan drive sebagai lokasi penyimpanan DACPAC. Jika tidak, selalu lebih cepat untuk menggunakan disk yang ada di komputer tempat database koleksi berada daripada drive jarak jauh.

Sekarang setelah Anda mengidentifikasi lokasi target untuk DACPAC dan memastikan bahwa Anda memiliki cukup ruang, saatnya untuk menghasilkan file DACPAC.

Buka jendela Prompt Perintah dan buka lokasi SqlPackage.exe. Untuk menghasilkan DACPAC, ganti nilai tempat penampung dengan nilai yang sesuai, lalu jalankan perintah berikut:

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

• Sumber Data: Instans SQL Server yang menghosting database koleksi Azure DevOps Server Anda.
• Katalog Awal: Nama database koleksi.
• targetFile: Lokasi pada disk dan nama file DACPAC.

Perintah pembuatan DACPAC yang berjalan di tingkat data Azure DevOps Server itu sendiri diperlihatkan dalam contoh berikut:

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

Output perintah adalah file DACPAC, yang dihasilkan dari koleksi database Foo yang disebut Foo.dacpac.

Mengonfigurasi koleksi Anda untuk migrasi

Setelah database koleksi Anda dipulihkan di Azure VM Anda, konfigurasikan masuk SQL untuk memungkinkan Azure DevOps Services tersambung ke database untuk memigrasikan data. Masuk ini hanya memungkinkan akses baca ke satu database.

Untuk memulai, buka SQL Server Management Studio pada VM, lalu buka jendela kueri baru terhadap database yang akan diimpor.

Atur pemulihan database menjadi sederhana:

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

Buat rincian masuk SQL untuk database, dan tetapkan rincian masuk tersebut '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>'

Mengikuti contoh Fabrikam kami, dua perintah SQL akan terlihat seperti contoh berikut:

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'

Catatan

Aktifkan mode autentikasi SQL Server dan Windows di SQL Server Management Studio pada VM. Jika Anda tidak mengaktifkan mode autentikasi, migrasi gagal.

Mengonfigurasi file spesifikasi migrasi untuk menargetkan VM

Perbarui file spesifikasi migrasi untuk menyertakan informasi tentang cara menyambungkan ke instans SQL Server. Buka file spesifikasi migrasi Anda dan buat pembaruan berikut.

1. Hapus parameter DACPAC dari objek file sumber.

   Spesifikasi migrasi sebelum perubahan ditampilkan dalam kode berikut.

   

   Spesifikasi migrasi setelah perubahan ditampilkan dalam kode berikut.

   

2. Isi parameter yang diperlukan dan tambahkan objek properti berikut dalam objek sumber Anda dalam file spesifikasi.

   "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" 
   }
   

Setelah Anda menerapkan perubahan, spesifikasi migrasi terlihat seperti contoh berikut.

Spesifikasi migrasi Anda sekarang dikonfigurasi untuk menggunakan SQL Azure VM untuk migrasi. Lanjutkan dengan langkah-langkah persiapan lainnya untuk migrasi ke Azure DevOps Services. Setelah migrasi selesai, pastikan untuk menghapus kredensial masuk SQL atau mengganti kata sandi. Microsoft tidak menyimpan informasi masuk setelah migrasi selesai.

Langkah 3: Unggah file DACPAC

Catatan

Jika Anda menggunakan metode SQL Azure VM, Anda hanya perlu menyediakan string koneksi. Anda tidak perlu mengunggah file apa pun, dan Anda dapat melewati langkah ini.

DACPAC Anda harus ditempatkan dalam kontainer penyimpanan Azure, yang dapat menjadi kontainer yang sudah ada atau yang dibuat khusus untuk upaya migrasi Anda. Penting untuk memastikan bahwa kontainer Anda dibuat di lokasi geografis yang tepat.

Layanan Azure DevOps tersedia di beberapa lokasi geografis. Saat Anda mengimpor ke lokasi ini, sangat penting untuk menempatkan data Anda dengan benar untuk memastikan bahwa migrasi dapat dimulai dengan sukses. Data Anda harus ditempatkan di lokasi geografis yang sama dengan yang Anda impor. Menempatkan data di tempat lain menyebabkan migrasi tidak dapat dimulai. Tabel berikut mencantumkan lokasi geografis yang dapat diterima untuk membuat akun penyimpanan Anda dan mengunggah data Anda.

Lokasi geografis migrasi yang diinginkan	Lokasi geografis akun penyimpanan
Amerika Serikat Tengah	Amerika Serikat Tengah
Eropa Barat	Eropa Barat
Inggris Raya	Inggris Raya Selatan
Australia Timur	Australia Timur
Brasil Selatan	Brasil Selatan
India Tengah	India Tengah
Kanada Tengah	Kanada Tengah
Asia Pasifik (Singapura)	Asia Pasifik (Singapura)

Meskipun Layanan Azure DevOps tersedia di beberapa lokasi geografis di AS, hanya lokasi Amerika Serikat Pusat yang menerima Layanan Azure DevOps baru. Anda tidak dapat memigrasikan data Anda ke lokasi Azure AS lainnya saat ini.

Membuat sebuah kontainer blob dari portal Azure. Setelah Anda membuat wadah, unggah file Koleksi DACPAC.

Setelah migrasi selesai, hapus kontainer blob dan akun penyimpanan yang menyertai alat seperti AzCopy atau alat penjelajah penyimpanan Azure lainnya.

Catatan

Jika file DACPAC Anda lebih besar dari 10 GB, kami sarankan Anda menggunakan AzCopy, karena memiliki dukungan unggahan multithreaded untuk unggahan yang lebih cepat.

Langkah 4: Hasilkan token SAS

Token tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan ke sumber daya di akun penyimpanan. Token ini memungkinkan Anda untuk memberi Microsoft tingkat hak istimewa terendah yang diperlukan untuk mengakses data Anda untuk menjalankan migrasi.

Anda dapat menghasilkan token SAS menggunakan portal Azure. Dari sudut pandang keamanan, sebaiknya lakukan tugas berikut:

1. Pilih hanya Baca dan Daftar sebagai izin untuk token SAS Anda. Tidak diperlukan izin lain.
2. Tetapkan waktu kedaluwarsa tidak lebih dari tujuh hari ke depan.
3. Batasi akses ke IP Azure DevOps Services saja.
4. Perlakukan kunci SAS sebagai rahasia. Jangan tinggalkan kunci di lokasi yang tidak aman karena memberikan akses baca dan daftar ke data apa pun yang disimpan dalam kontainer.

Langkah 5: Selesaikan spesifikasi migrasi

Sebelumnya dalam proses Anda mengisi sebagian file spesifikasi migrasi, yang dikenal sebagai migration.json. Saat ini, Anda memiliki informasi yang cukup untuk melengkapi semua bidang yang tersisa kecuali jenis migrasi. Jenis migrasi tercakup nanti, di bagian migrasi.

Dalam file spesifikasi migration.json, di bawah Sumber, selesaikan bidang berikut ini.

• Lokasi: Tempelkan kunci SAS yang Anda buat dari skrip lalu salin di langkah sebelumnya.
• Dacpac: Pastikan bahwa file, termasuk ekstensi file .dacpac , memiliki nama yang sama dengan file DACPAC yang Anda unggah ke akun penyimpanan.

File spesifikasi migrasi akhir akan terlihat seperti contoh berikut.

Menentukan jenis migrasi

Impor dapat diantrekan sebagai uji coba (DryRun) atau produksi (ProductionRun). Parameter ImportType menentukan jenis migrasi:

• DryRun: Juga disebut sebagai uji coba. Gunakan untuk tujuan pengujian dan validasi. Sistem menghapus eksekusi pengujian setelah 45 hari.
• ProductionRun: Gunakan eksekusi produksi saat Anda ingin menyimpan migrasi yang dihasilkan dan menggunakan organisasi penuh waktu di Azure DevOps Services setelah migrasi selesai.

Kiat

Kami selalu menyarankan agar Anda menyelesaikan migrasi uji coba terlebih dahulu.

Organisasi Uji Coba

Organisasi uji coba membantu tim menguji migrasi koleksi mereka. Sebelum migrasi produksi dapat dijalankan, organisasi eksekusi pengujian yang telah selesai harus dihapus. Semua organisasi uji coba memiliki keberadaan terbatas dan secara otomatis dihapus setelah periode waktu yang ditetapkan. Informasi tentang kapan organisasi dihapus disertakan dalam email keberhasilan yang harus Anda terima setelah migrasi selesai. Pastikan untuk mencatat tanggal ini dan merencanakan sesuai.

Organisasi uji coba memiliki waktu 45 hari sebelum dihapus. Setelah periode waktu yang ditentukan, organisasi uji coba dihapus. Anda dapat mengulangi impor uji coba sebanyak yang Anda butuhkan sebelum melakukan migrasi produksi.

Menghapus eksekusi pengujian

Hapus eksekusi pengujian sebelumnya sebelum Anda mencoba yang baru. Saat tim Anda siap untuk melakukan migrasi produksi, Anda perlu menghapus organisasi uji coba secara manual. Sebelum Anda dapat menjalankan migrasi uji coba kedua atau migrasi produksi akhir, pastikan Anda menghapus organisasi Azure DevOps Services sebelumnya yang Anda buat dalam eksekusi pengujian sebelumnya. Untuk informasi selengkapnya, lihat Menghapus organisasi.

Kiat

Informasi opsional untuk membantu pengguna menjadi lebih suksesMenjalankan migrasi uji coba yang mengikuti yang pertama diharapkan memakan waktu lebih lama mengingat waktu tambahan yang diperlukan untuk membersihkan sumber daya dari eksekusi pengujian sebelumnya.

Diperlukan waktu hingga satu jam agar nama organisasi tersedia setelah menghapus atau mengganti nama. Untuk informasi selengkapnya, lihat artikel Tugas pascamigrasi .

Jika Anda mengalami masalah migrasi, lihat Pemecahan masalah migrasi dan kesalahan migrasi.

Menjalankan migrasi

Tim Anda sekarang siap untuk memulai proses menjalankan migrasi. Kami menyarankan agar Anda memulai dengan migrasi uji coba yang berhasil sebelum mencoba migrasi ke lingkungan produksi. Dengan melakukan impor uji coba, Anda dapat melihat terlebih dahulu bagaimana migrasi akan tampak, mengidentifikasi potensi masalah, dan mendapatkan pengalaman sebelum melanjutkan ke proses produksi.

Catatan

• Jika Anda perlu mengulangi migrasi pada proses produksi yang telah selesai untuk koleksi, seperti karena adanya pemulihan, hubungi Azure DevOps Services Dukungan Pelanggan sebelum Anda mengantrekan migrasi lainnya.

• Administrator Azure dapat mencegah pengguna membuat organisasi Azure DevOps baru. Jika kebijakan penyewa Microsoft Entra diaktifkan, migrasi Anda gagal diselesaikan. Sebelum memulai, verifikasi bahwa kebijakan tidak ditetapkan atau ada pengecualian untuk pengguna yang melakukan migrasi. Untuk informasi selengkapnya, lihat Membatasi pembuatan organisasi melalui kebijakan penyewa Microsoft Entra.
• Azure DevOps Services tidak mendukung kebijakan retensi untuk setiap pipeline, dan kebijakan tersebut tidak diterapkan pada versi yang dihosting.

Pertimbangan untuk rencana pembatalan

Kekhawatiran umum bagi tim yang melakukan proses produksi akhir adalah rencana pembatalan mereka, jika ada yang salah dengan migrasi. Sebaiknya lakukan uji coba untuk memastikan bahwa Anda dapat menguji pengaturan migrasi yang Anda berikan ke Alat Migrasi Data untuk Azure DevOps.

Proses rollback untuk tahap produksi akhir cukup sederhana. Sebelum Anda mengantre migrasi, lepaskan koleksi proyek tim dari Azure DevOps Server, yang membuatnya tidak tersedia untuk anggota tim Anda. Jika karena alasan apa pun Anda perlu mengembalikan eksekusi produksi dan membawa server lokal kembali online untuk anggota tim Anda, Anda dapat melakukannya. Lampirkan kembali koleksi proyek tim di lokasi dan memberitahukan tim Anda bahwa mereka dapat terus bekerja secara normal sementara tim Anda berkumpul kembali untuk memahami kemungkinan kegagalan.

Anda kemudian dapat menghubungi dukungan pelanggan Azure DevOps Services untuk bantuan dalam memahami penyebab kegagalan jika Anda tidak dapat menentukan penyebabnya. Untuk informasi selengkapnya, lihat artikel Pemecahan Masalah. Tiket dukungan pelanggan dapat dibuka dari halaman https://aka.ms/AzureDevOpsImportSupportberikut. Jika masalah mengharuskan teknisi grup produk terlibat, kasus-kasus tersebut ditangani selama jam kerja reguler.

Lepaskan koleksi proyek tim Anda dari Azure DevOps Server untuk menyiapkannya untuk migrasi.

Sebelum membuat cadangan database SQL, Anda harus sepenuhnya melepaskan koleksi dari Azure DevOps Server (bukan SQL) menggunakan Alat Migrasi Data. Proses penghapusan di Azure DevOps Server mentransfer informasi identitas pengguna yang disimpan di luar database koleksi, membuatnya portabel untuk pindah ke server baru atau, dalam hal ini, ke Azure DevOps Services.

Melepaskan koleksi mudah dilakukan dari Konsol Administrasi Azure DevOps Server pada instans Azure DevOps Server Anda. Untuk informasi selengkapnya, lihat Memindahkan koleksi proyek, Melepaskan koleksi.

Memulai antrean untuk migrasi

Penting

Sebelum melanjutkan, pastikan koleksi Anda sudah dipisahkan sebelum Anda membuat file DACPAC atau mengunggah database koleksi ke SQL Azure VM. Jika Anda tidak menyelesaikan langkah ini, migrasi gagal. Jika migrasi Anda gagal, lihat Mengatasi kesalahan migrasi.

Mulai migrasi dengan menggunakan perintah impor Alat Migrasi Data. Perintah impor mengambil file spesifikasi migrasi sebagai input. Ini menguraikan file untuk memastikan bahwa nilai yang disediakan valid dan, jika berhasil, ia mengantrekan migrasi ke Azure DevOps Services. Perintah impor memerlukan koneksi internet, tetapi tidak* memerlukan koneksi ke instans Azure DevOps Server Anda.

Untuk memulai, buka jendela Command Prompt, dan ubah direktori ke jalur Alat Migrasi Data. Kami menyarankan agar Anda meninjau teks bantuan yang disediakan dengan alat ini. Jalankan perintah berikut untuk melihat panduan dan bantuan untuk perintah impor:

Migrator import /help

Perintah untuk mengantrekan migrasi memiliki struktur berikut:

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

Contoh berikut menunjukkan perintah impor yang telah selesai:

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

Setelah validasi berhasil, masuk ke Microsoft Entra ID dengan identitas yang merupakan anggota dari penyewa Microsoft Entra yang sama dengan tempat file log peta identitas tersebut dibuat. Pengguna yang masuk adalah pemilik dari organisasi yang diimpor.

Catatan

Setiap tenant Microsoft Entra dibatasi maksimal lima impor per periode 24 jam. Hanya impor yang sedang berada dalam antrean yang dihitung terhadap batas ini.

Saat tim Anda memulai migrasi, pemberitahuan email dikirim ke pengguna yang mengantrekan migrasi. Sekitar 5 hingga 10 menit setelah antrean migrasi dimulai, tim Anda dapat mengunjungi organisasi untuk memeriksa statusnya. Setelah migrasi selesai, tim Anda diarahkan untuk masuk, dan pemberitahuan email dikirim ke pemilik organisasi.

Alat Migrasi Data menandai kesalahan yang perlu Anda koreksi sebelum migrasi. Artikel ini menjelaskan peringatan dan kesalahan paling umum yang mungkin Anda terima saat bersiap untuk bermigrasi. Setelah Anda memperbaiki setiap kesalahan, jalankan perintah validasi migrator lagi untuk memverifikasi resolusi.

Langkah berikutnya

Mengatasi kesalahan migrasi

Konten terkait

• Gambaran umum migrasi
• Tugas pasca migrasi