Datenmigration für Managed Service Provider: Ihre PSA, nicht die Ihrer Kunden
Gibt man „Datenmigration für Managed Service Provider“ ein, findet man unzählige Artikel über die Migration von Client-Postfächern zu Microsoft 365.
Diese Seite behandelt Ihr PSA-System, Ihre Tickets und Ihren Service Desk: das System, mit dem Ihr Geschäft läuft. Als Managed Service Provider (MSP) gehören diese Daten Dutzenden, manchmal Hunderten von Kunden gleichzeitig. Daher sind die Trennung der Kundendaten, die Kontinuität der Abrechnung und ein reibungsloser Systemwechsel hier wichtiger als anderswo. Erfahren Sie, wie branchenspezifische Migrationsplanung funktioniert, und wenden Sie diese Erkenntnisse auf eine PSA-Migration für einen MSP an, wo die Anforderungen deutlich höher sind.
Lassen Sie uns über einen Plan sprechen
Keine Kreditkarte nötig Schnelles Setup
Mehr als 60.000 Unternehmen vertrauen uns
Arten der Datenmigration: Was wird bei einer PSA-Migration verschoben?
Ein PSA-Switch ist keine einfache Ticketmigration mit zusätzlichen Schritten. Im Hintergrund verknüpft ein einzelnes Ticket Boards, Warteschlangen, benutzerdefinierte Felder, SLA-Richtlinien und Konfigurationen, die alle auch nach der Migration erhalten bleiben müssen. Hier der vollständige Überblick, beginnend mit den Helpdesk-Daten, in der Reihenfolge, in der die meisten MSPs vorgehen:
| Rekordsatz | Was es beinhaltet | Worauf man bei einem Film achten sollte | Isolationsvermerk pro Klient |
|---|---|---|---|
| Hilfe-Desk und PSA-Tickets | Fälle, Tickets, Ticket-Threads, Boards, Warteschlangen, Status, Tags, benutzerdefinierte Felder | Board- und Warteschlangenstrukturen stimmen zwischen den Plattformen selten eins zu eins überein | Die Tickets müssen die korrekte Firmen- oder Kundenbeziehung beibehalten |
| Zeiterfassung und Verträge | Zeiterfassungsdaten, Vertragsunterlagen, Konfigurationen, Rechnungsbelege | Der Abrechnungsstaat wird in der Regel nicht mit dem Datensatz übertragen, siehe unten | Die Vertragsbedingungen bleiben kundenspezifisch und gelten nicht für andere Kunden |
| Wissensdatenbank | Artikel, Kategorien, Sichtbarkeit pro Kunde versus intern, Artikelanhänge | Die Sichtbarkeitseinstellungen erfordern eine Entscheidung, nicht nur eine Zuordnungsregel | Für geteilte Artikel muss explizit festgelegt werden, welche Clients darauf zugreifen können |
| Kunden- und Kontaktdaten | Unternehmen, Kontakte, Standorte, Organisationshierarchie, Agenten- und Gruppenstruktur | Dies ist das Rückgrat, von dem die restlichen Migrationsschlüssel abgezogen werden | Wo Isolation zuerst gelingt oder scheitert |
| Medien und Anhänge | Inline-Bilder, Dateianhänge, Größen- und Aufbewahrungsbeschränkungen | Die Zielgrößenbeschränkungen können enger sein als die der Quelle | Anhänge erben die Isolation von dem Ticket oder Datensatz, zu dem sie gehören |
| E-Mail-Verlauf | Eingehende und ausgehende Threads, die mit Tickets verknüpft sind, Header-Erhaltung | Die Header-Erhaltung variiert stark je nach Plattformpaar | Threads bleiben so lange isoliert, wie das übergeordnete Ticket dies tut |
| Anrufprotokolle und Aufzeichnungen | Telefonaufzeichnungen und Aufzeichnungslinks, die mit Tickets verknüpft sind | Aufzeichnungslinks verweisen manchmal auf ein Drittanbietersystem, das sich separat bewegt | Gleiche Abhängigkeit wie Anhänge |
Das sind sieben Datensätze, nicht nur einer. Tickets bilden den Kern: Sie stellen den größten Anteil dar, und ein PSA-Wechsel wird leicht mit einer Ticketmigration verwechselt. Doch jeder der anderen sechs Datensätze verfügt über eine eigene mandantenspezifische Isolation, um die Daten während der Migration zu schützen. Zeiteinträge und Verträge haben ein finanzielles Gewicht, das Tickets nicht haben. Kundendaten sind die Grundlage für alles andere. Selbst so alltägliche Dinge wie Anhänge und Anrufprotokolle erben ihre Isolation von dem jeweiligen Ticket oder Datensatz, dem sie zugeordnet sind. Keiner dieser Datensätze ist optional, nur weil er nicht zuerst erwähnt wurde.
Was tatsächlich übertragen wird, hängt davon ab, welche Daten Ihre Quellplattform freigibt und welche Daten Ihre Zielplattform erfassen kann. Betrachten Sie diese Tabelle als ein Dokument zur Abgrenzung des Projektumfangs, das Sie prüfen, bevor Sie sich für eine bestimmte Option entscheiden.
Unterstützte Migrationsplattformen für MSP-Unternehmen
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
Bitte überprüfen Sie den Namen auf Tippfehler oder hinterlassen Sie uns eine Nachricht.
Warum die Isolation pro Mandant die eigentliche Anforderung ist, nicht die Ticketanzahl
Isolation ist keine Funktion, die man einfach aktivieren kann. Sie hängt davon ab, wie die Daten während der Migration zugeordnet und geprüft werden. Genau das unterscheidet die Migration eines MSP-Helpdesks von einem Projekt mit einem einzelnen Mandanten: Die Daten gehören mehreren Mandanten, daher müssen Zuordnung und Validierung für jeden Mandanten einzeln erfolgen, nicht nur einmal für den gesamten Datensatz.
Diese Tatsache allein verlängert ein Projekt deutlich stärker als das Datenvolumen. Eine Migration von 40 Kunden mit moderatem Datenvolumen kann hinsichtlich Planung und Validierung mehr Zeit in Anspruch nehmen als eine Migration eines einzelnen Kunden mit deutlich mehr Datensätzen. Jeder Kunde benötigt vor der Umstellung eine eigene Überprüfung und Validierung der Zuordnung.
Isolation ist keine Selbstverständlichkeit einer Plattform. Sie resultiert aus Entscheidungen während der Mapping-Phase und wird vor der Umstellung durch eine clientseitige Validierung bestätigt – sie wird nicht einfach vorausgesetzt, nur weil beide Plattformen auf ihren Marketingseiten das Wort „Multi-Tenant“ verwenden.
Wie die gezielte Zuordnung in Autotask PSA aussieht
Wie sieht „bewusst erstellt“ konkret aus? In Autotask PSAmuss jeder Kontakt mit einem Unternehmen verknüpft sein. Es gibt keine Alternative. Einzelne Kontakte in Ihrem Quellsystem werden während der Zuordnung einem Unternehmen zugewiesen und nicht sich selbst überlassen.
Autotask PSA erlaubt es Ihnen außerdem nicht, die Firma eines Kontakts nach dessen Erstellung zu ändern. Genau deshalb ist eine Demo-Migration zur Überprüfung der Firmenzuordnung hier besonders wichtig, insbesondere wenn Sie Konten zusammenführen.
Im Bereich Reporting erfolgt die Validierung über das Live-Dashboard des Migrationsassistenten. Dabei werden Tickets, Agenten, Kontakte und Unternehmen während der Übertragung als separate Einheiten erfasst und abschließend ein Bericht erstellt, der aufzeigt, was übertragen wurde, was nicht und warum. Nichts davon geschieht automatisch. Es handelt sich um eine Zuordnungsregel und ein Dashboard, das tatsächlich von einem Benutzer gelesen wird. Das ist zwar weniger aussagekräftig als die Behauptung, die Isolation sei integriert, aber dennoch zutreffender.
So sieht die Zuordnung pro Client aus: Migration von ConnectWise
Nehmen wir ConnectWise PSA als konkretes Beispiel. Jedes Ticket, jeder Kontakt und jeder Konfigurationsdatensatz in der ConnectWise Migration wird einem Unternehmen zugeordnet, und ein Unternehmen wird in Standorte für Kunden mit mehreren Standorten unterteilt. Während einer Migration müssen diese Beziehungen für jeden Kunden korrekt abgebildet werden.
Dies gewinnt an Bedeutung, wenn die Quellplattform mehrere Kunden unter einem gemeinsamen Firmendatensatz gruppiert hat. Dieses Problem muss vor Beginn der Migration gelöst werden, nicht währenddessen. Kein Tool kann vermischte Kundendaten automatisch trennen; dazu braucht es eine Person, eine Entscheidung und eine sorgfältige Zuordnung. Dieselbe Vorgehensweise gilt generell für die Datenmigration von IT-Dienstleistungsunternehmen ; die Trennung der Daten ist nicht nur für Managed Service Provider (MSPs) relevant, hat hier aber eine höhere Priorität.
Ein weiterer Mythos, der widerlegt werden sollte: Mandantenfähigkeit ist eine Produktfunktion, kein Ergebnis einer Migration. Eine mandantenfähige Plattform kann mehrere Clients gleichzeitig verwalten, ohne dass diese sich während des Betriebs gegenseitig beeinflussen. Sie sagt jedoch nichts darüber aus, ob Datensätze bei einer Migration zwischen zwei mandantenfähigen Plattformen korrekt gespeichert werden. Genau hier liegt die Diskrepanz zwischen den Aussagen der Anbieter. Wenn Ihnen jemand eine Migration verkaufen will, fragen Sie ihn, welche Seite dieser Diskrepanz er meint.
Vor der Umstellung jeden Kunden prüfen
In der Praxis bedeutet die clientbezogene Validierung vor der Umstellung, dass die zugeordneten Datensätze jedes einzelnen Clients geprüft werden und nicht nur Stichproben aus der Gesamtheit:
Für einen Managed Service Provider (MSP) mit wenigen Kunden geht die Abwicklung schnell. Bei einem Unternehmen mit Dutzenden oder Hunderten von Kunden ist es der zeitaufwändigste Teil des Projekts, der den Kalender in Anspruch nimmt, mehr noch als die Datenübertragung selbst.
Ein guter Tipp ist, jeden Kunden vor der Umstellung separat zu validieren. Im Fehlerfall kann die Migration des betroffenen Kunden rückgängig gemacht werden, ohne die bereits validierten Kunden zu beeinträchtigen. Dadurch bleiben Probleme isoliert und die gesamte Migration lässt sich leichter steuern.
Sicherheits- und Compliance-Fragen tauchen bei der Auswahl eines Migrationspartners für Managed Service Provider (MSPs) frühzeitig auf – und das zu Recht. Lesen Sie Help Desk Migrationdie Sicherheitsrichtlinie von zusammen mit dem vom Anbieter für Ihre spezifische Migration vorgeschlagenen Isolationsansatz.
Die PSA-Schallplatten, die mit einem Preisschild versehen sind
Die Migration des Helpdesks eines Managed Service Providers (MSP) beschränkt sich nicht auf Tickets. Ein PSA (Professional Services Account) speichert Zeiterfassungen und Vertragsdatensätze direkt neben den Tickets. Diese beiden Kategorien haben ein finanzielles Gewicht, das Tickets allein nicht haben. Geht die Tickethistorie verloren, hat man ein Problem mit dem Service. Verliert man den Abrechnungsstatus einer Zeiterfassung, sieht man drei Wochen nach der Umstellung einen Großteil der abrechnungsfähigen Stunden des Vormonats, die nie als abrechnungsfähig übertragen wurden. Jeder MSP-Inhaber wird Ihnen bestätigen, dass dies nicht dasselbe ist wie ein Notfall.
| Datensatztyp | Bewegt sich direkt | Bedarfsanalyse | Hat Auswirkungen auf die Abrechnung |
|---|---|---|---|
| Tickets | Ja | Feldebene, in der Regel unkompliziert | NEIN |
| Zeiteinträge | Wie Aufzeichnungen | Ja, die Struktur variiert von Paar zu Paar | Ja |
| Verträge | Teilweise | Siehe Platzhalter unten | Ja |
| Konfigurationen | Teilweise | Hängt vom Anlagenmodell ab | Manchmal |
| Unternehmen | Ja | Isolationskritisch, siehe oben | NEIN |
| Kontakte | Ja | An die Unternehmenskartierung gebunden | NEIN |
| Websites | Ja | An die Unternehmenskartierung gebunden | NEIN |
| SLA-Richtlinien | Selten eins zu eins | Normalerweise wiederaufgebaut, nicht versetzt | NEIN |
| Benutzerfelder | NEIN | Manuelle Einrichtung auf dem Zielsystem | Manchmal |
| Anhänge | Ja | Größen- und Aufbewahrungsgrenzen variieren | NEIN |
Zeiteinträge vs. Abrechnungsstatus
Zeiteinträge werden üblicherweise als Datensätze migriert, jedoch nicht als Abrechnungsstatus. Der Grund dafür ist strukturell bedingt: Der Rechnungsstatus befindet sich in der Regel in der Finanzebene einer Plattform, nicht im Ticket oder im Zeiteintrag selbst. Autotask PSA verdeutlicht dies. Ein zu einem Ticket erfasster Zeiteintrag muss genehmigt und verbucht werden, bevor er zu einer abrechnungsfähigen Position wird. Die durchgeführten Arbeiten und die dafür benötigte Zeit werden problemlos mit dem Datensatz migriert. Ob der Eintrag bereits genehmigt, verbucht oder in Rechnung gestellt wurde, ist eine andere Frage.
Eine, die üblicherweise im Abrechnungsprozess der Zielplattform selbst abgeglichen wird, anstatt automatisch übernommen zu werden.
Assistentenoptionen und Plattformnuancen
Help Desk Migration listet „Zeiteinträge migrieren“ als benannte, auswählbare Option im Migrationsassistenten auf. Diese Option beschreibt das Übertragen der Datensätze, die Agenten zur Zeiterfassung für Tickets verwenden. Es handelt sich dabei um eine offizielle, unterstützte Option und nicht um eine Sonderanfertigung. Die veröffentlichte Beschreibung gibt jedoch nicht an, ob der Genehmigungs-, Buchungs- oder Rechnungsstatus für Ihre spezifische Plattformkombination ebenfalls übertragen wird.
Hierbei handelt es sich um eine ehrliche Lücke in den öffentlich zugänglichen Informationen. Behandeln Sie daher das oben beschriebene allgemeine Verhalten des Abrechnungsstatus als gesichert und die Frage nach dem paarspezifischen Flag als eine, die Sie direkt Ihrem Migrationsspezialisten stellen sollten.
Verträge als benutzerdefinierte Objekte
Verträge werden gleich behandelt. Weder ConnectWise PSA noch Autotask PSAführen Verträge als Standarddatensatztyp in ihren veröffentlichten Feldlisten auf. Die dokumentierten Felder von ConnectWise PSA umfassen Mitglieder, Kontakte, Unternehmen und Tickets. Autotask PSAumfasst Agenten, Unternehmen, Kontakte und Tickets. Verträge fallen stattdessen unter die Migration benutzerdefinierter Objekte, also in dieselbe Kategorie wie Anlagen und Garantien, und werden über Professional Services anstatt über den Standard-Feldzuordnungsprozess abgewickelt.
Kurz gesagt: Verträge werden nicht standardmäßig in die Ticketmigration einbezogen. Planen Sie sie als separates Projekt ein.
Unternehmens-Kontaktstruktur
Help Desk Migration verschiebt Ticket- und Kontaktdatensätze zwischen PSA-Plattformen und erhält dabei die Unternehmens-Kontakt-Struktur, die die Datensätze jedes Kunden getrennt hält. Die Abstimmung des Abrechnungsstatus wird als separater Schritt von der Verschiebung der zugrunde liegenden Datensätze behandelt. Wenn Ihre Bewertung vom genauen Verhalten der Abrechnungskennzeichnung für Ihr spezifisches Paar abhängt, sollten Sie dies vor der Festlegung des Projektumfangs direkt bestätigen.
Die plattformspezifischen Details finden Sie im Autotask PSA Datenimport
Selbstgemacht, verwaltet oder individuell: So wählen Sie die richtige Migrationslösung für Managed Service Provider
Drei Wege zur Migration des Helpdesks für MSP-Betriebe – welche am besten zu Ihnen passt, hängt mehr von der Anzahl der Kunden als vom Datenvolumen ab:
Migrationsassistent, Selbstbedienung
Ideal für kleine Managed Service Provider (MSPs) mit wenigen Kunden, die ein gut unterstütztes Plattformpaar migrieren möchten, ohne komplizierte clientseitige Zuordnungen vornehmen zu müssen. Sie definieren die Felder, führen eine Testmigration durch, überprüfen diese und führen anschließend die vollständige Migration selbst durch.
Managed Service
Bei den meisten MSP-Projekten ist dies Standard, da die clientbezogene Zuordnung über Dutzende oder Hunderte von Clients hinweg ein Gespräch erfordert und nicht einfach eine Checkliste ausfüllt. Help Desk Migrationbietet Ihnen Managed Migration Service: Wir definieren gemeinsam mit Ihnen den Projektumfang, erstellen die Zuordnung, führen eine Testmigration zur Überprüfung durch und übernehmen anschließend die eigentliche Migration.
Beratung
Für die komplizierteren Fälle: ungewöhnliche Quelldaten, benutzerdefinierte Objekte, mehrere Quellplattformen, die gleichzeitig konsolidiert werden müssen, oder ein Sequenzierungsproblem neben einem separaten clientseitigen Projekt.
Die nativen PSA-Importfunktionen verdienen hier Anerkennung. Die meisten PSA-Plattformen verfügen über ein CSV oder natives Importtool, und für einen sauberen, klar definierten Datensatz aus einer einzigen Quelle ist dieses Tool bestens geeignet. Wo also spielt ein Managed Migration Service seine Stärken aus? Genau dort, wo ein nativer Importer nicht ausgelegt ist: bei der kundenspezifischen Datenzuordnung im großen Stil, beim Abgleich von Abrechnungsdatensätzen über verschiedene Plattformen mit unterschiedlichen Finanzmodellen hinweg und bei der Validierung, die die Daten jedes einzelnen Kunden prüft, anstatt nur eine Stichprobe des Gesamtbestands zu nehmen und diese als gültig zu betrachten.
Stellen Sie sich zwei Managed Service Provider (MSPs) nebeneinander vor. Der eine betreut zwei Kunden und ein überschaubares Ticketaufkommen auf gut dokumentierten Plattformen mit einer nahezu 1:1-Zuordnung. Self-Service ist hier eine gute Lösung. Der andere betreut 50 Kunden, und seine Gesamtzahl an Datensätzen mag auf dem Papier geringer erscheinen als die des MSPs mit zwei Kunden. Das ist jedoch irrelevant. 50 Kunden bedeuten 50 Zuordnungen und 50 Validierungen, da der Aufwand mit der Kundenzahl skaliert, nicht mit der Anzahl der Datensätze, und sich nicht – anders als bei einer Migration von einem einzelnen Mandanten – mit sinkendem Ticketaufkommen verringert.
Keine API in Ihrer Quelle? Das verändert die Abgrenzung des Projektumfangs von Anfang an. Ältere oder stark angepasste PSA-Systeme exportieren teilweise nur per CSV, was zwar funktioniert, aber den Anteil der automatisierbaren Projektschritte im Vergleich zur manuellen Zuordnung beeinflusst.
Eine plattformspezifische Version davon sind Halo Service Solutions die Migration und ConnectWise zu Freshdesk die Migration , die zwei der Paare abdecken, zwischen denen MSPs am häufigsten wechseln.
Umstellung ohne sichtbare Versorgungslücke
Bei der Umstellung wird die Migration des Helpdesks für MSP-Betriebe konkret: Sie können kein Wartungsfenster einlegen, das Ihre Kunden bemerken würden.
Diese eine Einschränkung ist der Grund, warum die Umstellung eher wie ein paralleler Vorgang als wie ein einzelner Schalterumschalter aussieht: Beide Plattformen bleiben nach der Hauptmigration noch eine Weile aktiv, und eine Delta-Migration verschiebt alles, was in diesem Zeitraum erstellt oder aktualisiert wird: neue Tickets, Antworten, Zeiteinträge, bevor die Quelle endgültig außer Betrieb genommen wird.
Der gleichzeitige Betrieb zweier Plattformen hat eine Konsequenz, die bewusst eingeplant werden sollte: Agenten bearbeiten Tickets während der Übergangszeit auf beiden Systemen, und es muss ein Nummerierungsschema verwendet werden, das auf beiden Systemen sinnvoll ist. Diese Entscheidung muss im Vorfeld getroffen werden und darf nicht erst am Umstellungstag geklärt werden.
Es handelt sich konkret um zwei Entscheidungen, die beide vor Beginn der Umstellung getroffen werden sollen
Zunächst zur Ticketnummerierung: Kann die Zielplattform die Nummerierung der Quellplattform beibehalten oder beginnt sie mit einer eigenen Nummerierung?
Das hängt ganz davon ab, wohin Sie wechseln. Autotask PSAlistet in seinen dokumentierten Ticketfeldern sowohl die ID als auch die Ticketnummer als separate Felder auf, sodass die Quellnummer irgendwo gespeichert werden kann. ConnectWise PSA hingegen listet in seinen dokumentierten Feldern zwar die ID auf, aber kein separates Feld für die Ticketnummer. Das bedeutet, dass die Ticketnummer als Wert übergeben wird und nicht unbedingt der ConnectWise-eigenen Nummerierungsfolge entspricht. Wenn Ihre Kunden auf Ticketnummern achten, sollten Sie dies speziell für Ihre Zielplattform überprüfen, bevor Sie das Projekt planen. Die Plattform, die Sie verlassen, ist kein verlässlicher Indikator für die Plattform, zu der Sie wechseln.
Zweitens: Wann erfolgt die Umstellung des Kundenportals? Das klingt nach einer kleineren Frage mit weitreichenderen Folgen. Kunden haben die URL als Lesezeichen gespeichert und sich unzählige Male darüber eingeloggt. Die Umstellung erst im Nachhinein zu planen, nachdem die Daten bereits migriert sind, führt dazu, dass eine technisch einwandfreie Migration zu einer schlechten Kundenerfahrung wird.
Eine PSA-Migration ohne Ausfallzeiten ist unmöglich, und wer etwas anderes behauptet, will Ihnen etwas verkaufen, anstatt es zu beschreiben. Erfahrungsgemäß ist für den Kunden ein nahezu unsichtbarer Effekt kaum spürbar. Wie nah man dem kommt, hängt von der Kundenanzahl, der Portalkonfiguration und der Ticketnummerierung der Zielplattform ab. Ein Help Desk MigrationProvider (MSP), dessen Kunden ihre Anfragen ausschließlich per E-Mail einreichen, hat in der Regel einen einfacheren Umstieg als einer mit einem stark frequentierten Kundenportal. Ein System weniger, das im laufenden Betrieb umgestellt werden muss, bedeutet weniger potenzielle Fehlerquellen.
Vereinbaren Sie ein Beratungsgespräch zur Migrationsplanung →
Was eine MSP-Migration tatsächlich kostet und wie lange sie dauert
Die Preisgestaltung für die Datenmigration bei Managed Service Providern (MSPs) unterscheidet sich von der bei Projekten mit einem einzelnen Mandanten. Die erste Frage lautet jedoch immer gleich: Was wird das kosten und wie lange dauert es, bis ich fertig bin? Eine berechtigte Frage. Folgende Faktoren beeinflussen die Kosten:
Die Anzahl der Kunden ist der entscheidende Faktor, der ein MSP-Projekt von einem Projekt mit einem einzelnen Mandanten unterscheidet und oft einen größeren Einfluss auf Kosten und Zeitplan hat als das reine Datensatzvolumen. Eine Migration mit geringem Volumen, verteilt auf 40 Kunden, kann letztendlich teurer und zeitaufwändiger sein als eine Migration mit hohem Volumen für ein einzelnes Unternehmen, da Mapping und Validierung mit der Kundenanzahl, nicht mit der Zeilenanzahl skalieren. Zeiterfassung und Vertragstiefe verstärken diesen Effekt: Ein PSA mit mehreren Vertragstypen und detaillierten Abrechnungsregeln pro Kunde benötigt unabhängig vom Ticketvolumen mehr Zeit für das Mapping als ein PSA mit einer einfachen, flachen Struktur.
Ob Ihre Datenquelle über eine API verfügt, beeinflusst Kosten und Zeitrahmen direkt. API-Zugriff bedeutet in der Regel einen stärker automatisierten Prozess. CSV-basierte oder stark angepasste Datenquellen erfordern meist einen höheren manuellen Aufwand vor Beginn der Migration. Die Preise von Help Desk Migrationberücksichtigen diese Variablen und basieren nicht auf einem festen Betrag pro Datensatz.
Statt im Kreis zu reden, sollten wir uns an konkreten Zahlen orientieren. Help Desk Migration richten sich nach der Anzahl der Datensätze, und zwar nicht linear: Je mehr Datensätze migriert werden, desto weniger zahlt man pro Datensatz. Im Standard-Tarif ohne Anpassungen Die Preise kostet die Migration von 1.000 Datensätzen 100 US-Dollar . Eine Migration von 10.000 Datensätzen kostet 514 US-Dollar . Die Berechnungsmethode begünstigt große Datenmengen, weshalb 40 kleine Migrationen pro Kunde nicht die gleichen wirtschaftlichen Vorteile bieten wie eine große Migration für einen einzelnen Mandanten.
Die Servicepakete skalieren mit der Komplexität: Standard umfasst eine einmalige Hard-Switch-Migration, Premium bewältigt bis zu 50.000 Datensätze mit dediziertem Support, und Signature und Enterprise bieten zusätzlich Delta-Migration, Intervall-Migration, Multi-Thread-Migration und ein dediziertes Account-Team für größere Projekte mit mehreren Mandanten.
Nichts davon ersetzt ein konkretes Angebot. Help Desk Migration erstellt erst dann einen verbindlichen Preis, nachdem eine kostenlose Demo-Migration Ihren tatsächlichen Bedarf ermittelt hat.
Schätzen Sie Ihre Migrationskosten zunächst anhand Ihrer Kundenzahl und Plattformen, insbesondere wenn Sie ein kleinerer Managed Service Provider (MSP) sind, für den Self-Service möglicherweise die richtige Lösung ist. Bei einer größeren Kundenzahl oder komplexeren Migration liefert ein ausführliches Beratungsgespräch deutlich bessere Ergebnisse als eine rein volumenbasierte Schätzung.
Zwei Managed Service Provider, zwei Migrationen, zwei wahre Geschichten
Zwei reale MSP-PSA-Migrationsgeschichten verdeutlichen dies besser als jedes Versprechen.
VestaTech wechselt zu ConnectWise PSA
VestaTech, ein IT- und Sicherheitsdienstleistungsunternehmen aus Ardooie, Belgien, das zur Vestagroup gehört, musste rund 2.000 Tickets, Kundendaten und zugehörige Aktivitätsdatensätze von Freshservice auf ConnectWise PSA migrieren. Vor der Migration nutzte das Team ein selbstentwickeltes Exportskript und hatte den manuellen Import aufgrund des hohen Aufwands bei diesem Datenvolumen bereits verworfen. Der erste Testlauf deckte einige kleinere Fehler auf, die VestaTech und der Support vor der vollständigen Migration behoben. Nach Auswertung der Testergebnisse stellte VestaTech fest, dass keine andere Option vergleichbar war. Die Migration von VestaTech zu ConnectWise ist ein hervorragendes Beispiel für Dienstleistungsunternehmen, die vollständig auf PSA umsteigen. Sie demonstriert einen direkten Plattformwechsel anstelle einer Zusammenführung – ein Unterschied, der für den nächsten Bericht relevant ist.
ROIcode, Zusammenführung zweier Supportinstanzen zu einer
ROIcode, ein IT-Dienstleistungsunternehmen mit Sitz in Denver, Colorado, musste zwei separate Helpdesk-Systeme, Kayako Classic und Zendesk, in einem einzigen cloudbasierten Kayako -Konto zusammenführen, anstatt eines der Systeme komplett abzuschalten. Die Kontozusammenführung in Kayakokonsolidierte beide Helpdesk-Quellen in einer einzigen Instanz und bewahrte dabei die gesamte Supporthistorie des Unternehmens. Falls Ihr Team nach einer Übernahme Konten zusammenführen muss, anstatt die Plattform komplett zu wechseln, zeigt Ihnen diese Fallstudie, wie Sie diesen Prozess reibungslos durchführen.
Dokumentierte Migrationspfade vs. Kundenergebnisse
Neben den namentlich genannten Kundenberichten Help Desk Migration Migrationspfade für die PSA- und RMM-Plattformen dokumentiert und abgebildet, auf die MSPs am häufigsten zurückgreifen: SuperOps, Syncround Atera, sowie Schritt-für-Schritt-Anleitungen für ConnectWise Migrationen, Autotask PSA Migrationen, die SuperOps -Checkliste für die Datenmigrationund die Halo Service Solutions -Checkliste für die Datenmigration.
Es ist wichtig, die Bedeutung dieser beiden Nachweisarten genau zu definieren, denn Managed Service Provider (MSPs), die einen Anbieter evaluieren, bemerken, wenn die Unterscheidung verschwimmt. Eine Kundenreferenz, beispielsweise von VestaTech oder ROIcode, beschreibt ein Ergebnis: ein Unternehmen, eine Migration, ein Resultat – einmalig dokumentiert und nicht weiter verallgemeinert. Ein dokumentierter Migrationspfad ist etwas anderes. Er zeigt an, Help Desk Migration das jeweilige Plattformpaar unterstützt und bereits eine entsprechende Zuordnung existiert, nicht aber, dass tatsächlich ein Projekt bestimmter Größe oder Komplexität darauf ausgeführt wurde. Beide sind wichtig. Keine ersetzt die andere, und Seiten, die sie als austauschbar darstellen, sollten mit Vorsicht genossen werden.
Skalierbarkeit ist die andere Hälfte der Vertrauensfrage. Help Desk Migration hat über 60.000 Migrationen abgeschlossen, unterstützt mehr als 100 Plattformen und ist nach SOC 2 Typ II und SOC 3 zertifiziert. Das ersetzt jedoch nicht die Erfolgsgeschichten von VestaTech oder ROIcode. Es bestätigt lediglich, dass die gleiche Sorgfalt, die beide Unternehmen an den Tag gelegt haben, auch in großem Umfang verfügbar ist und nicht nur einmalig.
Bevor Sie das genauer untersuchen, beginnen Sie hier
Für einen Managed Service Provider (MSP) sollte die Migration clientweise erfolgen, nicht als ein einziger großer Datensatz.
Bevor Sie die Umstellung endgültig beschließen, führen Sie für jeden Kunden dieselben fünf Prüfungen durch:
Verwenden Sie nicht einfach ein und dasselbe Mapping für alle Kunden, ohne die Unterschiede zu prüfen. Ein Kunde mit geringem Auftragsvolumen, einer anderen Unternehmensstruktur oder anderen benutzerdefinierten Feldern benötigt möglicherweise ein anderes Mapping als ein deutlich größerer Kunde.
Halo Service Solutions Die Checklisten SuperOps für die Datenmigration Help Desk Migrationvon und folgen derselben Struktur: Verbinden, Konfigurieren, Auswählen, Zuordnen und Testen. Nutzen Sie dieses Format als Ausgangspunkt für Ihre eigene, clientbezogene Migrationscheckliste.
Die Regel ist einfach: ein Kunde, eine Mapping-Überprüfung, eine Validierung vor der Umstellung.
Häufig gestellte Fragen
Ein Helpdesk eines Managed Service Providers (MSP) ist die Ticketing- und Service-Desk-Ebene innerhalb eines PSA (Provider Service Agreement) oder gelegentlich ein eigenständiges Tool, mit dem Techniker Anfragen für viele verschiedene Kundenorganisationen zentral erfassen, weiterleiten und bearbeiten können. Er ist typischerweise in die Abrechnungs-, Vertrags- und Anlagenverwaltung integriert und fungiert nicht als eigenständiges Support-Tool. Vergleichen Sie ITSM-Software für MSPs, wenn Sie eine auswählen oder Ihre Entscheidung überdenken.
Managed Service Provider (MSP) ist ein Geschäftsmodell: Ein Unternehmen, das die IT für andere Unternehmen vertraglich übernimmt. Professional Services Automation (PSA) ist eine Softwarekategorie: Eine Plattform zur Automatisierung professioneller Dienstleistungen, die diese Geschäftsprozesse unterstützt und Tickets, Zeiterfassung, Verträge und Abrechnung zentral verwaltet. Die meisten MSPs nutzen eine PSA anstelle eines herkömmlichen Helpdesks, da eine PSA eine Finanzebene bietet, die ein Helpdesk nicht hat. Ein typisches Beispiel für diese Kategorie ist ConnectWise -Migration
Für einen Managed Service Provider (MSP) fungiert die PSA als Betriebssystem für die Kundenbearbeitung. Tickets, Zeiteinträge, Verträge und Abrechnungen werden einem bestimmten Kunden, Standort oder Kontakt zugeordnet, oft auch in Verbindung mit RMM-Daten. Ein Helpdesk hört mit der Bearbeitung eines Tickets auf. Eine PSA hingegen erfasst weiterhin die geleisteten Stunden und erstellt Rechnungen. Ein praktisches Beispiel für diese Struktur finden Sie in Autotask PSA .
Verschiedene Quellen unterteilen dies unterschiedlich, aber die meisten Frameworks gliedern die Datenmigration in Speichermigration, database , Anwendungsmigration und Geschäftsprozessmigration – ein Modell, das für Infrastruktur und nicht speziell für PSA- oder Ticketdatensätze entwickelt wurde. Falls Sie tatsächlich danach gesucht haben, die Help Desk MigrationFunktionsweise der den Datensatz-basierten Ansatz, der für Service-Desk-Daten gilt.
Es gibt kein allgemein bestes Tool. Die Wahl hängt von den beteiligten Plattformen ab, davon, ob die Quellplattform über eine API verfügt und wie viel der Migration eine benutzerdefinierte Zuordnung oder einen einfachen Feldabgleich erfordert. Vergleichen Sie insbesondere bei PSA- und Helpdesk-Daten Help Desk Migrationvon die Migrationsdienste mit dem nativen Importtool Ihrer Quellplattform, bevor Sie eine Entscheidung treffen.
Die beste Lösung hängt von Ihrer Kundenzahl, Ihren Anforderungen an integrierte Abrechnung und Zeiterfassung sowie dem Umfang Ihrer Integrationen ab. Einige Managed Service Provider (MSPs) nutzen eine dedizierte PSA-Lösung, ConnectWise oder Autotask. Andere setzen auf einen schlankeren Helpdesk mit separater Abrechnung. Vergleichen Sie Helpdesk- und ITSM-Optionen speziell für MSPs, bevor Sie eine umfassende PSA-Lösung als einzigen Weg in Betracht ziehen.
Neben der PSA selbst umfasst Ihr Tool-Stack üblicherweise RMM-Software für Fernüberwachung und -verwaltung, eine Dokumentationsplattform und gegebenenfalls ein separates Ticketsystem. Beispiele für PSA- und RMM-Lösungen von Managed Service Providern (MSPs) sind ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOneund SherpaDesksowie speziell für MSPs entwickelte ITSM-Tools wie ManageEngine ServiceeDesk Plus MSP. Eine neuere Komplettlösung finden Sie unter SuperOps Konkurrenten
Ein CRM-System erfasst Vertriebspipeline, Kontakte und Abschlüsse. Ein PSA-System hingegen dokumentiert die Serviceleistungen: Tickets, Zeitaufwand, Verträge und Abrechnungen für Bestandskunden, nicht für Interessenten. Manche Plattformen kombinieren beides, doch für einen Managed Service Provider (MSP) ist das PSA-System üblicherweise das zentrale System für Serviceleistungen, während ein CRM-System – sofern überhaupt eines verwendet wird – sich auf Neukundengewinnung konzentriert. Erfahren Sie, wie ConnectWise diese Daten strukturiert.
„MSP in der Cloud“ bezeichnet üblicherweise einen Managed Service Provider, der die Cloud-Infrastruktur eines Kunden verwaltet oder den Umzug eines Kunden zu Cloud-Diensten wie Microsoft 365 übernimmt. Dies ist ein anderes Projekt als das, das auf dieser Seite behandelt wird: die Migration eigener PSA- und Service-Desk-Daten anstelle der Cloud-Umgebung eines Kunden. Die plattformseitige Variante dieser Frage erfahren Sie unter „Warum MSPs die Plattform wechseln“
Gängige Frameworks listen Rehosting, Replatforming, Repurchase, Refactoring, Retiring, Retaining und Relocating auf – ein Modell, das für die Migration von Infrastruktur und Anwendungen entwickelt wurde, nicht jedoch für PSA- oder Ticketdaten. Falls Sie über eine Suche nach Cloud-Migrationen hierher gelangt sind, informieren Sie sich über den Migrationsprozess auf Datensatzebene, der für Service-Desk- und PSA-Daten gilt.