{"id":4536,"date":"2026-09-09T12:00:55","date_gmt":"2026-09-09T05:00:55","guid":{"rendered":"https:\/\/www.aquaorange.id\/?p=4536"},"modified":"2026-09-07T12:40:34","modified_gmt":"2026-09-07T05:40:34","slug":"blueprint-migrasi-email-perusahaan-ke-gmail","status":"publish","type":"post","link":"https:\/\/www.aquaorange.id\/en\/blueprint-migrasi-email-perusahaan-ke-gmail\/","title":{"rendered":"Blueprint Migrasi Email Perusahaan ke Gmail Tanpa Mengganggu Operasional"},"content":{"rendered":"

Email masih menjadi salah satu komponen penting dalam operasional perusahaan. Komunikasi dengan pelanggan, pengiriman dokumen, notifikasi sistem, hingga koordinasi internal masih banyak bergantung pada email perusahaan. Karena itu, ketika organisasi ingin memindahkan sistem email lama seperti cPanel, Microsoft Exchange, atau server email <\/span>on-premises<\/span><\/i> ke Gmail di Google Workspace, kekhawatiran terbesar biasanya bukan hanya soal pemindahan data, tetapi juga bagaimana memastikan bisnis tetap berjalan selama proses tersebut.<\/span><\/p>\n

Migrasi email tidak harus dilakukan dengan mematikan server lama lalu menyalakan sistem baru pada hari yang sama. Pendekatan seperti ini justru dapat meningkatkan risiko gangguan karena perubahan routing, konfigurasi DNS, dan pemindahan data belum tentu selesai secara bersamaan.<\/span><\/p>\n

Strategi yang lebih aman adalah menyiapkan lingkungan Google Workspace terlebih dahulu, memindahkan data secara bertahap, menguji konfigurasi dengan sebagian pengguna, kemudian melakukan perubahan alur email ketika lingkungan baru sudah siap. Dalam skenario tertentu, <\/span>Dual Delivery<\/b> juga dapat digunakan agar pesan masuk dikirimkan ke Gmail sekaligus sistem email lama selama periode transisi.<\/span><\/p>\n

Dengan pendekatan tersebut, migrasi dapat dirancang untuk <\/span>meminimalkan gangguan operasional<\/b> dan mengurangi risiko email tidak dapat dikirim atau diterima selama perpindahan. Namun, keberhasilan migrasi tetap bergantung pada kondisi sistem sumber, konfigurasi routing, DNS, volume data, serta pengujian sebelum proses <\/span>cutover<\/span><\/i>.<\/span><\/p>\n

Bersama <\/span>AquaOrange Indonesia<\/b>, perusahaan dapat memetakan infrastruktur email lama, menentukan strategi migrasi yang sesuai, serta menyiapkan proses transisi yang lebih terstruktur agar perpindahan ke Gmail dapat dilakukan dengan risiko operasional yang lebih terukur.<\/span><\/p>\n

 <\/p>\n

Memahami Prinsip Transisi Email Tanpa Downtime<\/b><\/h3>\n

Prinsip utama migrasi email yang minim gangguan adalah memisahkan proses <\/span>pemindahan data<\/b> dari proses <\/span>perubahan alur email<\/b>. Data lama dapat dimigrasikan ketika server sumber masih aktif, sementara konfigurasi routing dipersiapkan secara bertahap.<\/span><\/p>\n

Salah satu mekanisme yang dapat digunakan adalah <\/span>Dual Delivery<\/b>. Dalam konfigurasi ini, pesan yang masuk dapat dikirimkan ke kotak masuk Gmail sekaligus sistem email lama. Pendekatan tersebut memberikan waktu bagi tim IT untuk menguji lingkungan baru sebelum Gmail digunakan sebagai sistem email utama.<\/span><\/p>\n

Pendekatan berikutnya adalah <\/span>migrasi data secara bertahap<\/b>. Data historis tidak harus menunggu hari <\/span>cutover<\/span><\/i> untuk dipindahkan. Bergantung pada sumber datanya, organisasi dapat menggunakan layanan atau alat migrasi Google yang sesuai untuk memindahkan email, kalender, dan kontak.<\/span><\/p>\n

Di sisi DNS, administrator perlu mempersiapkan perubahan MX, SPF, DKIM, dan DMARC dengan hati-hati. MX menentukan tujuan pengiriman email masuk, sedangkan SPF, DKIM, dan DMARC berperan dalam autentikasi dan perlindungan domain email.<\/span><\/p>\n

Karena perubahan DNS membutuhkan waktu untuk dikenali secara luas, proses <\/span>cutover<\/span><\/i> sebaiknya tidak dilakukan secara terburu-buru. Tim IT perlu memastikan bahwa akun pengguna, routing, autentikasi, dan aplikasi yang bergantung pada email sudah diuji sebelum perubahan MX dilakukan.<\/span><\/p>\n

Untuk menerapkan prinsip tersebut, sebuah <\/span>blueprint migrasi<\/b> perlu mencakup pemetaan akun email, alias, grup distribusi, aplikasi yang menggunakan email, strategi pemindahan data, serta prosedur pemulihan jika terjadi kendala selama proses transisi.<\/span><\/p>\n

 <\/p>\n

Hambatan Migrasi Email Tradisional dan Solusi Gmail Google Workspace<\/b><\/h3>\n

Migrasi dari sistem email lama dapat menimbulkan beberapa tantangan jika dilakukan tanpa perencanaan yang cukup. Salah satunya adalah risiko gangguan pengiriman ketika MX record diubah sebelum akun dan routing di lingkungan baru benar-benar siap.<\/span><\/p>\n

Masalah lainnya adalah perbedaan struktur data antara sistem sumber dan Gmail. Folder pada sistem lama, misalnya, dapat dipetakan menjadi label di Gmail. Jenis data tertentu juga dapat memiliki batasan atau aturan migrasi masing-masing. Karena itu, organisasi sebaiknya melakukan inventarisasi terlebih dahulu untuk mengetahui data apa saja yang perlu dipindahkan dan bagaimana hasilnya akan muncul di lingkungan Google Workspace.<\/span><\/p>\n

Perubahan platform juga berdampak pada pengguna. Karyawan mungkin perlu mengonfigurasi ulang aplikasi email, perangkat mobile, atau aplikasi desktop yang sebelumnya terhubung ke server lama. Untuk itu, komunikasi internal dan panduan penggunaan sebaiknya menjadi bagian dari rencana migrasi, bukan baru disiapkan setelah <\/span>cutover<\/span><\/i>.<\/span><\/p>\n

Google Workspace menyediakan beberapa metode migrasi, tetapi alat yang digunakan perlu disesuaikan dengan sistem sumber. <\/span>Data Migration Service<\/b>, Google Workspace Migration for Microsoft Outlook (GWMMO), dan Google Workspace Migrate memiliki fungsi serta cakupan yang berbeda. Pemilihan metode sebaiknya mempertimbangkan platform sumber, jenis data, jumlah pengguna, dan kebutuhan organisasi.<\/span><\/p>\n

Dengan blueprint yang disusun berdasarkan kondisi infrastruktur aktual, perusahaan dapat mengurangi risiko yang biasanya muncul saat berpindah dari sistem email tradisional ke Google Workspace.<\/span><\/p>\n

 <\/p>\n

Komponen Utama Blueprint Migrasi Email Perusahaan<\/b><\/h3>\n

Blueprint migrasi email perusahaan perlu mencakup beberapa komponen utama yang saling berkaitan. Pertama adalah <\/span>alat migrasi Google Workspace<\/b>, yang digunakan untuk memindahkan data dari sistem email lama sesuai dengan platform sumber dan jenis data yang didukung. Metode yang digunakan dapat berbeda tergantung apakah perusahaan sebelumnya menggunakan Microsoft Exchange, IMAP, Outlook, atau sistem lainnya.<\/span><\/p>\n

Komponen berikutnya adalah <\/span>Dual Delivery<\/b>, terutama jika perusahaan membutuhkan periode transisi ketika Gmail dan sistem email lama masih berjalan secara bersamaan. Konfigurasi ini dapat memberikan waktu bagi tim IT untuk menguji pengiriman dan penerimaan email sebelum Gmail menjadi sistem utama.<\/span><\/p>\n

Seluruh proses tersebut dikelola melalui <\/span>Google Workspace Admin Console<\/b>, yang menjadi pusat pengaturan pengguna, grup, domain, Gmail, keamanan, dan berbagai konfigurasi organisasi. Struktur akun sebaiknya sudah disiapkan sebelum proses migrasi dimulai agar pengguna dapat langsung menggunakan lingkungan baru ketika proses <\/span>cutover<\/span><\/i> dilakukan.<\/span><\/p>\n

Dari sisi pengiriman email, <\/span>MX, SPF, DKIM, dan DMARC<\/b> juga perlu diperhitungkan dalam blueprint. MX menentukan ke mana email masuk diarahkan, sedangkan SPF, DKIM, dan DMARC membantu memvalidasi email yang dikirim menggunakan domain perusahaan serta mendukung perlindungan terhadap penyalahgunaan domain.<\/span><\/p>\n

Terakhir, migrasi sebaiknya dilakukan melalui <\/span>pilot dan batch migration<\/b>. Tim IT dapat memulai dengan sejumlah akun pengujian, kemudian melanjutkan ke kelompok pengguna tertentu sebelum melakukan migrasi secara lebih luas. Pendekatan ini membantu mengidentifikasi masalah konfigurasi lebih awal dan memberikan kesempatan untuk memperbaikinya sebelum berdampak pada seluruh organisasi.<\/span><\/p>\n

 <\/p>\n

Panduan Langkah Merancang Blueprint Migrasi Email<\/b><\/h3>\n

Untuk mengurangi risiko selama migrasi, proses dapat dibagi menjadi lima fase.<\/span><\/p>\n

    \n
  1. Fase 1: Inventarisasi dan Pemetaan Akun (<\/b>Audit & Planning<\/i><\/b>)<\/b><\/li>\n<\/ol>\n

    Mulailah dengan mendata seluruh mailbox, alias, grup, akun bersama, ukuran mailbox, serta jenis data yang perlu dipindahkan. Identifikasi juga sistem yang saat ini terhubung dengan email perusahaan, seperti aplikasi bisnis, CRM, printer, perangkat scanner, atau layanan yang menggunakan SMTP.<\/span><\/p>\n

    Tahap ini penting karena migrasi email bukan hanya perpindahan mailbox. Sistem lain yang mengirim email menggunakan domain perusahaan juga harus diperhitungkan agar tidak berhenti bekerja setelah perubahan routing.<\/span><\/p>\n

     <\/p>\n

      \n
    1. Fase 2: Penyiapan Lingkungan Google Workspace (<\/b>Environment Setup<\/i><\/b>)<\/b><\/li>\n<\/ol>\n

      Setelah struktur akun dipetakan, siapkan lingkungan Google Workspace. Verifikasi kepemilikan domain, buat pengguna dan grup yang diperlukan, kemudian konfigurasi Gmail serta kebijakan keamanan yang relevan.<\/span><\/p>\n

      Pada tahap ini, jangan langsung mengubah MX record hanya karena akun Google Workspace sudah tersedia. Lingkungan baru sebaiknya diuji terlebih dahulu agar perubahan routing tidak dilakukan sebelum sistem siap.<\/span><\/p>\n

       <\/p>\n

        \n
      1. Fase 3: Konfigurasi Pengiriman Ganda (<\/b>Dual Delivery Setup<\/i><\/b>)<\/b><\/li>\n<\/ol>\n

        Jika skenario migrasi membutuhkan pengiriman ke dua sistem sekaligus, administrator dapat menggunakan Dual Delivery. Konfigurasi ini dapat membantu mengarahkan pesan ke Gmail dan sistem email lama selama periode transisi.<\/span><\/p>\n

        Konfigurasi perlu diuji dengan beberapa akun terlebih dahulu. Pastikan email eksternal, email internal, balasan, lampiran, serta pesan dari aplikasi bisnis dapat diterima sesuai alur yang direncanakan.<\/span><\/p>\n

         <\/p>\n

          \n
        1. Fase 4: Pemindahan Data Historis (<\/b>Background Data Migration<\/i><\/b>)<\/b><\/li>\n<\/ol>\n

          Setelah lingkungan siap, lakukan migrasi data secara bertahap. Metode yang digunakan bergantung pada sistem sumber. Untuk data dari Microsoft Outlook atau Exchange, misalnya, Google menyediakan GWMMO untuk skenario migrasi yang didukung.<\/span><\/p>\n

          Jangan menganggap bahwa seluruh struktur mailbox akan berpindah secara identik. Beberapa data dapat memiliki pemetaan atau batasan tertentu. Karena itu, lakukan validasi terhadap hasil migrasi sebelum melanjutkan ke batch berikutnya.<\/span><\/p>\n

          Pemeriksaan dapat mencakup jumlah pesan, lampiran, struktur label, tanggal email, serta data kalender atau kontak jika termasuk dalam ruang lingkup migrasi.<\/span><\/p>\n

           <\/p>\n

            \n
          1. Fase 5: Pengalihan DNS Utama dan Penyelesaian (<\/b>Cutover & Delta Sync<\/i><\/b>)<\/b><\/li>\n<\/ol>\n

            Setelah data dan routing diuji, organisasi dapat melakukan <\/span>cutover<\/span><\/i> dengan mengarahkan MX domain ke Google Workspace.<\/span><\/p>\n

            Setelah <\/span>cutover<\/span><\/i>, lakukan pemeriksaan terhadap email masuk dan keluar, autentikasi domain, aplikasi yang mengirim email, serta akun pengguna. Migrasi susulan dapat dilakukan untuk menangani data yang masuk setelah proses migrasi awal, sesuai metode migrasi yang digunakan.<\/span><\/p>\n

            Server lama sebaiknya tidak langsung dimatikan. Pertahankan sistem lama sesuai kebutuhan dan rencana retensi sampai tim memastikan bahwa proses transisi telah selesai dan tidak ada dependensi yang tertinggal.<\/span><\/p>\n

             <\/p>\n

            Ringkasan Konfigurasi Catatan MX DNS Google Workspace<\/b><\/h3>\n

            Pada konfigurasi Google Workspace saat ini, Google mendokumentasikan <\/span>smtp.google.com<\/span> sebagai nilai MX utama dengan prioritas 1 untuk konfigurasi MX baru.<\/span><\/p>\n

            Namun, perubahan MX tidak langsung berarti seluruh internet akan menggunakan konfigurasi baru pada saat yang sama. Propagasi DNS dapat membutuhkan waktu, sehingga administrator perlu mempertimbangkan hal tersebut ketika menentukan jadwal <\/span>cutover<\/span><\/i>.<\/span><\/p>\n

            Selain MX, administrator juga perlu memeriksa konfigurasi SPF, DKIM, dan DMARC. Ketiga mekanisme tersebut memiliki fungsi berbeda dan sebaiknya disiapkan sebagai bagian dari konfigurasi autentikasi domain, bukan sekadar ditambahkan pada hari <\/span>cutover<\/span><\/i>.<\/span><\/p>\n

             <\/p>\n

            Studi Kasus Skenario Migrasi di Berbagai Sektor Industri<\/b><\/h3>\n

            Penerapan blueprint migrasi dapat disesuaikan dengan ukuran organisasi dan karakteristik operasionalnya.<\/span><\/p>\n

            Skenario A: Industri Manufaktur dengan Ribuan Karyawan<\/b><\/p>\n

            Perusahaan manufaktur dengan 1.500 karyawan yang masih menggunakan server email berbasis cPanel dapat membagi migrasi menjadi beberapa batch. Tim IT dapat menguji proses pada akun tertentu terlebih dahulu, kemudian melanjutkan ke departemen dengan jumlah pengguna lebih besar.<\/span><\/p>\n

            Dengan pendekatan tersebut, masalah seperti konfigurasi perangkat, alias yang belum dibuat, atau aplikasi internal yang masih menggunakan server lama dapat ditemukan sebelum migrasi diperluas ke seluruh karyawan.<\/span><\/p>\n

             <\/p>\n

            Skenario B: Perusahaan Jasa Keuangan dan Konsultan<\/b><\/p>\n

            Untuk perusahaan yang memiliki arsip komunikasi klien dalam jumlah besar, fokus utama bukan hanya memindahkan mailbox, tetapi juga memastikan data yang dibutuhkan benar-benar masuk ke akun tujuan.<\/span><\/p>\n

            Tim migrasi perlu menentukan periode data yang akan dipindahkan, memeriksa struktur folder dan label, serta melakukan sampling terhadap pesan dan lampiran setelah migrasi. Untuk organisasi dengan kebutuhan kepatuhan tertentu, kebijakan retensi dan eDiscovery juga perlu dirancang sebagai bagian dari tata kelola Google Workspace, bukan dianggap sebagai bagian otomatis dari proses migrasi.<\/span><\/p>\n

             <\/p>\n

            Skenario C: Perusahaan Ritel dan Distribusi Multi-Cabang<\/b><\/p>\n

            Pada organisasi dengan banyak cabang, migrasi dapat dilakukan secara bertahap berdasarkan lokasi atau kelompok pengguna. Setelah satu kelompok berhasil dipindahkan, tim IT dapat menggunakan hasil pengujian tersebut sebagai acuan untuk batch berikutnya.<\/span><\/p>\n

            Pengguna di lapangan juga perlu mendapatkan panduan mengenai login, aplikasi Gmail, sinkronisasi perangkat, serta perubahan alur kerja yang mungkin terjadi setelah migrasi.<\/span><\/p>\n

            Hasil keberhasilan migrasi<\/b> sebaiknya diukur berdasarkan indikator yang dapat diverifikasi, seperti jumlah mailbox yang berhasil dimigrasikan, jumlah pesan yang gagal dipindahkan, keberhasilan pengiriman dan penerimaan email, jumlah tiket dukungan, serta masalah yang ditemukan setelah <\/span>cutover<\/span><\/i>.<\/span><\/p>\n

            Dengan menggunakan indikator tersebut, perusahaan dapat mengevaluasi hasil migrasi berdasarkan kondisi aktual, bukan sekadar menggunakan target seperti \u201cdowntime 0%\u201d atau persentase pengurangan tiket yang belum didukung data.<\/span><\/p>\n

             <\/p>\n

            Memaksimalkan Efisiensi Pasca-Migrasi ke Google Workspace<\/b><\/h3>\n

            Setelah mailbox dipindahkan, manfaat Google Workspace tidak berhenti pada penggantian sistem email. Gmail terintegrasi dengan berbagai layanan Google Workspace yang dapat mendukung aktivitas kerja sehari-hari.<\/span><\/p>\n

            Pencarian Gmail<\/b> memungkinkan pengguna menemukan pesan dan informasi dalam mailbox menggunakan berbagai kriteria pencarian. Untuk organisasi dengan arsip email yang besar, kemampuan pencarian ini dapat membantu mengurangi waktu yang dibutuhkan untuk menemukan kembali korespondensi lama.<\/span><\/p>\n

            Dari sisi keamanan, Gmail memiliki perlindungan terhadap spam, phishing, dan malware. Google menyatakan bahwa Gmail memblokir lebih dari 99,9% spam, phishing, dan malware sebelum mencapai inbox. Meskipun demikian, perlindungan tersebut bukan berarti perusahaan dapat mengabaikan edukasi pengguna dan kebijakan keamanan internal.<\/span><\/p>\n

            Gmail juga terintegrasi dengan <\/span>Google Calendar dan Google Meet<\/b>, sehingga pengguna dapat mengelola komunikasi dan jadwal rapat dari ekosistem yang sama. Sementara itu, file yang dikirim melalui email dapat dibagikan dan dikerjakan menggunakan Google Drive, Docs, Sheets, atau Slides sesuai kebutuhan.<\/span><\/p>\n

            Integrasi ini dapat mengurangi perpindahan konteks antara berbagai aplikasi dalam pekerjaan sehari-hari, terutama bagi organisasi yang sebelumnya menggunakan sistem email dan layanan kolaborasi dari platform yang berbeda.<\/span><\/p>\n

             <\/p>\n

            Keuntungan Bisnis dari Pindah ke Gmail Perusahaan<\/b><\/h3>\n

            Migrasi ke Gmail dapat mengubah model pengelolaan email perusahaan dari infrastruktur server yang harus dikelola sendiri menjadi layanan cloud yang dikelola Google. Hal ini dapat mengurangi kebutuhan perusahaan untuk menangani hardware email server, kapasitas penyimpanan server, serta sebagian pekerjaan pemeliharaan infrastruktur yang sebelumnya dilakukan secara internal.<\/span><\/p>\n

            Namun, penghematan biaya tidak otomatis terjadi hanya karena perusahaan berpindah ke cloud. Organisasi tetap perlu memperhitungkan biaya lisensi Google Workspace, implementasi, migrasi, pengelolaan akun, dukungan pengguna, serta kebutuhan keamanan dan compliance.<\/span><\/p>\n

            Dari sisi ketersediaan, Google Workspace memiliki <\/span>SLA dengan target Monthly Uptime Percentage minimal 99,9%<\/b> untuk layanan yang tercakup dalam perjanjian. SLA tersebut merupakan komitmen layanan dengan ketentuan tertentu, bukan jaminan bahwa organisasi tidak akan pernah mengalami gangguan.<\/span><\/p>\n

            Migrasi juga dapat menyederhanakan pengalaman pengguna karena Gmail merupakan antarmuka yang sudah familiar bagi banyak pengguna. Meski demikian, perusahaan tetap perlu menyediakan onboarding singkat, terutama untuk menjelaskan perubahan pada aplikasi email, struktur label, perangkat mobile, dan kebijakan keamanan.<\/span><\/p>\n

             <\/p>\n

            Kesimpulan<\/b><\/h3>\n

            Migrasi email perusahaan ke Gmail di Google Workspace tidak harus dilakukan dengan pendekatan <\/span>big bang<\/span><\/i> yang berisiko mengganggu operasional. Dengan <\/span>blueprint migrasi<\/b> yang tepat, organisasi dapat menyiapkan lingkungan Google Workspace terlebih dahulu, memigrasikan data secara bertahap, menguji akun melalui pilot, menggunakan Dual Delivery bila sesuai dengan skenario, lalu melakukan <\/span>cutover<\/span><\/i> ketika sistem baru sudah siap.<\/span><\/p>\n

            Kunci keberhasilan migrasi bukan sekadar memindahkan seluruh mailbox dari server lama ke Gmail, tetapi memastikan <\/span>data, routing, DNS, autentikasi, perangkat pengguna, dan aplikasi yang bergantung pada email<\/b> ikut diperhitungkan dalam rencana transisi.<\/span><\/p>\n

            Target yang lebih realistis bukan sekadar menjanjikan \u201czero downtime\u201d, melainkan merancang proses yang <\/span>meminimalkan gangguan dan memiliki rencana pemulihan jika terjadi masalah<\/b>. Dengan pendekatan tersebut, perusahaan dapat berpindah ke Gmail dengan risiko operasional yang lebih terukur dan proses yang lebih mudah dikendalikan.<\/span><\/p>\n

            Ingin merencanakan migrasi email perusahaan ke Google Workspace? <\/span>AquaOrange Indonesia<\/b> dapat membantu memetakan sistem email lama, menentukan pendekatan migrasi yang sesuai, menyiapkan struktur Google Workspace, serta mendampingi proses pengujian dan <\/span>cutover<\/span><\/i> agar transisi berjalan lebih terencana.<\/span><\/p>\n

            Contact Us<\/span><\/a><\/div>","protected":false},"excerpt":{"rendered":"

            Email masih menjadi salah satu komponen penting dalam operasional perusahaan. […]<\/p>\n","protected":false},"author":5,"featured_media":4537,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32],"tags":[],"class_list":["post-4536","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-google-workspace"],"_links":{"self":[{"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/posts\/4536","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/comments?post=4536"}],"version-history":[{"count":1,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/posts\/4536\/revisions"}],"predecessor-version":[{"id":4538,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/posts\/4536\/revisions\/4538"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/media\/4537"}],"wp:attachment":[{"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/media?parent=4536"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/categories?post=4536"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aquaorange.id\/en\/wp-json\/wp\/v2\/tags?post=4536"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}