Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Rencana migrasi menentukan urutan, waktu, dan pendekatan tertentu untuk memigrasikan beban kerja ke Azure. Rencana ini menerjemahkan strategi migrasi tingkat tinggi ke dalam urutan penyebaran yang dapat ditindaklanjuti. Ini dibangun berdasarkan rencana adopsi cloud dengan mengatasi keputusan taktis seperti prioritas beban kerja, pengurutan migrasi, dan metode transfer data.
Prasyarat:Rencana adopsi migrasi, zona pendaratan Azure
Menilai kesiapan dan keterampilan migrasi
Penilaian kesiapan memastikan bahwa tim Anda memiliki keterampilan dan dukungan yang diperlukan untuk menjalankan rencana migrasi. Langkah ini mengidentifikasi kesenjangan kemampuan dan mempercepat kemajuan melalui pelatihan yang ditargetkan atau dukungan eksternal.
Evaluasi keterampilan Azure tim Anda. Tinjau pengalaman tim Anda dengan layanan Azure, alat migrasi, dan cutover. Evaluasi ini membantu Anda mengidentifikasi kesenjangan pengetahuan tertentu dan menentukan pelatihan apa yang dibutuhkan tim Anda untuk berhasil.
Libatkan keahlian eksternal saat diperlukan. Jika tim Anda tidak memiliki pengalaman dengan migrasi cloud, bawa Microsoft atau mitra Microsoft. Pakar eksternal dapat memvalidasi strategi migrasi Anda, merekomendasikan alat yang sesuai, dan membantu membangun garis waktu yang realistis. Dukungan ini mengurangi risiko dan mempercepat migrasi Anda, terutama untuk proyek skala kompleks atau besar.
Memilih jalur migrasi data Anda
Jalur migrasi data adalah cara Anda memindahkan data dari lokasi Anda saat ini ke Azure. Jalur yang tepat memastikan transfer data Anda dengan aman, cepat, dan hemat biaya. Pertama, periksa koneksi jaringan apa yang Anda miliki, ExpressRoute, VPN, atau internet publik, untuk memahami opsi Anda.
Gunakan ExpressRoute saat Anda memilikinya. ExpressRoute memberi Anda koneksi privat dan khusus ke Azure yang lebih cepat dan lebih aman daripada koneksi internet. Jika Anda sudah memiliki ExpressRoute atau berencana untuk mendapatkannya, gunakan metode ini untuk semua beban kerja Anda. Perlu diingat bahwa ExpressRoute memerlukan waktu penyiapan dan memiliki biaya transfer data.
Gunakan VPN jika ExpressRoute tidak tersedia. Pilih VPN saat Anda memerlukan transfer data yang aman tetapi tidak memiliki ExpressRoute. VPN membuat terowongan terenkripsi melalui internet ke Azure, meskipun biasanya lebih lambat dari ExpressRoute. Pastikan Anda memiliki VPN Gateway yang dikonfigurasi di Azure sebelum memulai.
Gunakan Azure Data Box untuk data dalam jumlah besar. Data Box adalah yang terbaik untuk migrasi offline dengan banyak data. Microsoft mengirimkan perangkat fisik untuk menyalin data Anda ke, lalu Anda mengirimkannya kembali. Opsi ini menghindari penggunaan jaringan Anda tetapi membutuhkan waktu paling lama karena waktu pengiriman.
Gunakan internet publik untuk data yang kurang sensitif. Opsi ini berfungsi saat data Anda tidak memerlukan enkripsi dan Anda tidak dapat menggunakan ExpressRoute atau Data Box. Meskipun metode ini tersedia di mana-mana, metode ini paling tidak aman dan dapat memperlambat aktivitas internet Anda yang lain.
| Jalur Migrasi Data | Kapan harus menggunakan | Pros | Cons |
|---|---|---|---|
| ExpressRoute | Beban kerja apa pun jika tersedia | Aman dan cepat | Pemasangan diperlukan, memerlukan biaya |
| VPN | Transfer aman saat tidak ada ExpressRoute | Lebih aman daripada internet publik | Memerlukan penyiapan, lebih lambat dari ExpressRoute |
| Azure Data Box | Migrasi offline dengan data dalam jumlah besar | Memindahkan data tanpa menggunakan jaringan Anda | Metode paling lambat karena pengiriman |
| Internet publik | Data yang tidak sensitif dan tidak dapat menggunakan Data Box | Bekerja di mana-mana | Paling rentan, memanfaatkan bandwidth Anda |
Menentukan urutan migrasi
Pengurutan migrasi mengurangi risiko dan membangun kepercayaan tim dengan menetapkan urutan logis untuk migrasi beban kerja. Urutan menentukan beban kerja mana yang bergerak terlebih dahulu dan bagaimana komponen dependen bermigrasi bersama untuk mencegah gangguan layanan. Atur portofolio besar ke dalam gelombang migrasi. Untuk panduan terperinci tentang perencanaan gelombang, lihat Perencanaan gelombang migrasi.
Menemukan dependensi
Temukan semua dependensi terlebih dahulu. Dependensi antara beban kerja menyebabkan gangguan layanan jika tidak dimigrasikan bersama-sama. Petakan dependensi internal dan eksternal untuk menemukan koneksi ini sebelum membuat grup migrasi.
Menganalisis jenis dependensi dan kekritisan. Jenis dependensi yang berbeda memerlukan pendekatan migrasi yang berbeda. Membedakan antara kategori ini:
Jenis dependensi Description Pendekatan migrasi Dependensi langsung Memerlukan komunikasi langsung dan latensi rendah antar komponen. Pindahkan semua komponen yang terhubung langsung bersama-sama untuk menjaga performa dan menghindari gangguan. Dependensi tidak langsung Libatkan interaksi sesekali atau non-kritis antar sistem. Migrasi bersama-sama atau dalam gelombang terpisah jika koneksi mentolerir latensi atau mendukung penggunaan hibrid. Dependensi bisnis Bergantung pada hubungan organisasi atau manajemen. Mengelompokkan dan memigrasikan beban kerja terkait dan sistem pelaporan bersama-sama untuk selaras dengan prioritas bisnis. Mengelompokkan beban kerja menurut hubungan dependensi. Buat grup berdasarkan database bersama, API, layanan autentikasi, atau koneksi jaringan. Grup ini membentuk fondasi gelombang migrasi Anda dan memastikan semua komponen yang diperlukan untuk fungsionalitas bergerak bersama. Ketika ada ketidakpastian tentang kekritisan dependensi, kelompokkan komponen bersama-sama. Pendekatan konservatif ini memberikan fleksibilitas untuk pemisahan di masa mendatang.
Dokumentasikan setiap grup dependensi secara sistematis. Menandai aset berdasarkan grup dependensinya menggunakan konvensi penamaan yang konsisten. Dokumentasikan setiap grup dengan:
- Nama dan ID grup - Pengidentifikasi unik dan nama deskriptif
- Inventori komponen - Semua elemen infrastruktur, aplikasi, dan layanan
- Dependensi kritis - Koneksi penting yang memerlukan penanganan khusus
- Batasan migrasi - Persyaratan bisnis, teknis, atau waktu
Memeriksa kelengkapan grup. Konfirmasikan setiap grup menyertakan semua komponen yang diperlukan agar aplikasi dapat beroperasi, termasuk infrastruktur pendukung seperti load balancer, catatan DNS, atau lapisan penembolokan.
Menangani operasi lingkungan terpisah
Rencanakan dependensi yang tidak dapat dipindahkan. Identifikasi komponen yang harus tetap berada di lingkungan sumber Anda karena alasan teknis atau peraturan. Dokumentasikan mengapa mereka tidak dapat bergerak, bagaimana mereka terhubung ke sistem lain, dan data apa yang mereka bagikan. Dokumentasi ini membantu Anda membuat strategi agar komponen-komponen ini bekerja dengan lancar dengan sistem cloud Anda.
Minimalkan waktu operasi lingkungan terpisah. Ketika komponen dapat berpindah ke cloud nanti tetapi tidak segera, dokumentasikan koneksi dan aliran data mereka dengan sistem cloud. Buat rencana yang jelas dengan garis waktu dan pendekatan manajemen risiko untuk mengurangi waktu beban kerja Anda beroperasi di kedua lingkungan. Pertimbangkan untuk menunda migrasi hingga lebih banyak komponen dapat bergerak bersama.
Sambungkan lingkungan secara efektif. Gunakan metode integrasi seperti gateway API, antrean pesan, dan sinkronisasi data untuk membuat koneksi yang andal antara beban kerja cloud dan komponen lingkungan sumber Anda. Pendekatan ini mengurangi penundaan, meningkatkan keamanan, dan mempersiapkan cara untuk akhirnya memindahkan komponen yang tersisa ke cloud.
Memprioritaskan beban kerja untuk bermigrasi
Tinjau detail beban kerja. Bekerja sama dengan pemangku kepentingan untuk meninjau detail bisnis dan teknis untuk setiap beban kerja. Pastikan bahwa dampak waktu henti atau kegagalan dipahami dengan baik dan selaras dengan prioritas bisnis saat ini. Gunakan rencana adopsi migrasi untuk memverifikasi detail seperti unit bisnis, pemilik beban kerja, dependensi teknis, dan klasifikasi kritisitas. Detail ini membantu memprioritaskan dan mengurutkan beban kerja secara efektif.
Priority Nilai bisnis Effort Description High High Low Kemenangan cepat - bermigrasi terlebih dahulu untuk dampak langsung Sedang-Tinggi High High Investasi strategis - rencanakan dengan cermat dengan sumber daya yang memadai Menengah-Rendah Low Low Opsi yang mudah - mengisi celah di antara migrasi utama Low Low High Hindari atau tunda - fokuskan sumber daya pada peluang bernilai lebih tinggi Mulailah dengan beban kerja yang lebih sederhana untuk mengurangi risiko. Mulailah memigrasikan beban kerja yang kurang kompleks dan memiliki risiko yang lebih rendah. Pendekatan ini membantu tim Anda mendapatkan kepercayaan diri dan menyempurnakan proses migrasi sebelum mengatasi beban kerja yang lebih menantang. Menargetkan alat internal, lingkungan pengembangan, atau aplikasi penggunaan rendah dengan arsitektur mandiri dan titik integrasi minimal.
Pindahkan lingkungan non-produksi sebelum produksi. Lingkungan nonproduksi menyediakan ruang yang aman untuk menguji proses migrasi penuh. Migrasikan lingkungan pengembangan, penahapan, dan QA sebelum produksi untuk memvalidasi kesiapan. Urutan ini memungkinkan tim untuk menguji konfigurasi, performa, dan prosedur pemulihan tanpa memengaruhi pengguna. Gunakan migrasi nonproduksi untuk melatih tim operasi.
Jadwalkan sistem penting setelah Anda menunjukkan keberhasilan awal. Aplikasi penting memerlukan kemampuan migrasi yang terbukti sebelum Anda memindahkannya ke Azure. Rencanakan migrasi ini untuk gelombang selanjutnya saat tim Anda menunjukkan kompetensi dengan layanan Azure. Tenggat waktu bisnis seperti siklus refresh perangkat keras mungkin mengharuskan Anda memprioritaskan aplikasi penting sebelumnya dengan perlindungan yang lebih baik dan periode pengujian yang diperpanjang.
Sertakan beban kerja kompleks yang representatif untuk menguji skenario. Tambahkan satu atau dua beban kerja kompleks ke setiap gelombang awal untuk mengekspos tantangan yang Anda hadapi dengan aplikasi misi penting. Pilih beban kerja yang mewakili pola umum seperti aplikasi multi-tingkat atau sistem yang bergantung pada database.
Membuat jadwal migrasi terperinci
Atur tanggal mulai dan berakhir untuk setiap migrasi. Sertakan waktu buffer untuk pengujian dan resolusi masalah untuk memastikan kelancaran eksekusi. Penjadwalan terperinci ini mengurangi risiko penundaan dan mendukung perencanaan sumber daya yang efektif.
Menyelaraskan garis waktu dengan peristiwa bisnis. Hindari penjadwalan migrasi selama periode bisnis penting seperti penutupan keuangan, peluncuran produk, atau musim liburan. Penyelarasan ini mengurangi risiko gangguan bisnis dan memastikan kepercayaan pemangku kepentingan.
Gunakan alat manajemen proyek untuk melacak kemajuan. Gunakan alat seperti Azure DevOps untuk mengelola dependensi, melacak pencapaian, dan mengomunikasikan perubahan secara efektif. Alat-alat ini memberikan visibilitas ke dalam kemajuan migrasi dan mendukung penyelesaian masalah proaktif.
Pilih metode migrasi untuk setiap beban kerja
Metode migrasi termasuk dalam dua kategori: migrasi dengan waktu henti dan migrasi dengan waktu henti hampir nol. Pilih metode migrasi terbaik untuk setiap beban kerja berdasarkan toleransi waktu henti dan kekritisan bisnisnya.
Pilih migrasi waktu henti untuk beban kerja yang mentolerir pemadaman yang direncanakan. Migrasi waktu henti lebih sederhana dan lebih cepat karena tidak memerlukan sinkronisasi real time antara lingkungan sumber dan target. Metode ini berfungsi dengan baik untuk beban kerja noncritical seperti lingkungan pengembangan, sistem pengujian, atau aplikasi dengan jendela pemeliharaan terjadwal. Dokumentasikan durasi waktu henti yang dapat diterima untuk setiap beban kerja dan jadwalkan migrasi selama periode penggunaan rendah untuk meminimalkan efek bisnis.
Pilih migrasi dengan waktu henti hampir nol untuk beban kerja kritis. Migrasi dengan waktu henti hampir nol memastikan bahwa beban kerja penting tetap beroperasi selama transisi melalui replikasi data berkelanjutan dan teknik pergantian. Metode ini sangat penting untuk aplikasi yang menghadap pelanggan, sistem transaksi real-time, atau beban kerja dengan perjanjian tingkat layanan yang ketat. Validasi bahwa arsitektur beban kerja mendukung replikasi berkelanjutan dan bandwidth jaringan tersebut dapat menangani transfer data real time. Uji proses konektivitas dan replikasi di lingkungan nonproduksi untuk mengonfirmasi kesiapan untuk metode migrasi ini.
| Metode Migrasi | Kapan harus menggunakan | Pros | Cons |
|---|---|---|---|
| Migrasi saat tidak beroperasi | Beban kerja tidak kritis, lingkungan untuk pengembangan | Proses yang lebih sederhana, eksekusi yang lebih cepat | Gangguan layanan diperlukan |
| Migrasi dengan waktu henti hampir nol | Beban kerja penting, SLA yang ketat | Gangguan layanan minimal | Penyiapan kompleks dan memerlukan pengujian |
Tentukan rencana pembatalan
Rencana putar kembali memungkinkan tim untuk dengan cepat membalikkan perubahan ketika penyebaran gagal atau menimbulkan risiko. Rencana yang ditentukan dengan baik meminimalkan waktu henti, membatasi dampak bisnis, dan mempertahankan keandalan sistem. Selalu tetapkan kriteria dan prosedur pembatalan sebelum memulai migrasi atau penyebaran apa pun.
Definisikan penyebaran yang gagal. Berkolaborasi dengan pemangku kepentingan bisnis, pemilik beban kerja, dan tim operasi untuk memutuskan apa yang dihitung sebagai penyebaran yang gagal. Contohnya termasuk pemeriksaan kesehatan yang gagal, performa buruk, masalah keamanan, atau metrik keberhasilan yang tidak terukur. Definisi ini memastikan keputusan pembatalan selaras dengan toleransi risiko organisasi Anda. Sertakan kondisi tertentu yang memicu pembatalan dalam rencana penyebaran Anda, seperti batas penggunaan CPU, ambang waktu respons, atau tingkat kesalahan. Evaluasi ini membuat keputusan pemulihan menjadi jelas dan konsisten pada saat insiden.
Otomatisasi langkah rollback dalam alur CI/CD. Gunakan alat seperti Azure Pipelines atau GitHub Actions untuk mengotomatiskan proses putar kembali. Misalnya, konfigurasikan alur untuk menyebarkan ulang versi sebelumnya jika pemeriksaan kesehatan gagal.
Buat petunjuk pemulihan khusus untuk beban kerja tertentu. Kembangkan langkah putar kembali yang cocok dengan jenis beban kerja, lingkungan, dan metode penyebaran Anda. Misalnya, penyebaran infrastruktur sebagai kode memerlukan penerapan kembali templat sebelumnya. Pembatalan aplikasi melibatkan penyebaran ulang gambar kontainer sebelumnya. Lampirkan skrip putar kembali, rekam jepret konfigurasi, dan templat infrastruktur sebagai kode ke paket putar kembali Anda. Aset ini memungkinkan eksekusi cepat dan mengurangi ketergantungan pada intervensi manual.
Menguji prosedur pemulihan. Simulasikan kegagalan penerapan di lingkungan praproduksi untuk memvalidasi efektivitas rollback. Identifikasi dan atasi celah dalam otomatisasi, izin, atau dependensi. Pastikan bahwa pemulihan mengembalikan sistem ke kondisi stabil yang sehat.
Tingkatkan strategi pemulihan Setelah setiap penyebaran atau peristiwa rollback, lakukan retrospektif untuk menilai apa yang berhasil dan apa yang tidak. Perbarui kriteria putar kembali, prosedur, dan otomatisasi berdasarkan pelajaran yang dipelajari, perubahan arsitektur, atau alat baru. Pertahankan dokumentasi untuk memastikan strategi rollback tetap terkini dan efektif.
Libatkan pemangku kepentingan tentang rencana migrasi
Persetujuan pemangku kepentingan memvalidasi rencana migrasi Anda memenuhi persyaratan bisnis dan toleransi risiko. Anda harus mengamankan persetujuan formal sebelum menjalankan migrasi.
Dokumentasikan rencana migrasi dengan pembenaran bisnis. Buat rencana terstruktur yang menunjukkan nama beban kerja, pemilik, kekritisan, metode migrasi, jendela waktu henti, dan efek bisnis. Sertakan alasan untuk setiap pendekatan dan jelaskan bagaimana hal itu meminimalkan risiko.
Menyajikan prosedur putar kembali yang diuji. Tampilkan rencana putar kembali tertentu dengan langkah, jangka waktu, dan kriteria keberhasilan. Sertakan kemampuan otomatis dan manual. Mendokumentasikan hasil pengujian praproduksi untuk membuktikan pemulihan layanan yang cepat.
Validasi jadwal terhadap batasan bisnis. Tinjau garis waktu dengan pemangku kepentingan untuk menghindari periode bisnis penting, pembekuan pemeliharaan, dan puncak musiman. Berikan pilihan alternatif dengan pertukaran jika ada konflik.
Dapatkan persetujuan formal dan kewenangan melakukan rollback. Persetujuan tertulis yang aman dari pemangku kepentingan untuk rencana migrasi dan prosedur pembatalan. Tentukan otoritas pengambilan keputusan dan tetapkan saluran komunikasi darurat.
Tentukan kriteria keberhasilan dan tinjau titik pemeriksaan. Atur metrik terukur termasuk tolok ukur performa, validasi fungsionalitas, dan kriteria penerimaan pengguna. Jadwalkan titik tinjauan formal untuk keputusan lanjut/tidak lanjut.