Vanta, sebuah Agentic Trust Platform, memindahkan lebih dari 128.000 tiket, 512.000 komentar, dan 86.000 lampiran dari Freshservice ke Jira Service Management dengan pemetaan bidang khusus dan pelestarian data historis — menyelesaikan migrasi dalam 21 hari dengan Help Desk Migration.
Tentang Vanta
Vanta adalah Platform Kepercayaan Agentik #1, didirikan pada tahun 2018 untuk membantu bisnis mengotomatiskan kepatuhan, mengelola risiko, dan terus membuktikan kepercayaan. Perusahaan ini didirikan sebagai respons terhadap meningkatnya kebutuhan akan perlindungan data yang lebih kuat dan awalnya berfokus pada otomatisasi proses kepatuhan untuk standar seperti SOC 2, HIPAA, dan ISO 27001.
Saat ini, Vanta menyediakan platform tunggal berbasis AI yang membantu organisasi mengelola keamanan, kepatuhan, dan risiko secara berkelanjutan. Dipercaya oleh lebih dari 15.000 pelanggan, Vanta melayani perusahaan-perusahaan termasuk Atlassian, Duolingo, Icelandair, Ramp, dan Synthesia. Platformnya memungkinkan bisnis untuk membangun, memelihara, dan menunjukkan kepercayaan melalui proses berkelanjutan dan real-time. Perusahaan terus fokus membantu bisnis melindungi data, menyederhanakan kepatuhan, dan membuktikan kepercayaan dalam skala besar.
Kami berbicara dengan Janiece Caldwell, yang memimpin Operasi TI di tim Teknik Korporat Vanta, tentang migrasi Freshservice ke Jira Service Management . Dia mengawasi dukungan help desk, sistem tiket internal, dan sistem TI, dengan fokus pada otomatisasi, skalabilitas, dan penyampaian layanan yang efisien. Janiece berbagi tujuan migrasi Vanta, tantangan utama, dan pengalamannya dalam beralih ke JSM dengan Help Desk Migration.
Migrasi Freshservice → Jira Service Management : Berdasarkan Angka
Tiket telah dimigrasikan dari Freshservice ke Jira Service Management
komentar dipindahkan beserta konteks tiket aslinya
Lampiran dimigrasikan dan disimpan
Pemohon & agen telah bermigrasi
hari dari awal proyek hingga penyelesaian menyeluruh
Mengapa Vanta Memutuskan untuk Bermigrasi dari Freshservice ke Jira Service Management
JSM adalah portal permintaan internal kami — IT menggunakannya untuk permintaan akses perangkat keras, perangkat lunak, dan pemecahan masalah, tetapi juga telah menjadi platform bersama untuk People Ops, Workplace, GTM Systems, HR, dan Access Management. Pada dasarnya setiap karyawan Vantan mengaksesnya sebagai pemohon, dan agen IT/Enterprise Engineering kami menggunakannya setiap hari. Kami juga memiliki integrasi Slack sehingga tiket disinkronkan dua arah antara Slack dan JSM.
Freshservice sudah tidak lagi mampu memenuhi kebutuhan kami — skalabilitas, fleksibilitas, dan integrasi semuanya kurang memadai seiring pertumbuhan kami. Kami menginginkan alur kerja yang lebih baik, pelaporan yang lebih baik, dan keselarasan yang lebih erat dengan perangkat rekayasa/TI kami lainnya, jadi kami memutuskan untuk beralih ke JSM.
Gambaran Umum Migrasi
Alur migrasi:
Freshservice → Jira Service Management
Cakupan data yang dimigrasikan
128.000+ tiket
512 ribu komentar
86 ribu lampiran
Tipe data dipindahkan
Tiket, komentar, lampiran, pemohon, agen, grup
Pengaturan kustomisasi tetap terjaga
Alur kerja status, kolom kustom, skema prioritas, tim
Opsi Migrasi
Migrasi demo, gambar sebaris, menambahkan tag pada tiket yang dimigrasikan, migrasi ulang.
Garis waktu
21 hari, dari awal hingga akhir
Hasil
ITSM terpadu pada JSM, dengan integritas jejak audit penuh yang terjaga selama migrasi.
Tantangan
- Data yang ditampilkan di Freshservice dan JSM tidak sama persis.
- Setiap tiket harus tetap mencantumkan informasi pelapor dan penerima tugas asli.
- Item katalog, alur persetujuan, dan otomatisasi harus dibangun ulang di JSM.
- Hapus tipe permintaan yang berlebihan atau sudah usang, daripada hanya menduplikasinya.
- Migrasi Demo membantu mengidentifikasi kesenjangan sejak dini, termasuk masalah pemetaan reporter dan penerima tugas, sebelum migrasi penuh.
Kustomisasi + Opsi Migrasi Siap Pakai yang Disesuaikan dengan Kebutuhan Vanta
Data mana yang paling penting untuk disimpan di Jira Service Management?
Melestarikan data tiket historis penting untuk tujuan kontinuitas dan audit — kami adalah perusahaan kepatuhan, jadi kemampuan untuk menampilkan stempel waktu dan riwayat permintaan penting untuk hal-hal seperti audit SOC 2 kami sendiri. Kami juga ingin tim kami tetap dapat mencari tiket lama di sistem baru daripada kehilangan pengetahuan institusional tersebut.
Seberapa penting kemampuan untuk menyesuaikan migrasi sesuai dengan kebutuhan spesifik tim Anda, dan penyesuaian mana yang paling berharga bagi Anda?
Kustomisasi sangat penting. Freshservice tidak sepenuhnya terintegrasi dengan JSM di setiap bidang — misalnya, kami harus memastikan nama reporter dan penerima tugas asli tetap ada meskipun JSM tidak memiliki bidang yang setara secara langsung.
Kami juga perlu item katalog, alur persetujuan, dan otomatisasi , bukan hanya menyalinnya, karena kami menggunakan migrasi ini sebagai kesempatan untuk membersihkan jenis permintaan yang berlebihan atau sudah usang.
Migrasi demo memungkinkan kami memvalidasi pemetaan kolom dan integritas data sebelum melakukan migrasi historis penuh. Hal ini mengungkap beberapa celah di awal—seperti masalah kolom reporter/penerima tugas—yang dapat kami perbaiki sebelum migrasi sebenarnya dijalankan, alih-alih baru mengetahuinya setelah kejadian.
Kustomisasi yang Dibuat untuk Melestarikan Data dan Konteks Vanta
Migrasi ini membutuhkan lebih dari sekadar transfer data standar untuk memastikan Freshservice data Jira Service Management . Migrasi disesuaikan untuk mempertahankan nilai bidang penting, persetujuan, item layanan, informasi pengguna asli, dan kepemilikan komentar agen. Pemetaan yang disesuaikan ini juga menjaga agar data yang dimigrasikan tetap terstruktur, mudah dicari, dan mudah digunakan oleh tim Vanta di JSM.
- Migrasikan nilai kolom ke dalam deskripsi tiket: ID Asli, Grup, Sumber, Jenis Masalah, Jenis Masalah Orang, Jenis Masalah Hukum, Peran AWS, Kategori. Jika kolom sumber kosong, migrasikan dengan nilai
kosong. - Pindahkan Item Layanan untuk Permintaan Layanan (SR) ke dalam deskripsi tiket.
- Pindahkan informasi persetujuan ke dalam deskripsi tiket, termasuk nama pemberi persetujuan, alamat email, dan tanggal persetujuan.
- Jangan mengisi Penerima Tugas dan Pelapor saat membuat tiket. Tetapkan masalah sebagai Belum Ditugaskan dan tampilkan pelapor sebagai Anonim di antarmuka.
- Pindahkan penerima tugas asli ke Penerima tugas asli dan pemohon asli ke Pelapor asli .
- Untuk komentar yang ditinggalkan oleh agen, tambahkan detail penulis komentar asli di awal komentar dengan format berikut:
Nama Depan & Belakangemail@vanta.com - Identifikasi proses Orientasi Karyawan dan pindahkan ke dalam deskripsi tiket.
- Format nama kolom dalam deskripsi tiket agar dicetak tebal.
Opsi Migrasi Siap Pakai untuk Kontrol Data yang Lebih Baik
Opsi migrasi tambahan digunakan untuk memastikan konten tiket penting tetap dapat diakses dan mudah dikelola setelah pemindahan. Gambar yang disisipkan dipertahankan sebagai lampiran tiket, sementara tag khusus membantu mengidentifikasi dan mengatur catatan yang dimigrasikan.
- Migrasikan gambar yang disematkan langsung sebagai lampiran tiket: Pindahkan gambar yang disematkan langsung dalam konten tiket sebagai lampiran tiket terpisah, sehingga tetap dapat diakses setelah migrasi.
- Tambahkan tag baru: Beri tag pada tiket berdasarkan kolom Grup. Jika tidak ada grup yang ditentukan, tambahkan
migrated-no group. TambahkanFS-ke semua tag ini. - Paket Dukungan Premium: termasuk migrasi ulang, yang memang dibutuhkan oleh tim Vanta. Setelah menyelesaikan semua penyesuaian yang diperlukan dan pengujian awal, migrasi ulang memungkinkan mereka untuk melakukan transfer akhir tanpa kesalahan.
Hasil: Platform JSM Terpadu dengan Data Historis yang Utuh
Sekarang kami memiliki satu platform terpadu, bukan lagi sistem yang rumit, pelaporan dan otomatisasi yang lebih baik, serta riwayat tiket yang dapat dicari di portal baru. Ada masa penyesuaian normal setelah peluncuran, tetapi tidak ada hal besar — sebagian besar hanya pembersihan yang diharapkan.
Masukan
"Secara menyeluruh, dari tahap penemuan hingga transisi penuh, proyek ini berjalan selama beberapa bulan. Kami mulai menggunakan JSM pada awal September, kemudian melakukan migrasi tiket historis dengan Help Desk Migration setelahnya. Prosesnya sedikit lebih lama dari target waktu awal kami, tetapi waktu tambahan tersebut digunakan untuk memastikan pemetaan yang tepat daripada terburu-buru — dan itu sepadan jika dilihat dari sudut pandang retrospektif.".
Saya akan merekomendasikan Help Desk Migration kepada tim lain yang melakukan migrasi serupa. Tim tersebut responsif dan membuat migrasi data historis yang benar-benar kompleks terasa mudah dikelola."
