Jika Anda ingin meluncurkan upaya transformasi digital Anda, langkah pertama yang bagus adalah menjelajahi berbagai kemungkinan di dalam cloud. Kami sering menemukan bahwa mentransisikan satu aplikasi pada satu waktu adalah pendekatan terbaik. Menguji perairan membantu menyesuaikan diri tidak hanya dengan tim teknologi Anda ke cloud tetapi juga seluruh budaya bisnis Anda secara keseluruhan.
Namun, ada beberapa situasi di mana rencana yang lebih ambisius masuk akal. Misalnya, bisnis mungkin perlu berkomitmen untuk memindahkan beberapa sistem yang saling bergantung sekaligus, karena perubahan vendor, alasan teknis, dll. Ini biasanya berarti menangani kompleksitas yang lebih tinggi dan menerima peningkatan risiko. Untuk situasi ini, kami mengembangkan peta jalan transisi cloud yang mendetail, bertahap, dan berjangka panjang. Bahkan untuk strategi satu per satu yang lebih konservatif, penting untuk membuat peta jalan yang komprehensif untuk memenuhi tata kelola perusahaan atau kebutuhan perencanaan jangka panjang lainnya bahkan sebelum mencelupkan kaki pertama ke dalam air.
Fase Satu: Perencanaan
Langkah 1: Tentukan Tujuan Anda
Istilah “cloud” bisa jadi ambigu. Ini sering berarti sesuatu yang berbeda dari satu orang atau perusahaan ke orang lain. Sangat penting untuk mengidentifikasi dan menentukan tujuan perusahaan Anda sebelum menyelami migrasi cloud Anda.
Kami merekomendasikan untuk bertanya pada diri sendiri apa yang sebenarnya dibutuhkan bisnis Anda dari lingkungan cloud – apakah itu lift-and-shift terfokus dari aplikasi saat ini atau strategi transformasi digital yang lebih luas? Jika Anda ingin membangun sesuatu yang baru, apakah itu sistem internal untuk karyawan Anda, portal untuk mitra b2b Anda, aplikasi yang berhubungan dengan pelanggan, atau kombinasi dari semuanya?
Anda pasti ingin membuat tolok ukur untuk mengukur kesuksesan Anda. Ini bisa menjadi sesuatu yang konkret seperti waktu muat aplikasi yang lebih baik atau peningkatan produktivitas yang terukur, atau bisa juga hal yang tidak berwujud seperti kepuasan karyawan yang lebih tinggi. Tentukan indikator kinerja utama ini terlebih dahulu untuk membantu memfokuskan rencana Anda, dan agar Anda dapat mengetahui kapan harus menganggap migrasi Anda berhasil.
Langkah 2: Dokumentasikan Rencana Tindakan Awal
Ada banyak cara untuk berpindah ke cloud saat Anda mempertimbangkan semua opsi, jadi jangan bekerja dari template. Buat rencana transisi yang sesuai untuk bisnis Anda dengan kebutuhan dan sasaran spesifiknya. Kami merekomendasikan untuk mencakup sebanyak mungkin detail selama proses perencanaan. Fase ini mungkin membuat beberapa pemangku kepentingan merasa tidak sabar untuk memulai atau beberapa lainnya khawatir menghabiskan terlalu banyak sumber daya untuk perencanaan. Namun, semakin baik rencana Anda, semakin tinggi peluang Anda untuk mendapatkan hasil yang sukses.
Anda mungkin pernah mendengar pepatah terkenal Dwight D. Eisenhower, “Rencana itu tidak berharga, tetapi perencanaan adalah segalanya”, berkali-kali sebelumnya. Maksudnya adalah bahwa setiap proyek yang cukup rumit secara virtual pasti akan menghadapi keadaan tak terduga yang memaksa Anda menyimpang dari rencana. Rencana harus menjadi dokumen hidup yang berusaha untuk mengantisipasi semaksimal mungkin dan menyesuaikan dengan cepat dan efisien ketika keadaan menyimpang dari rencana. Manajer proyek yang efektif sangat penting untuk mengelola rencana sejak awal, dari evolusi hingga penyelesaian.
Buat Strategi Gerakan Awal Anda
Taktik yang dapat diandalkan adalah melakukan fase migrasi yang dimulai dengan satu aplikasi warisan kritis (atau tidak kritis), terkadang disebut “angkat-dan-geser”. Alternatif serupa adalah mengganti / membangun kembali aplikasi lama yang sudah ada. Mengambil rute ini memungkinkan Anda membayar hutang teknis pada sistem yang penting untuk inti bisnis Anda. Anda kemudian dapat memigrasi pengguna dan data Anda ke aplikasi pengganti. Strategi ketiga adalah memprioritaskan pengembangan aplikasi baru yang direncanakan yang belum ada. Pertimbangan termasuk seberapa berisiko dan seberapa besar Anda harus pergi ke sini? Buat garis besar bukan hanya migrasi aplikasi pertama Anda tetapi juga urutan prioritas dari segala sesuatu dalam ekosistem teknologi Anda, bahkan jika hal ini membuat Anda membutuhkan waktu bertahun-tahun dari transisi penuh ke cloud. Ini membantu Anda dan pemangku kepentingan Anda mempertimbangkan gambaran besar dalam satu peta jalan yang lengkap.
Penting! Meskipun terlalu dini untuk mendalami detail teknis, Anda perlu mempertimbangkan pertimbangan teknis bersama dengan pertimbangan bisnis selama fase evaluasi strategi dan risiko. Libatkan ahli teknologi bersama pemangku kepentingan dalam perencanaan sejak awal untuk mengurangi risiko dikejutkan oleh komplikasi teknis yang tersembunyi. Seringkali kedua perwakilan ini secara harfiah berbicara dalam bahasa yang berbeda, dan di situlah analis bisnis yang berpengalaman menjadi sangat penting untuk menyatukan berbagai masalah ke dalam rencana yang kohesif.
Evaluasi Risiko
Pertimbangkan tingkat kenyamanan Anda dengan risiko. Kami telah bekerja dengan perusahaan “menjadi besar, atau pulang” yang memindahkan sistem kritis atau ambisius ke cloud terlebih dahulu. Kami juga telah bekerja dengan organisasi yang memindahkan aplikasi yang lebih kecil dan berdampak minimal terlebih dahulu, membuat kaki mereka basah sebelum mengambil risiko. Pertimbangkan sumber daya yang Anda miliki dan apa yang perlu Anda tambahkan, baik selama transisi maupun untuk perawatan dan pemeliharaan yang berkelanjutan. Beberapa aplikasi akan membutuhkan lebih banyak pekerjaan daripada yang lain. Ada manfaat untuk setiap strategi, dan itu tergantung pada apa yang terbaik untuk bisnis Anda.
Pilih dengan hati-hati dan pertimbangkan kejutan transformasi budaya. Dampak dari langkah pertama ini seperti kesan pertama. Jika berjalan dengan buruk atau tidak diluncurkan dengan baik kepada pengguna, organisasi Anda mungkin menolak gelombang migrasi cloud selanjutnya. Jika berjalan dengan baik, mereka lebih cenderung menyambut migrasi di masa depan.
Detail Teknis
Setelah Anda menentukan urutan operasi, sekarang saatnya menentukan sumber daya dan persyaratan teknis yang lebih mendetail untuk transisi Anda.
Anda akan menginginkan setidaknya satu sumber daya arsitek di tim yang telah menunjukkan pengalaman sebelumnya dalam bekerja dengan penyedia cloud yang Anda pilih. Tidak semua orang di tim harus ahli dalam cloud tertentu yang Anda pilih (mis., AWS, Azure, dll.). Namun, jika Anda berasumsi bahwa tim ahli Anda dapat mempelajari seluk beluk pengaturan dan administrasi cloud, Anda mungkin benar. Pastikan untuk memperhitungkan banyak waktu baik di kalender maupun minggu kerja sumber daya untuk mengatasi gundukan awal.
Jika kalender sangat penting, Anda sebaiknya menyertakan arsitek bersertifikat dengan pengalaman langsung di tim. Di sisi lain, jika Anda ingin ahli internal Anda mempelajari seluk-beluknya, dan kalender tidak terlalu penting, luangkan waktu untuk mengirim orang ke pelatihan. Kemudian beri mereka waktu dan kesempatan untuk belajar sambil bekerja dalam situasi berisiko rendah.
Anda perlu mengidentifikasi dependensi di antara aplikasi yang berbeda, dan bagaimana hubungannya akan berubah jika satu aplikasi berada dalam lingkungan cloud Anda dan yang lainnya tidak.
Jangan lupa tentang mendokumentasikan rencana untuk keamanan data dan privasi ke depannya. Anda perlu menjelaskan strategi perlindungan data, terutama saat data masuk dan keluar dari cloud.
Pertimbangkan peraturan industri yang relevan. Bisnis Anda mungkin tidak perlu mengkhawatirkan hal ini, tetapi kami telah bekerja dengan organisasi yang harus mengikuti peraturan seperti HIPPA, GDPR, dll. Uraikan cara menangani peraturan saat Anda dalam tahap perencanaan untuk memastikan bahwa Anda menyertakan spesialis yang tepat keahlian dalam tim proyek.
Langkah 3: Mulai Membuat Perubahan Sumber Daya
Transisi ke cloud adalah pekerjaan besar. Perlu waktu bertahun-tahun untuk beralih sepenuhnya ke cloud. Dan itu menciptakan beban baru, terkadang permanen, pada sumber daya. Banyak bisnis memilih untuk bekerja dengan tim konsultan, arsitek solusi cloud, dan pengembang perangkat lunak (seperti Soliant) untuk mengurangi tekanan. Namun, tim Anda pada akhirnya perlu mempelajari cara memperbarui dan mengelola aplikasi Anda di lingkungan cloud, meskipun mereka tidak akan mengambil alih administrasi langsung. Mereka harus terlibat aktif dalam proses perencanaan dan implementasi. Bagaimana mereka akan menyulap pengembangan dan kebutuhan sistem lainnya selama ini? Tanggung jawab apa yang menjadi prioritas tertinggi? Bangun rencana sumber daya yang realistis, karena Anda hanya dapat meregangkan orang-orang dalam waktu singkat sebelum Anda mengambil risiko kehilangan mereka atau melihat kualitas menurun.
Menambahkan Anggota Tim
Kadang-kadang ini berarti mempekerjakan satu atau dua anggota tim baru atau mendedikasikan waktu anggota tim veteran hampir secara eksklusif untuk menjalankan tugas ini. Kami merekomendasikan mengisi peran baru sebelum ketegangan pada sumber daya menjadi menyakitkan. Kami tahu betapa sulitnya menemukan pakar teknologi berbakat. Mulailah mencari anggota tim yang sempurna selama fase perencanaan untuk membantu membawa Anda melalui transisi ini. Jika Anda memerlukan bantuan, tim kami di Soliant Consulting dapat membantu menyaring kandidat untuk tim pengembangan klien internal.
Mempersiapkan DevOps
Jika Anda tidak memiliki strategi atau tim DevOps, migrasi Anda ke cloud adalah waktu yang tepat untuk membuatnya. Kemudian Anda harus mempersiapkan mereka untuk langkah ini, baik melalui pelatihan tambahan, sertifikasi khusus cloud, atau sumber daya. Keuntungan dari strategi DevOps yang terencana dengan baik adalah peningkatan kecepatan ke pasar dan kualitas produk perangkat lunak Anda.
Langkah 4: Bangun Timeline Anda
Semua rencana yang dilaksanakan dengan baik menyertakan kalender terperinci. Jaga agar tim Anda tetap pada jalurnya dan bertanggung jawab dengan membangun garis waktu untuk transisi Anda. Dapatkan detail sebanyak mungkin dan pastikan memiliki mekanisme untuk mengukur kecepatan dan kemajuan sehingga Anda dapat terus memperbarui garis waktu berdasarkan kemajuan terukur aktual.
Ya, proyek yang kompleks biasanya menyimpang dari rencana awal. Anda akan mengalami masalah yang tidak terpikirkan oleh siapa pun – risiko itu melekat dalam setiap proyek pengembangan yang kompleks. Namun, jadwal yang terkelola dengan baik dan akurat dapat memotivasi tim Anda untuk terus bergerak maju dan menebus waktu yang hilang. Lebih penting lagi, ini memberi bisnis secara keseluruhan sebagai referensi. Ini memberi pemangku kepentingan informasi berharga untuk merencanakan aktivitas yang berdekatan, seperti penjualan, pemasaran, meja bantuan, dll.
Seperti semua migrasi, strategi migrasi cloud Anda hadir dengan variabel pilih-petualangan-Anda-sendiri. Kami telah bekerja dengan bisnis yang bekerja sangat lambat untuk mengurangi risiko serta dengan mereka yang ingin bekerja lebih cepat untuk memenuhi tujuan bisnis yang lebih ambisius. Sebaiknya hindari proses yang terburu-buru. Namun, semakin lambat Anda pergi, semakin banyak Anda akan berinvestasi dalam komunikasi dalam jangka waktu yang lebih lama dan pemeliharaan dua infrastruktur hingga transisi selesai.
Tahap Kedua: Pengembangan
Langkah 1: Penyiapan Infrastruktur Cloud
Infrastruktur Anda menentukan nada untuk seluruh migrasi Anda, jadi setiap keputusan yang Anda buat selama langkah ini sangat penting. Anda tidak bisa hanya mempertimbangkan kebutuhan bisnis Anda sekarang. Anda juga harus merencanakan masa depan perusahaan Anda dan bagaimana perusahaan itu akan berkembang dalam cloud.
Penyimpanan Data, Latensi, dan Penyediaan
Pindah ke cloud sering kali membutuhkan pergeseran asumsi. Misalnya, strategi pencadangan bisa lebih sederhana dan lebih hemat biaya karena infrastruktur cloud tidak memerlukan pengelolaan media fisik seperti hard drive dan pita cadangan.
Di sisi lain, beberapa aplikasi lokal mungkin harus dioptimalkan ulang karena pengguna di fasilitas fisik yang terhubung sekarang dapat terhubung ke aplikasi melalui internet alih-alih LAN.
Pembelian dan penyediaan sumber daya akan mengikuti model yang berbeda saat Anda berpindah dari perangkat keras ke cloud. Perangkat keras umumnya dianggarkan dengan amortisasi tiga hingga lima tahun. Infrastruktur cloud membuka opsi penyediaan baru yang dimulai dengan resource sesuai permintaan dengan biaya premium per menit. Ini dapat mencakup penghematan biaya jika Anda dapat memprediksi instans cadangan dalam jangka waktu satu hingga tiga tahun.
Detail Konfigurasi
Detail konfigurasi bisa menjadi serupa dengan kode aplikasi. Di sinilah strategi DevOps yang efektif berperan. Lingkungan yang direncanakan dengan benar dapat disediakan dengan cara yang sangat otomatis di cloud menggunakan alat seperti AWS Cloud Formation. Hal ini membuat penyediaan dan konfigurasinya sangat dapat diulang dan skalabel, sehingga memberikan waktu yang lebih cepat ke pasar dengan kualitas yang lebih tinggi.
Kontrol Atas Lingkungan Cloud Anda
Manajer teknis Anda harus langsung menentukan kebijakan. Anda akan memerlukan kebijakan tentang bagaimana tim dapat meminta dan menyediakan sumber daya baru, serta kebijakan seputar akses dan keamanan untuk lingkungan pementasan dan produksi. Pertimbangkan ini baik dalam bidang bisnis maupun teknis. Anda dapat mengotomatiskan hampir semuanya, tetapi Anda membutuhkan tim tepercaya yang menyatukannya sehingga mereka saling mendukung dan memperkuat.
Langkah 2: Pengembangan Aplikasi Primer
Sekarang setelah rencana lingkungan Anda siap, Anda dapat mulai menerapkannya. Bergantung pada keputusan dan prioritas Anda, ini bisa cepat, dengan lift dan shift, atau bisa juga bangunan baru yang besar.
Jangan Lupakan Dokumentasi
Pengembangan migrasi cloud melibatkan banyak bagian yang bergerak dan seringkali banyak sumber daya. Karena satu unit bisnis dapat sepenuhnya mengelola satu komponen dari proses pengembangan, dokumentasi sangat penting untuk memberi petunjuk kepada orang lain. Semua persyaratan, keputusan, dan perubahan harus didokumentasikan di lokasi pusat, dapat diakses oleh semua yang perlu mengetahui detail ini. Tim proyek sering kali dapat mendokumentasikan keputusan dan tugas secara efisien di wiki, pelacak masalah, dan repositori kontrol versi. Dokumentasi sangat berguna jika muncul masalah selama QA. Anda dapat menentukan apa yang salah dan memperbarui dokumentasi agar tidak terjadi lagi.
Beberapa proyek mungkin juga memerlukan tingkat dokumentasi pengguna akhir yang lebih formal, biasanya membutuhkan tim khusus untuk menulis dan menguji.
Langkah 3: Pengujian
Kami merekomendasikan tinjauan jaminan kualitas internal yang cermat. QA harus melibatkan lebih dari anggota tim pengembangan Anda yang menguji kode. Analis bisnis Anda akan mencari lebih dari sekadar bug teknis dan biasanya lebih fokus pada cerita pengguna daripada cara kerjanya secara teknis, menjadikannya proxy yang lebih baik untuk pengguna nyata. Bahkan pengembang terbaik pun terkenal buruk dalam menemukan bug dalam kodenya sendiri. Anggota tim QA akan memastikan aplikasi sesuai dengan visi bisnis awal yang diuraikan dalam fase satu. Jika proyek memerlukannya, kumpulkan tim QA khusus, dan pertimbangkan untuk menyertakan teknisi QA yang terpisah dari tim pengembangan untuk menulis pengujian otomatis yang diintegrasikan ke dalam proses penerapan. Ini akan memastikan kualitas dasar yang sangat tinggi saat Anda menambahkan fitur baru.
Apa pun proses QA yang diminta oleh proyek Anda, langkah normal berikutnya untuk aplikasi baru atau yang dimigrasi adalah pengujian penerimaan pengguna. Kami merekomendasikan untuk meluncurkan aplikasi awal ini untuk memberdayakan pengguna dalam bisnis untuk pengujian penerimaan pengguna formal. Hindari godaan untuk melakukan ini secara ad hoc. Manajer proyek dan / atau BA harus merancang rencana uji penerimaan karena bahkan pengguna yang berkuasa dapat cenderung berasumsi bahwa jika sesuatu bekerja dengan satu cara maka itu akan berhasil dengan cara apapun. UAT formal akan membantu memastikan bahwa fitur-fitur penting diperiksa secara menyeluruh. Ini membantu menangkap apa pun yang terlewat selama pengembangan dan memungkinkan Anda mempertimbangkan untuk memasukkan umpan balik pengguna dalam lingkungan UAT yang tidak terlalu berisiko sebelum Anda ditayangkan langsung ke semua pengguna. Tanggapi umpan balik dari para power user ini dengan serius. Jika mereka memiliki kekhawatiran, Anda juga harus melakukannya.
Langkah 4: Penerapan
Setelah pengujian penerimaan pengguna selesai, Anda perlu menerapkan aplikasi yang baru Anda selesaikan dengan data saat ini. Bergantung pada keadaan, ini mungkin memerlukan waktu henti sementara data produksi diubah dan dimuat. Atau, mungkin sesederhana mengubah beberapa pengaturan.
Apa pun tingkat kerumitannya, Anda harus mempersiapkan tim Anda untuk periode perawatan tinggi setelah meluncurkan aplikasi baru. Anda harus secara aktif memantau aplikasi untuk masalah dan respons cepat terhadap masalah pengguna. Seringkali pengguna bingung hanya karena sesuatu yang baru, dan mereka mungkin perlu menjawab pertanyaan sederhana. Seseorang perlu ditugaskan dan siap untuk melakukan triase permintaan dukungan untuk memisahkan jenis pertanyaan sederhana ini dari bug yang sebenarnya. Orang atau tim hyper-care point juga akan bekerja untuk mereproduksi bug dan mengkarakterisasi detail seperti versi, lingkungan, status data, dll. Dan menuliskannya sehingga pengembang yang ditugaskan untuk memperbaikinya dapat fokus pada perbaikan alih-alih menelusuri cara mereproduksi masalah.
Harus ada tim dan rencana untuk memprioritaskan dan menambal bug. Tim ini harus mencakup pemangku kepentingan, analis, penguji, dan pengembang. Tim harus mencoba menangguhkan bug untuk siklus rilis pengembangan normal jika memungkinkan. Namun, mereka mungkin harus menyoroti beberapa bug sebagai prioritas tinggi untuk diperbaiki dan mendorongnya ke produksi dengan cepat.
Komunikasi Dua Arah adalah Kuncinya
Komunikasi yang buruk dapat menggagalkan penerapan terbaik sekalipun. Mulailah dengan langkah yang benar dengan mempersiapkan semua pengguna sebelum penerapan. Beri tahu mereka apa yang diharapkan dan bagikan panduan pengguna untuk membantu mereka memahami perubahan dalam sistem. Manajer proyek harus berkomunikasi langsung dengan pengguna atau memverifikasi bahwa orang yang didelegasikan komunikasi telah mengirim pesan yang disetujui ke grup yang tepat pada waktu yang tepat.
Anda juga harus membuat loop umpan balik yang diformalkan untuk memahami reaksi mereka terhadap aplikasi di lingkungan cloud.
Ingat, pengguna akan menolak sistem baru jika mereka merasa bingung, tidak terdengar, atau tertangkap basah. Buat mereka mendukung Anda di awal permainan dengan membantu mereka merasa nyaman dan siap. Bersiaplah untuk bereaksi dan menggabungkan umpan balik dengan cara yang efisien dan transparan.
Langkah 5: Bilas dan Ulangi
Sekarang saatnya mengikuti rencana migrasi cloud lengkap Anda dengan melalui fase ini lagi dengan aplikasi Anda yang tersisa. Tentu saja, jika Anda mengikuti strategi yang lebih rumit untuk memindahkan sistem dependen secara bersamaan, ini akan terlihat berbeda. Namun, inti setiap aplikasi sama. Perencanaan> Pengembangan> Pengujian> Penerapan> Dukungan.
Fase Tiga: Pemeliharaan
Infrastruktur dan aplikasi Anda di cloud membutuhkan pengawasan. Sebagian besar dapat diotomatiskan, tetapi tim Anda masih perlu meninjau peluang untuk peningkatan. Misalnya, haruskah Anda memperbesar atau memperkecil skala bulan ini? Penyedia cloud utama meluncurkan fitur-fitur baru dengan kecepatan yang membingungkan. Seseorang perlu mengawasi rilis ini untuk menentukan apakah Anda perlu mengintegrasikannya ke lingkungan Anda.
Cadangan
Sementara kami menyinggung secara singkat hal ini di atas, kami ingin menegaskan kembali bahwa perencanaan untuk keadaan darurat adalah yang terpenting dalam teknologi. Pertimbangkan detail terkait cara Anda menjalankan cadangan dan seberapa cepat Anda dapat memulihkannya. Tentukan apakah Anda memiliki rencana pemulihan bencana lengkap. Identifikasi anggota tim yang memiliki kekuatan untuk memulihkan sistem dan / atau versi data. Dalam banyak hal, pencadangan dan pemulihan jauh lebih cepat dan lebih sederhana di cloud. Namun, mereka memerlukan tingkat perencanaan dan pengujian yang sama seperti rencana pemulihan bencana warisan. Kabar baiknya adalah, cloud dapat mempermudah menjalankan latihan pemulihan / ketahanan bencana melalui otomatisasi. Organisasi Anda harus mempertimbangkan perencanaan terperinci dan apa yang disebut latihan “GameDay” jika ketahanan dan / atau pemulihan cepat sangat penting untuk bisnis Anda.
Keamanan
Banyak orang khawatir tentang pemindahan data penting bisnis ke cloud. Namun, ini bisa lebih aman daripada infrastruktur milik sendiri. Karena sifatnya, infrastruktur cloud lebih mudah diperbarui daripada infrastruktur fisik. DevOps harus secara aktif memantau dan mengelola infrastruktur, dan manajemen TI memiliki peran pengawasan dan tata kelola yang penting untuk dimainkan. Pengembang harus diberdayakan untuk mencari cara untuk menambal lubang dan mengurangi ancaman dengan izin terbatas khusus di lingkungan produksi. Juga, pertimbangkan isolasi jaringan dan langkah-langkah ketahanan. Pantau integrasi dan API untuk memastikan tidak ada kelemahan yang muncul. Ikuti langkah-langkah enkripsi data dan tinjau terus otentikasi pengguna dan tingkat izin. Infrastruktur cloud tidak secara inheren lebih atau kurang aman daripada sistem yang terhubung ke Internet. Bisa dibilang, infrastruktur cloud yang dirancang dengan baik bisa lebih aman daripada infrastruktur lokal yang terhubung ke Internet.
Memulai Migrasi Cloud Anda
Kami berharap panduan ini bermanfaat bagi Anda saat merencanakan migrasi ke cloud. Jika Anda memiliki pertanyaan atau ingin mempelajari lebih lanjut tentang pekerjaan konsultasi dan pengembangan kami di cloud, hubungi tim kami hari ini.