Migrasi Data untuk Penyedia Layanan Terkelola: PSA Anda, Bukan PSA Klien Anda
Cari "migrasi data untuk penyedia layanan terkelola" dan Anda akan menemukan banyak sekali artikel tentang memindahkan kotak surat klien ke Microsoft 365.
Halaman ini membahas PSA Anda, tiket Anda, dan help desk Anda: sistem yang Anda gunakan untuk menjalankan bisnis Anda. Sebagai MSP, data tersebut milik puluhan, bahkan terkadang ratusan, klien sekaligus, sehingga isolasi per klien, kontinuitas penagihan, dan peralihan yang lancar menjadi lebih penting di sini daripada di tempat lain. Lihat bagaimana perencanaan migrasi khusus industri bekerja, lalu terapkan pada migrasi PSA MSP, di mana risikonya lebih besar.
Mari kita diskusikan rencananya
Tidak diperlukan kartu kredit Pengaturan cepat
Dipercaya oleh lebih dari 60.000 perusahaan
Jenis Migrasi Data: Apa Saja yang Berpindah dalam Migrasi PSA?
Peralihan PSA bukanlah migrasi tiket dengan langkah tambahan. Di balik layar, satu tiket terhubung ke papan, antrian, bidang khusus, kebijakan SLA, dan konfigurasi yang semuanya harus tetap ada setelah pemindahan. Berikut adalah cakupan yang lebih lengkap, dimulai dari data help desk, sesuai urutan yang biasa digunakan oleh sebagian besar MSP:
| Rekor tercipta | Apa saja yang termasuk di dalamnya | Hal-hal yang perlu diperhatikan dalam sebuah film | Catatan isolasi per klien |
|---|---|---|---|
| Tiket help desk dan PSA | Kasus, tiket, rangkaian tiket, papan, antrean, status, tag, kolom kustom | Struktur papan dan antrean jarang sekali sama persis antar peron | Tiket harus tetap mencantumkan perusahaan atau hubungan klien yang tepat |
| Pencatatan waktu dan kontrak | Catatan waktu, catatan kontrak, konfigurasi, referensi penagihan | Informasi mengenai negara bagian tempat penagihan biasanya tidak disertakan bersama dokumen, lihat di bawah ini | Ketentuan kontrak tetap spesifik untuk satu klien dan tidak berlaku untuk klien lain |
| Basis pengetahuan | Artikel, kategori, visibilitas per klien versus internal, lampiran artikel | Pengaturan visibilitas membutuhkan keputusan, bukan hanya aturan pemetaan | Artikel yang dibagikan memerlukan keputusan eksplisit tentang klien mana yang dapat mengaksesnya |
| Data klien dan kontak | Perusahaan, kontak, situs, hierarki organisasi, agen dan struktur grup | Ini adalah tulang punggung yang menjadi dasar kunci migrasi lainnya | Di mana isolasi berhasil atau gagal terlebih dahulu |
| Media dan lampiran | Gambar sebaris, lampiran file, batasan ukuran dan penyimpanan | Batasan ukuran target bisa lebih ketat daripada batasan ukuran sumber | Lampiran mewarisi isolasi dari tiket atau catatan tempat lampiran tersebut berada |
| Riwayat email | Thread masuk dan keluar terkait dengan tiket, pelestarian header | Pelestarian header sangat bervariasi tergantung pada pasangan platform | Thread akan tetap terisolasi selama tiket induknya juga terisolasi |
| Catatan panggilan dan rekaman | Rekaman telepon dan tautan rekaman yang dilampirkan pada tiket | Tautan rekaman terkadang mengarah ke sistem pihak ketiga yang bergerak secara terpisah | Ketergantungan yang sama seperti lampiran |
Itu adalah tujuh set catatan, bukan satu. Tiket adalah jangkar: tiket adalah tumpukan terbesar, dan mudah untuk salah mengira peralihan PSA sebagai migrasi tiket. Tetapi masing-masing dari enam set catatan lainnya membawa isolasi per kliennya sendiri untuk melindungi saat dipindahkan. Entri waktu dan kontrak memiliki bobot finansial yang tidak dimiliki tiket. Data klien adalah tulang punggung yang menjadi acuan semua hal lainnya. Bahkan sesuatu yang biasa seperti lampiran dan log panggilan mewarisi isolasinya dari tiket atau catatan mana pun yang terkait dengannya. Tidak satu pun dari hal-hal tersebut bersifat opsional hanya karena tidak ada yang menyebutkannya terlebih dahulu.
Apa yang sebenarnya ditransfer bergantung pada apa yang akan dirilis oleh platform sumber Anda dan apa yang dapat ditangkap oleh platform target Anda. Anggap tabel ini sebagai dokumen ruang lingkup yang Anda nilai sebelum Anda memutuskan satu pilihan.
Platform Migrasi yang Didukung untuk Perusahaan MSP
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
Periksa nama tersebut untuk kesalahan pengetikan atau tinggalkan pesan kepada kami.
Mengapa Isolasi Per-Klien Adalah Persyaratan Sebenarnya, Bukan Jumlah Tiket?
Isolasi bukanlah fitur yang bisa Anda aktifkan begitu saja. Hal ini bergantung pada bagaimana data dipetakan dan diperiksa selama migrasi. Inilah yang membedakan migrasi help desk MSP dari proyek single-tenant: data tersebut milik beberapa klien, sehingga pemetaan dan validasi perlu dilakukan untuk setiap klien, bukan sekali untuk seluruh dataset.
Fakta tunggal itu saja sudah menambah waktu pengerjaan proyek lebih banyak daripada volume data yang besar. Migrasi yang melibatkan 40 klien dengan volume data sedang dapat memakan waktu lebih lama untuk perencanaan dan validasi dibandingkan migrasi satu klien dengan jumlah data yang jauh lebih banyak. Setiap klien membutuhkan tinjauan dan validasi pemetaan tersendiri sebelum proses migrasi dimulai.
Isolasi bukanlah sesuatu yang diberikan platform secara cuma-cuma. Isolasi berasal dari keputusan yang dibuat selama pemetaan, dan dikonfirmasi melalui validasi per klien sebelum peralihan, bukan diasumsikan hanya karena kedua platform mencantumkan kata "multi-tenant" di halaman pemasaran mereka.
Beginilah tampilan pemetaan yang disengaja di Autotask PSA
Jadi, seperti apa sebenarnya "dibangun dengan sengaja" itu? Di Autotask PSA, setiap kontak harus terhubung ke sebuah perusahaan. Tidak ada jalan pintas. Kontak independen di sistem sumber Anda akan ditugaskan ke sebuah perusahaan selama pemetaan, bukan dibiarkan mengatur diri sendiri.
Autotask PSA juga tidak akan mengizinkan Anda mengubah perusahaan kontak setelah dibuat, dan itulah mengapa migrasi demo untuk memeriksa penugasan perusahaan menjadi lebih penting di sini, terutama jika Anda menggabungkan akun.
Dari sisi pelaporan, validasi berjalan melalui dasbor langsung Migration Wizard, melacak tiket, agen, kontak, dan perusahaan sebagai entitas terpisah saat transfer berlangsung, dan diakhiri dengan laporan tentang apa yang dipindahkan, apa yang tidak, dan mengapa. Semua itu tidak otomatis. Ini adalah aturan pemetaan dan dasbor yang benar-benar dibaca oleh seseorang, yang merupakan klaim yang lebih kecil daripada "isolasi sudah terintegrasi," dan lebih benar.
Beginilah tampilan pemetaan per-klien: Migrasi dari ConnectWise
Ambil ConnectWise PSA sebagai contoh konkret. Setiap tiket, kontak, dan catatan konfigurasi dalam ConnectWise migrasi tergabung dalam sebuah perusahaan, dan sebuah perusahaan terbagi menjadi beberapa lokasi untuk klien yang beroperasi di lebih dari satu tempat. Selama migrasi, hubungan tersebut perlu dipetakan dengan benar untuk setiap klien.
Hal ini menjadi lebih penting ketika platform sumber memiliki beberapa klien yang dikelompokkan dalam satu catatan perusahaan bersama. Itu adalah masalah yang harus dipecahkan sebelum migrasi dimulai, bukan saat sedang berjalan. Tidak ada alat yang dapat memisahkan data klien yang tercampur secara otomatis; itu membutuhkan seseorang, keputusan, dan pemetaan yang disengaja. Disiplin yang sama berlaku untuk migrasi data bagi perusahaan layanan TI secara lebih luas; isolasi bukanlah hal yang unik bagi MSP, hanya saja risikonya lebih tinggi di sini.
Satu lagi mitos yang perlu diluruskan: multi-tenancy adalah fitur produk, bukan hasil migrasi. Sebuah platform yang multi-tenant berarti platform tersebut dapat menampung klien terpisah tanpa klien tersebut saling melihat saat platform berjalan. Ini tidak mengatakan apa pun tentang apakah data masuk ke tempat yang tepat selama migrasi antara dua platform multi-tenant. Di situlah klaim vendor menjadi tidak valid. Jika seseorang menawarkan migrasi kepada Anda, tanyakan kepada mereka sisi mana dari celah tersebut yang mereka maksud.
Validasi setiap klien sebelum peralihan
Dalam praktiknya, validasi per klien sebelum peralihan berarti memeriksa setiap catatan yang dipetakan untuk setiap klien secara terpisah, bukan mengambil sampel secara keseluruhan:
Bagi MSP dengan beberapa klien, proses pembayaran berjalan cepat. Namun bagi MSP dengan puluhan atau ratusan klien, bagian proyek inilah yang paling memakan waktu, bukan proses pemindahan data itu sendiri.
Saran yang baik adalah memvalidasi setiap klien secara terpisah sebelum melakukan cutover. Jika terjadi kegagalan, Anda dapat mengembalikan migrasi klien tersebut tanpa memengaruhi klien yang telah lolos validasi. Hal ini menjaga agar masalah tetap terisolasi dan membuat migrasi secara keseluruhan lebih mudah dikendalikan.
Pertanyaan tentang keamanan dan kepatuhan muncul sejak awal bagi MSP yang mengevaluasi mitra migrasi, dan memang seharusnya demikian. Bacalah Help Desk Migrationkebijakan keamanan bersamaan dengan pendekatan isolasi apa pun yang diusulkan vendor untuk migrasi spesifik Anda.
Rekaman PSA yang Dilengkapi dengan Label Harga
Migrasi help desk MSP tidak berhenti pada tiket. PSA menyimpan catatan waktu dan catatan kontrak bersamaan dengan tiket, dan kedua kategori tersebut memiliki bobot finansial yang tidak dimiliki tiket. Kehilangan jejak riwayat tiket, dan Anda akan mengalami masalah layanan. Kehilangan jejak status penagihan catatan waktu, dan tiga minggu setelah peralihan Anda akan dihadapkan pada sejumlah jam kerja yang seharusnya ditagih bulan lalu yang tidak pernah diproses sebagai tagihan. Setiap pemilik MSP akan mengatakan bahwa itu bukanlah situasi darurat yang sama.
| Jenis catatan | Bergerak langsung | Perlu pemetaan | Memiliki konsekuensi penagihan |
|---|---|---|---|
| Tiket | Ya | Tingkat lapangan, biasanya mudah dipahami | TIDAK |
| Catatan waktu | Sebagai catatan | Ya, strukturnya bervariasi tergantung pasangannya | Ya |
| Kontrak | Sebagian | Lihat tempat penampung di bawah ini | Ya |
| Konfigurasi | Sebagian | Tergantung pada model aset | Kadang-kadang |
| Perusahaan | Ya | Isolasi kritis, lihat di atas | TIDAK |
| Kontak | Ya | Terkait dengan pemetaan perusahaan | TIDAK |
| Situs | Ya | Terkait dengan pemetaan perusahaan | TIDAK |
| Kebijakan SLA | Jarang sekali satu lawan satu | Biasanya dibangun ulang, bukan dipindahkan | TIDAK |
| Kolom kustom | TIDAK | Pengaturan manual pada target | Kadang-kadang |
| Lampiran | Ya | Batasan ukuran dan retensi bervariasi | TIDAK |
Pencatatan Waktu vs. Status Penagihan
Entri waktu biasanya bermigrasi sebagai catatan, tetapi tidak sebagai status penagihan, dan alasannya bersifat struktural: status penagihan biasanya berada di lapisan keuangan platform, bukan pada tiket atau entri waktu itu sendiri. Autotask PSA menjelaskan hal ini dengan baik. Entri waktu yang dicatat pada tiket perlu disetujui dan diposting sebelum berubah menjadi baris yang dapat ditagih. Apa yang dilakukan dan berapa lama waktu yang dibutuhkan, itu bermigrasi bersama catatan dengan baik. Apakah seseorang sudah menyetujui, memposting, atau menagihnya, itu adalah pertanyaan terpisah.
Salah satu hal yang biasanya diselesaikan dalam alur kerja penagihan platform target itu sendiri, bukan ditransfer secara otomatis.
Opsi Wizard & Nuansa Platform
Help Desk Migration mencantumkan "Migrate Time Entries" sebagai opsi bernama yang dapat dipilih di Migration Wizard, yang dijelaskan sebagai pemindahan catatan yang digunakan agen untuk mencatat waktu terhadap tiket. Itu adalah opsi nyata yang didukung, bukan permintaan khusus. Yang tidak dijelaskan dalam deskripsi yang dipublikasikan adalah apakah status persetujuan, diposting, atau ditagih ikut ditransfer untuk pasangan platform spesifik Anda.
Itu adalah celah yang wajar dalam informasi publik, jadi anggap perilaku umum terkait status penagihan di atas sebagai hal yang pasti dan pertanyaan tentang flag khusus pasangan sebagai pertanyaan yang harus Anda tanyakan langsung kepada spesialis migrasi Anda.
Kontrak sebagai Objek Kustom
Kontrak mendapatkan perlakuan yang sama. Baik daftar bidang yang diterbitkan oleh ConnectWise PSA maupun Autotask PSAtidak menyertakan kontrak sebagai tipe catatan standar. Bidang yang didokumentasikan oleh ConnectWise PSA mencakup anggota, kontak, perusahaan, dan tiket. Autotask PSAmencakup agen, perusahaan, kontak, dan tiket. Kontrak termasuk dalam migrasi Objek Kustom, kategori yang sama dengan aset dan garansi, yang ditangani melalui Layanan Profesional dan bukan alur pemetaan bidang standar.
Singkatnya: kontrak tidak secara otomatis ikut serta dalam migrasi tiket Anda. Anggarkan biaya untuk kontrak sebagai proyek tersendiri.
Struktur Perusahaan-ke-Kontak
Help Desk Migration memindahkan catatan tiket dan kontak antar platform PSA, mempertahankan struktur perusahaan-ke-kontak yang menjaga catatan setiap klien tetap terpisah, dan memperlakukan rekonsiliasi status penagihan sebagai langkah tersendiri yang berbeda dari pemindahan catatan yang mendasarinya. Jika evaluasi Anda bergantung pada perilaku flag penagihan yang tepat untuk pasangan spesifik Anda, ada baiknya untuk mengkonfirmasinya langsung sebelum menentukan ruang lingkup.
Lihat Autotask PSA impor data untuk detail spesifik platform.
Lakukan Sendiri, Terkelola, atau Kustom: Cara Memilih Migrasi untuk Penyedia Layanan Terkelola
Tiga cara untuk melakukan migrasi help desk untuk operasional MSP, dan mana yang paling sesuai untuk Anda bergantung pada jumlah klien lebih daripada volume data:
Panduan Migrasi, layanan mandiri
Cocok jika Anda adalah MSP kecil, dengan beberapa klien, yang memindahkan satu pasangan platform yang didukung dengan baik tanpa pemetaan per klien yang rumit. Anda menentukan cakupan bidang, menjalankan migrasi uji, meninjaunya, lalu menjalankan migrasi penuh sendiri.
Layanan Terkelola
Ini adalah standar untuk sebagian besar proyek MSP, karena pemetaan per klien di puluhan atau ratusan klien merupakan sebuah percakapan, bukan daftar periksa yang Anda isi sendiri. Inilah Help Desk Migrationdari layanan migrasi terkelola: kami merencanakan proyek bersama Anda, membangun pemetaan, menjalankan migrasi uji untuk ditinjau, lalu menangani migrasi tersebut.
Konsultasi
Untuk kasus yang lebih rumit: data sumber yang tidak biasa, objek kustom, beberapa platform sumber yang perlu dikonsolidasikan sekaligus, atau masalah pengurutan di samping proyek sisi klien yang terpisah.
Pengimpor PSA bawaan memang layak mendapat pujian di sini. Sebagian besar platform PSA memiliki CSV atau bawaan, dan untuk kumpulan data yang bersih dan terstruktur dengan baik dari satu sumber, alat tersebut menangani pekerjaan dengan sangat baik. Jadi, di mana layanan migrasi terkelola benar-benar berperan? Di area yang tidak dirancang untuk pengimpor bawaan: pemetaan per klien dalam skala besar, rekonsiliasi catatan penagihan di berbagai platform dengan model keuangan yang berbeda, dan validasi yang memeriksa data setiap klien secara terpisah alih-alih mengambil sampel agregat dan menganggapnya sudah cukup.
Bayangkan dua MSP berdampingan. Yang satu menjalankan dua klien dan volume tiket yang moderat pada platform yang terdokumentasi dengan baik dengan pemetaan yang mendekati satu banding satu. Layanan mandiri adalah pilihan yang tepat di sini. Yang lain menjalankan 50 klien, dan jumlah total catatannya mungkin terlihat lebih kecil di atas kertas daripada MSP dengan dua klien. Itu tidak masalah. 50 klien berarti 50 pemetaan dan 50 validasi, karena pekerjaan itu meningkat seiring dengan jumlah klien, bukan jumlah baris, dan tidak menyusut seperti upaya migrasi satu penyewa ketika volume menurun.
Tidak ada API sama sekali pada sumber Anda? Itu akan mengubah percakapan tentang ruang lingkup sejak hari pertama. Beberapa pengaturan PSA yang lebih lama atau yang telah banyak disesuaikan hanya mengekspor melalui CSV, yang memang bisa dilakukan, tetapi hal itu menggeser seberapa banyak proyek yang dapat Anda otomatiskan dibandingkan dengan seberapa banyak yang dipetakan secara manual.
Untuk versi yang spesifik untuk platform tertentu, Halo Service Solutions migrasi dan ConnectWise ke Freshdesk migrasi mencakup dua pasangan platform yang paling sering digunakan oleh MSP.
Memotong Tanpa Menyisakan Celah Layanan yang Terlihat
Cutover adalah saat migrasi help desk untuk operasional MSP menjadi nyata: Anda tidak bisa mengambil jeda pemeliharaan yang akan disadari oleh klien Anda.
Kendala itulah yang membuat proses peralihan terlihat seperti operasi paralel dan bukan sekadar proses sekali aktif: kedua platform tetap aktif untuk jangka waktu tertentu setelah migrasi utama berjalan, dan migrasi Delta memindahkan semua yang dibuat atau diperbarui dalam jangka waktu tersebut: tiket baru, balasan, catatan waktu, sebelum Anda menonaktifkan sumbernya secara permanen.
Menjalankan dua platform secara bersamaan memiliki konsekuensi yang perlu direncanakan dengan matang: agen yang menangani tiket di kedua sistem selama periode tumpang tindih, dan skema penomoran yang harus masuk akal di kedua sistem. Itu adalah keputusan yang dibuat sebelumnya, bukan detail yang diselesaikan pada hari peralihan.
Ada dua keputusan spesifik, keduanya dijadwalkan sebelum peralihan dimulai
Pertama, penomoran tiket: dapatkah platform target mempertahankan penomoran sumber, ataukah platform tersebut memulai urutan penomorannya sendiri?
Ini benar-benar bergantung pada ke mana Anda akan pergi. Kolom tiket yang didokumentasikan Autotask PSAmencantumkan ID dan nomor tiket sebagai kolom terpisah, sehingga nomor sumber memiliki tempat untuk dimasukkan. Kolom yang didokumentasikan ConnectWise PSA mencantumkan ID, tetapi tidak ada kolom nomor tiket terpisah, yang berarti nomor tiket tersebut masuk sebagai nilai dan tidak selalu mereproduksi urutan ConnectWisesendiri. Jika klien Anda memperhatikan nomor tiket, konfirmasikan hal ini secara khusus untuk target Anda sebelum Anda menentukan ruang lingkup proyek. Platform yang Anda tinggalkan bukanlah prediktor yang andal untuk platform yang akan Anda tuju.
Kedua: kapan portal yang menghadap klien beralih? Itu pertanyaan yang lebih kecil tetapi memiliki konsekuensi yang lebih besar daripada yang terlihat. Klien telah menyimpan URL tersebut sebagai bookmark dan telah masuk melalui URL tersebut berkali-kali. Menjadwalkan peralihan tersebut sebagai hal yang dipikirkan kemudian, setelah data sudah dipindahkan, adalah cara yang tepat untuk mengubah migrasi yang secara teknis bersih menjadi pengalaman klien yang buruk.
Tidak ada yang namanya migrasi PSA tanpa downtime sama sekali, dan siapa pun yang mengatakan sebaliknya hanya berjualan, bukan menjelaskan. Yang realistis, menurut pengalaman Help Desk Migration, adalah dampak yang hampir nol bagi klien, dan seberapa dekat Anda dengan kondisi tersebut bergantung pada jumlah klien, konfigurasi portal, dan bagaimana platform target Anda menangani penomoran tiket. MSP yang kliennya hanya mengirimkan tiket melalui email biasanya memiliki proses transisi yang lebih mudah daripada MSP yang menjalankan portal klien yang banyak digunakan. Satu sistem yang lebih sedikit untuk dialihkan secara langsung, satu hal yang lebih sedikit yang dapat berjalan tidak sesuai rencana.
Berapa Biaya Sebenarnya dan Berapa Lama Waktu yang Dibutuhkan untuk Migrasi MSP?
Penetapan harga migrasi data MSP mengikuti logika yang berbeda dari proyek single-tenant, dan pertanyaan yang sama muncul pertama kali: berapa biayanya, dan berapa lama waktu yang dibutuhkan hingga proses selesai? Pertanyaan yang wajar. Berikut adalah hal-hal yang sebenarnya memengaruhi angka tersebut:
Jumlah klien adalah variabel yang membedakan proyek MSP dari proyek single-tenant, dan seringkali lebih berpengaruh terhadap biaya dan jangka waktu daripada volume data mentah. Migrasi dengan volume rendah yang tersebar di 40 klien dapat berakhir dengan biaya lebih tinggi dan waktu lebih lama daripada migrasi dengan volume tinggi untuk satu perusahaan, karena pemetaan dan validasi meningkat seiring dengan jumlah klien, bukan jumlah baris. Waktu entri dan kedalaman kontrak memperparah hal itu: PSA dengan beberapa jenis kontrak dan aturan penagihan per klien yang terperinci membutuhkan waktu lebih lama untuk dipetakan daripada yang menjalankan struktur datar sederhana, terlepas dari volume tiket.
Apakah sumber data Anda memiliki API atau tidak, secara langsung memengaruhi biaya dan jangka waktu. Akses API umumnya berarti jalur yang lebih otomatis. Sumber data yang hanya berupa CSVatau yang sangat disesuaikan biasanya berarti pemetaan manual yang lebih banyak sebelum migrasi dimulai. Harga migrasi Help Desk Migrationmencerminkan variabel-variabel tersebut, bukan angka tetap per data.
Mari kita berikan angka konkret daripada bertele-tele. Help Desk Migration dihitung berdasarkan jumlah data, dan penetapan harganya tidak linier: semakin banyak data yang Anda migrasikan, semakin murah biaya per datanya. Pada paket Standar tanpa kustomisasi, Harga migrasi 1.000 data dikenakan biaya $100 . Migrasi 10.000 data dikenakan biaya $514 . Perhitungannya menguntungkan volume, itulah sebabnya 40 migrasi kecil per klien tidak memberikan keuntungan yang sama dengan satu migrasi besar untuk satu penyewa.
Paket layanan disesuaikan dengan kompleksitas: Paket Standar mencakup migrasi hard-switch satu kali, Paket Premium menangani hingga 50.000 data dengan dukungan khusus, dan Paket Signature serta Enterprise menambahkan migrasi Delta, migrasi interval, migrasi multi-thread, dan tim akun khusus untuk proyek multi-klien yang lebih besar.
Semua ini tidak menggantikan penawaran harga sebenarnya. Help Desk Migration hanya memberikan harga pasti di atas kertas setelah migrasi demo gratis mengkonfirmasi apa yang sebenarnya akan Anda hadapi.
Perkirakan biaya migrasi Anda sebagai titik awal berdasarkan jumlah klien dan platform Anda sendiri, terutama jika Anda adalah MSP yang lebih kecil di mana layanan mandiri mungkin benar-benar merupakan pilihan yang tepat. Jumlah klien lebih besar, kompleksitas lebih tinggi? Panggilan penjajakan akan memberi Anda jawaban yang lebih bermanfaat daripada perkiraan berdasarkan volume.
Dua MSP, Dua Migrasi, Dua Kisah Nyata
Dua kisah nyata migrasi MSP PSA membuktikan hal ini lebih baik daripada janji apa pun.
VestaTech, berekspansi ke ConnectWise PSA
VestaTech, sebuah perusahaan layanan TI dan keamanan dari Ardooie, Belgia, bagian dari keluarga perusahaan Vestagroup, perlu memindahkan sekitar 2.000 tiket, pelanggan, dan catatan aktivitas terkait dari Freshservice ke ConnectWise PSA. Sebelum migrasi, tim mengandalkan skrip ekspor buatan sendiri, dan mereka telah mengesampingkan impor secara manual karena dianggap lebih banyak pekerjaan daripada yang sepadan dengan volume data tersebut. Uji coba awal menemukan beberapa kesalahan kecil, yang diselesaikan oleh VestaTech dan tim dukungan sebelum migrasi penuh. Setelah meninjau hasil uji coba, VestaTech menyatakan bahwa tidak ada opsi lain yang mendekati keberhasilan migrasi ini. Migrasi VestaTech ke ConnectWise memberikan contoh yang sangat baik bagi perusahaan jasa yang beralih ke PSA penuh. Ini menunjukkan peralihan platform langsung daripada penggabungan, perbedaan yang penting untuk cerita selanjutnya.
ROIcode, menggabungkan dua instance dukungan menjadi satu
ROIcode, sebuah perusahaan teknologi informasi dan layanan yang berbasis di Denver, Colorado, perlu menggabungkan dua sistem help desk terpisah, Kayako Classic dan Zendesk, ke dalam satu Kayako , daripada mematikan salah satunya secara keseluruhan. Penggabungan akun ROIcode di Kayakomengkonsolidasikan kedua sumber help desk ke dalam satu instance sambil mempertahankan riwayat dukungan lengkap perusahaan sejak hari pertama. Jika tim Anda perlu menggabungkan akun setelah akuisisi daripada beralih platform sepenuhnya, studi kasus ini menunjukkan cara menjalankan proses tersebut dengan lancar.
Jalur Migrasi yang Terdokumentasi vs. Hasil yang Dicapai Pelanggan
Selain kisah sukses pelanggan yang disebutkan, Help Desk Migration telah mendokumentasikan dan memetakan jalur migrasi untuk platform PSA dan RMM yang paling banyak digunakan oleh MSP: SuperOps, Syncro, dan Atera, ditambah panduan langkah demi langkah untuk ConnectWise migrasi, Autotask PSA migrasi, SuperOps daftar periksa migrasi data, dan Halo Service Solutions daftar periksa migrasi data.
Penting untuk menjelaskan secara tepat apa arti sebenarnya dari kedua jenis bukti ini, karena MSP yang mengevaluasi vendor akan memperhatikan ketika perbedaan tersebut menjadi kabur. Kisah pelanggan yang disebutkan namanya, seperti VestaTech atau ROIcode, adalah sebuah hasil: satu perusahaan, satu migrasi, satu hasil, dilaporkan sekali dan tidak diekstrapolasi lebih lanjut. Jalur migrasi yang terdokumentasi berbeda. Ini memberi tahu Anda Help Desk Migration mendukung pasangan platform tersebut dan pemetaan sudah ada untuknya, bukan bahwa proyek dengan ukuran atau kompleksitas tertentu telah benar-benar dijalankan di atasnya. Keduanya penting. Tidak ada yang menggantikan yang lain, dan halaman mana pun yang memperlakukan keduanya seolah-olah dapat dipertukarkan adalah halaman yang seharusnya kurang Anda percayai.
Skala adalah separuh bagian lain dari pertanyaan kepercayaan tersebut. Help Desk Migration telah menyelesaikan lebih dari 60.000 migrasi, mendukung lebih dari 100 platform, dan memegang kepatuhan SOC 2 Tipe II dan SOC 3 Semua itu tidak menggantikan kisah VestaTech atau ROIcode. Itu hanya menegaskan disiplin yang sama yang mereka miliki tersedia dalam skala besar, bukan hanya sekali saja.
Sebelum Anda Menilai Ini, Mulailah dari Sini
Bagi MSP, lakukan migrasi klien demi klien, bukan sebagai satu set data besar.
Sebelum Anda memutuskan untuk melakukan peralihan, jalankan lima pemeriksaan yang sama untuk setiap klien:
Jangan menggunakan satu pemetaan yang sama untuk semua klien tanpa memeriksa perbedaannya. Klien dengan volume rendah yang memiliki struktur perusahaan atau bidang khusus yang berbeda mungkin memerlukan pemetaan yang berbeda dari klien yang jauh lebih besar.
SuperOps Daftar periksa migrasi data Help Desk Migrationdari dan Halo Service Solutions daftar periksa mengikuti struktur yang sama, yaitu menghubungkan, mengkonfigurasi, memilih, memetakan, dan menguji. Gunakan format tersebut sebagai titik awal untuk daftar periksa migrasi per klien Anda sendiri.
Aturannya sederhana: satu klien, satu tinjauan pemetaan, satu validasi sebelum peralihan.
Pertanyaan yang sering diajukan
Help desk MSP adalah lapisan tiket dan layanan help desk di dalam PSA, atau terkadang sebagai alat mandiri, yang digunakan teknisi untuk mencatat, mengarahkan, dan menyelesaikan permintaan untuk berbagai organisasi klien dari satu instance. Biasanya, help desk berada di samping sistem penagihan, kontrak, dan catatan aset, bukan berfungsi sebagai alat pendukung tersendiri. Bandingkan perangkat lunak ITSM untuk MSP jika Anda sedang memilih atau mempertimbangkan ulang perangkat lunak yang sudah ada.
MSP adalah model bisnis: sebuah perusahaan yang mengelola TI untuk bisnis lain berdasarkan kontrak. PSA adalah kategori perangkat lunak: platform otomatisasi layanan profesional yang menjalankan bisnis tersebut, menghubungkan tiket, pencatatan waktu, kontrak, dan penagihan di satu tempat. Sebagian besar MSP beroperasi menggunakan PSA daripada help desk generik, karena PSA memiliki lapisan keuangan yang tidak dimiliki help desk. Lihat ConnectWise migrasi untuk contoh umum kategori ini.
Bagi MSP, PSA berfungsi sebagai sistem operasi untuk pekerjaan klien. Tiket, catatan waktu, kontrak, dan penagihan semuanya dilacak terhadap klien, lokasi, atau kontak tertentu, seringkali juga terhadap data RMM. Help desk berhenti pada "tiket terselesaikan". PSA berlanjut ke "jam kerja yang dicatat" dan "faktur yang dibuat". Lihat Autotask PSA untuk contoh kerja dari struktur tersebut.
Berbagai sumber membagi hal ini secara berbeda, tetapi sebagian besar kerangka kerja membagi migrasi data menjadi migrasi penyimpanan, database , migrasi aplikasi, dan migrasi proses bisnis, sebuah model yang dibangun untuk infrastruktur, bukan khusus untuk PSA atau catatan tiket. Jika memang itu yang Anda cari, cara Help Desk Migrationkerja proses mencakup versi tingkat catatan yang berlaku untuk data layanan pelanggan.
Tidak ada satu alat terbaik pun. Semuanya bergantung pada platform yang digunakan, apakah sumber data memiliki API, dan seberapa banyak migrasi yang membutuhkan pemetaan khusus atau pencocokan bidang langsung. Khusus untuk data PSA dan help desk, bandingkan Help Desk Migrationdengan layanan migrasi alat impor bawaan platform sumber Anda sebelum Anda mengambil keputusan apa pun.
"Terbaik" bergantung pada jumlah klien Anda, apakah Anda memerlukan penagihan dan pelacakan waktu bawaan, dan seberapa dalam integrasi yang Anda butuhkan. Beberapa MSP menjalankan PSA, ConnectWise , atau Autotask khusus. Yang lain menjalankan help desk yang lebih ringan bersamaan dengan penagihan terpisah. Bandingkan opsi help desk dan ITSM yang dirancang untuk MSP sebelum Anda berasumsi bahwa PSA lengkap adalah satu-satunya jalan masuk.
Selain PSA itu sendiri, rangkaian perangkat Anda biasanya mencakup perangkat lunak RMM untuk pemantauan dan manajemen jarak jauh, platform dokumentasi, dan terkadang lapisan tiket terpisah di atasnya. Contoh PSA dan RMM untuk MSP meliputi ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOne, dan SherpaDesk, ditambah alat ITSM yang dibangun khusus untuk kelompok MSP seperti ManageEngine ServiceDeskeDesk MSP. Lihat SuperOps pesaing untuk melihat salah satu opsi all-in-one yang lebih baru.
CRM melacak alur penjualan, kontak, dan kesepakatan. PSA melacak penyampaian layanan: tiket, waktu, kontrak, penagihan terhadap klien yang sudah menjadi pelanggan, bukan prospek. Beberapa platform menggabungkan keduanya, tetapi untuk MSP, PSA biasanya merupakan sistem pencatatan untuk pekerjaan layanan, sementara CRM, jika Anda menggunakannya, tetap fokus pada bisnis baru. Lihat bagaimana ConnectWise menyusun data tersebut.
"MSP di cloud" biasanya merujuk pada penyedia layanan terkelola yang mengelola infrastruktur cloud klien, atau perpindahan klien ke layanan cloud seperti Microsoft 365. Itu adalah proyek yang berbeda dari yang dibahas di halaman ini: migrasi data PSA dan layanan helpdesk Anda sendiri, bukan lingkungan cloud klien. Lihat mengapa MSP beralih platform untuk versi pertanyaan dari sisi platform.
Kerangka kerja umum mencantumkan rehosting, replatforming, repurchasing, refactoring, retiring, retaining, dan relocating, sebuah model yang dibangun untuk migrasi infrastruktur dan aplikasi, bukan data PSA atau tiket. Jika pencarian migrasi cloud yang sebenarnya membawa Anda ke sini, lihat bagaimana proses migrasi bekerja untuk padanan tingkat catatan yang berlaku untuk data layanan pelanggan dan PSA.