Pola dan strategi migrasi tenant Power BI

Organisasi menghadapi berbagai skenario migrasi penyewa di Power BI, didorong oleh merger dan akuisisi, diveestmen perusahaan, persyaratan residensi data, atau kebutuhan kepatuhan regional. Migrasi penyewa adalah usaha kompleks yang memerlukan perencanaan yang cermat, strategi pencadangan komprehensif, dan eksekusi sistematis. Artikel ini menyediakan panduan untuk migrasi penyewa Power BI skala perusahaan, termasuk kerangka kerja keputusan untuk membantu menentukan apakah migrasi diperlukan, dan metodologi implementasi terperinci untuk pola migrasi yang berbeda.

Important

Migrasi penyewa membawa risiko yang signifikan dan memerlukan upaya manual yang luas. Microsoft tidak memberikan dukungan langsung untuk memigrasikan konten antar penyewa atau dalam penyewa yang sama selama relokasi regional. Sebelum melanjutkan migrasi apa pun, evaluasi alternatif dengan cermat seperti kapasitas multi-geografis yang dapat mengatasi banyak skenario tanpa kompleksitas dan risiko migrasi penyewa penuh.

Skenario migrasi penyewa

Power BI migrasi penyewa mencakup tiga skenario. Identifikasi mana yang berlaku untuk situasi Anda sebelum Merencanakan migrasi Anda.

Skenario Description Pemicu umum
Migrasi berdampingan (lintas penyewa) Dua penyewa Microsoft 365 terpisah beroperasi secara paralel. Artefak dipindahkan dari penyewa sumber ke penyewa target satu per satu. Merger dan akuisisi yang menyatukan dua organisasi ke dalam satu tenant.
Pemisahan penyewa Satu tenant Power BI dipisahkan menjadi dua tenant yang terpisah. Artefak, ruang kerja, dan pengguna yang dimiliki oleh entitas bisnis yang keluar dipisahkan secara selektif. Divestasi dan pemisahan usaha.
Pemetaan ulang tenant (relokasi tenant) Tenant Power BI dihapus dan dibuat ulang di wilayah asal yang baru dalam tenant Microsoft 365 yang sama. ID penyewa, domain, dan identitas pengguna Microsoft 365 dipertahankan. Untuk informasi selengkapnya, lihat Move Power BI antar wilayah geografis. Persyaratan residensi data yang mengharuskan wilayah asal tenant berada di negara/wilayah tertentu.

Migrasi berdampingan dan pemisahan penyewa adalah operasi lintas penyewa . Pemetaan ulang tenant adalah relokasi wilayah di dalam tenant Microsoft 365 yang sama.

Note

Untuk pertimbangan dan batasan terkait pemetaan ulang penyewa (relokasi regional) dengan Dukungan Microsoft, lihat Memindahkan penyewa Power BI Anda ke wilayah lain. Bantuan dari Microsoft Support terbatas pada penghapusan tenant sebelumnya dan pemetaan ulang tenant baru ke wilayah yang ditentukan; bantuan migrasi tidak disediakan. Anda harus memiliki rencana rehidrasi untuk data dan metadata, baik melalui pencadangan dan pemulihan berskrip, tindakan manual, atau proses rekreasi dan pemuatan ulang. Prosedur ini membawa risiko yang cukup besar, termasuk potensi kehilangan data atau artefak jika cadangan tidak lengkap atau artefak dihilangkan. Waktu henti selama pemetaan ulang tenant dapat berkisar antara tiga hingga 24 jam, dan waktu henti dapat lebih lama jika diperlukan pemulihan artefak.

Mengevaluasi alternatif sebelum bermigrasi

Migrasi penyewa melibatkan risiko dan upaya yang cukup besar. Jelajahi opsi alternatif sebelum melanjutkan. Strategi berikut mungkin membantu Anda menghindari migrasi atau relokasi penyewa.

Penerapan multi-geo

Penyebaran multi-geo memungkinkan Anda menyebarkan kapasitas Power BI dan Fabric di wilayah pilihan Anda sambil menjaga wilayah asal penyewa Anda tidak berubah. Data dalam kapasitas tersebut tetap dekat dengan pengguna akhir Anda, dan Anda dapat memiliki beberapa kapasitas di berbagai wilayah di bawah penyewa yang sama.

Memigrasikan artefak ke kapasitas di wilayah yang berbeda lebih sederhana daripada memigrasikan penyewa itu sendiri. Untuk memindahkan ruang kerja ke wilayah lain, menetapkan ulang ruang kerja dari satu kapasitas ke kapasitas lainnya. Penugasan ulang berjalan lancar untuk item Power BI.

Important

Fabric item tidak bertahan dari penetapan ulang ruang kerja di seluruh kapasitas di berbagai wilayah. Hapus item Fabric sebelum penetapan ulang ruang kerja dan buat ulang setelahnya, atau gunakan integrasi Git untuk mencadangkan dan memulihkan item Fabric.

Pertimbangkan penyebaran multi-geo untuk persyaratan berikut:

  • Latensi data. Tempatkan data dan komputasi lebih dekat dengan pengguna akhir dengan menyebarkan kapasitas di wilayah mereka.
  • Lokasi data. Data dan komputasi Anda terkait dengan wilayah kapasitas Anda, bukan wilayah penyewa Anda. Penerapan multi-geo menjaga data tetap berada dalam batas wilayah residensi data untuk sebagian besar beban kerja.

Hanya pertimbangkan pemetaan ulang penyewa jika persyaratan residensi data sedemikian ketat sehingga bahkan metadata penyewa (definisi ruang kerja, metadata model semantik, metadata visual, pengaturan, kebijakan) dan informasi pengguna Microsoft 365 harus tetap berada dalam batasan residensi data.

Membawa akun penyimpanan Anda sendiri untuk Dataflow Gen1

Dataflow Gen1 menulis outputnya ke akun Azure Data Lake Storage (ADLS) Gen2 yang, secara default, berada di wilayah asal penyewa Power BI. Jika lokasi penyimpanan Dataflow Gen1 adalah satu-satunya masalah residensi Anda, konfigurasikan akun ADLS Gen2 milik Anda sendiri di wilayah yang diinginkan alih-alih merelokasi penyewa.

Relai Azure kustom untuk ketidakcocokan wilayah gateway

Jika kapasitas Anda disebarkan di wilayah yang berbeda dari wilayah asal penyewa Anda, titik akhir gateway data lokal default merutekan lalu lintas kembali ke wilayah asal. Untuk menjaga lalu lintas gateway di wilayah kapasitas Anda, konfigurasikan Azure Relay kustom. Hanya ketidakcocokan wilayah gateway seharusnya tidak memicu migrasi tenant.

Meninjau kasus bisnis

Jika migrasi penyewa didorong oleh kebutuhan bisnis (misalnya, konsolidasi penagihan), pertimbangkan upaya dan risiko terhadap hasilnya. Tenant kecil mungkin relatif mudah untuk dimigrasikan; tenant besar dengan konten Fabric yang signifikan mungkin memerlukan peninjauan kembali terhadap kebutuhan bisnis sebelum melanjutkan.

Apa yang didukung untuk migrasi

Sebagian besar item Power BI mendukung ekspor definisi melalui API Admin Power BI atau Workspace Scanner API dan dapat diskrip. Sebagian besar item Fabric tidak mendukung ekspor definisi dan harus dibuat ulang secara manual.

Tabel berikut ini meringkas jalur migrasi untuk setiap jenis artefak.

Pesanan Artifact Jalur migrasi
1 Gateways Tidak ada jalur migrasi. Harus dikonfigurasi ulang di tenant target oleh administrator Power BI.
2 Ruang kerja Tidak ada jalur migrasi. Harus dibuat ulang di penyewa target. Pembuatan massal dimungkinkan menggunakan POWER BI Admin API.
3 Barang kain Item yang mendukung integrasi Git dapat dicadangkan dengan melakukan commit ke Git, melepas tautan dari ruang kerja sumber, dan menautkan ulang ke ruang kerja baru di tenant target. Hanya definisi saja yang dicadangkan; data tidak disertakan. Item yang tidak mendukung integrasi Git harus dibuat ulang secara manual. Untuk Lakehouse, hanya metadata yang dipertahankan; tabel delta dan skema tidak ditransfer.
4 Dataflows Unduh definisi JSON dan impor ulang ke penyewa target. Pembuatan skrip dimungkinkan menggunakan API Admin.
5 Model / himpunan data semantik Gunakan pencadangan dan pemulihan ke akun penyimpanan ADLS Gen2, atau unduh definisi dan impor ulang. Pembuatan skrip dimungkinkan menggunakan API Admin.
6 Reports Pemilik atau admin mengunduh file .pbix dan menerbitkannya ulang ke tenant target. Atau, ekspor definisi JSON. Pembuatan skrip dimungkinkan menggunakan API Admin.
7 Dasbor Tidak ada jalur migrasi. Harus dibuat ulang secara manual.
8 aplikasi Power BI Tidak ada jalur migrasi. Harus dibuat ulang secara manual.
9 Laporan terpaginasi Pemilik atau admin mengunduh file RDL dan menerbitkan ke penyewa target.

Important

Selalu buat ulang artefak dalam urutan ini. Artefak hilir bergantung pada artefak hulu, dan melewati urutan tersebut dapat menyebabkan referensi yang rusak selama eksekusi. Melakukan sinkronisasi Git menghapus semua item di ruang kerja yang tidak ada di repositori.

Metodologi migrasi

Pertimbangkan aktivitas acuan berikut. Sebagian besar langkah berlaku untuk ketiga skenario. Langkah-langkah yang spesifik untuk skenario tertentu ditandai pada judulnya.

Langkah 1: Penilaian penemuan dan inventori

Buat inventaris lengkap artefak dan dependensi, dan identifikasi apa yang dapat, tidak dapat, atau tidak boleh Anda migrasikan.

Aktivitas

  • Jalankan penemuan di seluruh tenant menggunakan kombinasi:
    • POWER BI ADMIN API
    • API Admin Fabric
    • Log aktivitas (ruang kerja, laporan, himpunan data, refresh)
    • Dokumentasi manual untuk item yang tidak diekspos oleh API
  • Menangkap:
    • Ruang kerja (jenis, kapasitas, wilayah)
    • Laporan, model semantik (terutama format penyimpanan besar), aliran data
    • Fabric item (Lakehouse, Warehouse, Eventhouse, notebooks)
    • Gateway, sumber data, kredensial
    • Peran keamanan tingkat baris (RLS), izin ruang kerja, tautan berbagi
  • Mengklasifikasikan setiap ruang kerja berdasarkan kompleksitas migrasi (rendah, sedang, tinggi) berdasarkan artefak yang dikandungnya dan dependensinya.

Outputs

  • Lembar kerja inventaris utama.
  • Klasifikasi kompleksitas migrasi untuk setiap ruang kerja.

Langkah 2: Penemuan pengguna dan keamanan

Catat identitas pengguna, lisensi, dan izin, lalu petakan antar-tenant jika diperlukan.

Dalam remap penyewa, ID objek pengguna dipertahankan. Untuk migrasi paralel atau pemisahan tenant, pengguna memiliki ID objek yang berbeda di tenant target. Petakan setiap identitas penyewa sumber ke identitas penyewa targetnya. Tetapkan ulang penugasan lisensi Power BI (Gratis, Pro, PPU). Cerminkan grup keamanan di tenant Microsoft 365 yang baru.

Aktivitas

Identifikasi dan rekam:

  • Penugasan lisensi Power BI (bersumber dari Microsoft Graph)
  • ID objek pengguna di tenant sumber
  • ID objek pengguna di tenant target (berdampingan atau terpisah saja)
  • Izin pengguna dan tingkat akses ruang kerja
  • Pengaturan tingkat penyewa saat ini (catat secara manual melalui portal admin)
  • Konfigurasi tata kelola saat ini (label sensitivitas, kebijakan dukungan)

Anda dapat mengekstrak izin ruang kerja dan artefak dengan menggunakan API Admin Power BI dan API Pemindai Workspace.

Langkah 3: Manajemen komunikasi dan perubahan pemangku kepentingan

Komunikasikan rencana migrasi lebih awal untuk mengurangi ketahanan dan beban dukungan.

Grup pemangku kepentingan utama

  • Sponsor eksekutif
  • Pemilik ruang kerja dan penulis laporan
  • Pengguna akhir
  • Tim TI, keamanan, dan identitas

Aktivitas

  • Kembangkan rencana komunikasi yang mencakup:
    • Gambaran umum dan alasan migrasi.
    • Apa saja yang dimigrasikan dan yang tidak (misalnya, ruang kerja pribadi, ruang kerja tidak aktif).
    • Perubahan apa (URL, akses, pengaturan waktu refresh). Tautan Power Apps hilir dan SharePoint yang mereferensikan URL Power BI juga terpengaruh.
    • Apa yang tidak berubah (semantik data, visual, logika bisnis).
  • Komunikasikan tanggal-tanggal penting:
    • Periode pembekuan (biasanya sekitar satu minggu tanpa perubahan pada tenant sumber selama pencadangan akhir).
    • Perkiraan waktu henti (untuk skenario pemetaan ulang tenant).
    • Periode validasi agar pemangku kepentingan dapat memverifikasi laporan mereka sendiri di tenant target.
    • Tonggak pencapaian cutover dan tanggal dekomisioning untuk tenant sumber (skenario side-by-side).

Outputs

  • Sebuah dek pengarahan pemangku kepentingan.
  • FAQ pengguna akhir.

Langkah 4: Ajukan permintaan pemetaan ulang penyewa (khusus pemetaan ulang penyewa)

Saat tanggal migrasi telah dikunci, ajukan tiket dukungan dan pilih secara spesifik opsi remap tenant. Teknisi dukungan Microsoft mengambil permintaan.

Aktivitas

  • Kirimkan tiket dukungan.
  • Lengkapi daftar periksa kesiapan yang disediakan oleh Microsoft.
  • Sepakati tanggal migrasi dan slot waktu, termasuk slot waktu cadangan.
  • Hapus kapasitas yang ada sebelum tenant dipetakan ulang.

Hasil yang diharapkan

  • Remap biasanya memakan waktu sekitar tiga jam, tetapi penundaan hingga 24 jam dapat terjadi jika muncul komplikasi.
  • Setelah remap selesai, penyewa baru memiliki ID penyewa yang sama dan terletak di wilayah yang diminta.

Langkah 5: Kesiapan penyewa target

Tenant yang baru dibuat atau baru dipetakan ulang tidak langsung siap untuk menerima konten. Konfigurasikan terlebih dahulu.

Aktivitas

  • Konfigurasi pengaturan tenant Power BI:
    • Kontrol pembuatan ruang kerja
    • Kebijakan berbagi dan akses eksternal
    • Tata kelola visual kustom
    • Label sensitivitas dan perlindungan informasi
    • Pengaktifan log audit dan pemantauan
  • Beli kapasitas Fabric dengan SKU yang sama atau lebih tinggi daripada sumber.
  • Mengonfigurasi dan memvalidasi gateway, kluster gateway, dan konektivitas data.
  • Untuk skenario berdampingan atau pemisahan tenant:
    • Buat pengguna di tenant target untuk setiap pengguna di tenant sumber, dan catat pemetaan pengguna.
    • Buat ulang kelompok pengguna dari tenant sumber.
    • Tetapkan lisensi Power BI di penyewa target.
  • Menyelaraskan tata kelola: label sensitivitas, integrasi Microsoft Purview, dan kebijakan dukungan.

Langkah 6: Pilot migrasi

Jalankan migrasi pengujian pada ruang kerja sampel perwakilan sebelum migrasi produksi.

Untuk migrasi paralel, tenant sumber tetap tersedia sebagai cadangan untuk percobaan ulang. Dalam proses remap penyewa, konten yang tidak dicadangkan dengan benar sebelum remap tidak akan dapat dipulihkan. Uji coba yang berhasil adalah cara utama untuk mengurangi risiko dalam proses remap.

Kriteria pemilihan ruang kerja pilot

  • Berisi campuran artefak: laporan, model semantik, aliran data, dan item Fabric.
  • Menggunakan sumber data yang realistis dan jadwal penyegaran.
  • Memiliki izin tingkat ruang kerja dan idealnya RLS.
  • Digunakan secara aktif, tetapi tidak kritis bagi operasional.

Langkah 7: Eksekusi migrasi

Jalankan migrasi. Item yang didukung diskrip terlebih dahulu; item yang tidak didukung dibuat ulang secara manual.

Untuk tenant besar, tulis skrip pembungkus untuk Power BI Admin API guna mengekspor dan membuat ulang artefak secara massal.

Buat ulang artefak dalam urutan yang ditentukan dalam Apa yang didukung untuk migrasi. Melewati urutan akan merusak dependensi.

Langkah 8: Validasi dan pengujian

Validasi bahwa konten berhasil dimigrasikan dan berperilaku dengan benar.

Definisi model semantik yang diekspor tidak menyertakan data yang mendasar. Setiap model semantik yang diimpor memerlukan setidaknya satu penyegaran manual di tenant target.

Tip

Pertimbangkan untuk menskalakan sementara ke SKU kapasitas yang lebih tinggi selama validasi. Jika tidak, sejumlah besar penyegaran yang terjadi secara bersamaan dapat membebani kapasitas target hingga penuh.

Aktivitas

  • Validasi data: jumlah baris, agregat utama, keberhasilan penyegaran.
  • Memvalidasi keamanan: Aturan RLS, akses ruang kerja, cakupan berbagi.
  • Validasi performa: waktu pemuatan laporan, daya tanggap kueri, cadangan kapasitas.

Langkah 9: Cutover dan adopsi pengguna

Pindahkan pengguna ke penyewa target dan perbarui aplikasi hilir.

Aktivitas

  • Berikan pengguna akses ke ruang kerja dan artefak di penyewa target.
  • Perbarui URL laporan yang disematkan, tautan SharePoint, koneksi Power Apps, dan alur Power Automate yang mereferensikan konten Power BI.
  • Nonaktifkan pengeditan di tenant sumber (fase hanya baca) sebelum penghentian akhir.
  • Jalankan sesi pengaktifan singkat yang mencakup apa yang berubah dan di mana menemukan konten.

Konten terkait

  • Last updated on