Wenn die Telefonie mitten im Arbeitstag kurz weg ist, merkst du sofort, wie viel daran hängt: Support-Anrufe, Sales, Lieferanten, Türsprechanlage, Notfallnummern. Genau deshalb ist eine 3cx migration auf neue version keine „mal schnell updaten“-Aufgabe, sondern ein kleines Projekt mit klaren Schritten. Nicht kompliziert – aber strukturiert.
Der praktische Kern: Du willst die neue Version, weil sie Bugfixes, Security-Patches und oft auch bessere Clients bringt. Gleichzeitig willst du keine Überraschungen bei Routing, Rufnummern, DECT, Apps oder Firewall-Regeln. Und du willst im Zweifel in Minuten zurück, statt in Stunden zu improvisieren.
Was „Migration“ bei 3CX in der Praxis heisst
Bei 3CX ist eine Migration auf eine neue Version meist eine Kombination aus Upgrade und Plattform-Checks. Je nach Ausgangslage ist es ein normales In-Place-Update oder ein Versionssprung, der einen Zwischenschritt braucht. Und manchmal ist es sinnvoller, die PBX neu aufzusetzen und das Backup einzuspielen, statt auf einem über Jahre gewachsenen System alles „drüberzuinstallieren“.
Drei Faktoren bestimmen den Aufwand stärker als die Anzahl User: Wie alt ist die aktuelle Version, wie ist die Anlage gehostet (Cloud, VM, On-Prem), und wie viel „Peripherie“ hängt dran (SBC, DECT-Basis, Türsprechstelle, Fax, CRM-Integration, Sonderrouten, Notfallkonzept).
Vorab klären: Warum updaten wir überhaupt – und was ist dein Ziel?
Ein Update „weil es neu ist“ ist selten ein guter Grund. Gute Gründe sind: Security, Support-Ende der alten Version, Stabilitätsprobleme, ein konkretes Feature (z. B. bessere Mobile-Push-Zuverlässigkeit) oder die Vereinheitlichung der Clients im Team.
Das Ziel sollte messbar sein: „Wir wollen bis Datum X auf Version Y, ohne dass eingehende Anrufe unterbrochen werden, und mit funktionierenden Apps/DECT/Notfallrouting.“ Sobald das klar ist, lässt sich der Rest sauber planen.
Check 1: Version, Lizenz und Plattform – die harten Abhängigkeiten
Bevor du irgendwas klickst: Prüfe, welche Upgrade-Pfade für deine Version überhaupt vorgesehen sind. Bei grossen Sprüngen kann es sein, dass erst auf eine Zwischenversion aktualisiert werden muss. Genauso wichtig: Stimmen Lizenz und Edition noch, und ist das System offiziell unterstützt (OS-Version, VM-Umgebung, Ressourcen)?
Gerade bei kleinen Umgebungen wird der Host oft „nebenbei“ betrieben. Das funktioniert – bis ein Update plötzlich mehr RAM braucht oder ein OS-Paket nicht passt. Ein Upgrade ist der Moment, in dem diese stillen Risiken sichtbar werden. Wenn du hier sauber aufräumst, sparst du dir später die nervigen Geisterfehler.
Check 2: Was hängt an der Telefonanlage?
Viele Teams denken bei 3CX nur an Nebenstellen und Apps. In der Realität hängen oft genau die Teile dran, die man beim Update nicht verlieren darf: SIP-Trunk-Registrierung, Rufnummernplan, Inbound-Routing, Ringruf-Logiken, Bürozeiten, Warteschlangen, Ansagen, Voicemail, Konferenzräume, DECT-Mobilteile, Tischtelefone, SBC für Außenstandorte, Türsprechstellen und manchmal auch Fax oder Alarmgeräte.
Mach daraus eine kurze Bestandsaufnahme. Kein Monster-Dokument – aber so, dass du nach dem Update gezielt testen kannst. Wenn du nur „Telefonieren geht“ prüfst, übersiehst du oft das, was im Alltag wirklich zählt: Weiterleitungen, DTMF in IVR-Menüs, Pickup-Gruppen oder Notfallrouten.
Der wichtigste Schritt: Backup ist nicht gleich Backup
Für eine 3CX-Migration ist das Backup dein Airbag. Es reicht aber nicht, „Backup erfolgreich“ zu sehen.
Du willst drei Dinge sicherstellen:
Erstens: Das Backup enthält wirklich alles, was du brauchst (Konfig, Prompts, Voicemails, FQDN/Cert-Themen je nach Setup). Zweitens: Du weisst, wo es liegt und dass du es im Ernstfall schnell herunterladen kannst. Drittens: Du hast einmal getestet, dass sich dieses Backup auf einem Testsystem oder einer separaten Instanz wiederherstellen lässt.
Das ist der Punkt, an dem viele Updates scheitern: Es gibt ein Backup, aber niemand hat je versucht, es zurückzuspielen. Im Ernstfall wird dann aus „10 Minuten Downtime“ ein halber Tag.
Testen ohne Theater: Eine realistische Testumgebung
Nicht jedes KMU braucht eine perfekt spiegelnde Staging-Umgebung. Aber du brauchst eine Möglichkeit, den Upgrade-Prozess einmal durchzuspielen – idealerweise auf einer Kopie der VM oder einer kleinen Test-Instanz.
Wenn deine 3CX als VM läuft, ist ein VM-Snapshot vor dem Upgrade zusätzlich sinnvoll. Aber wichtig: Snapshot ist kein Ersatz für ein 3CX-Backup. Snapshots sind gut für „schnell zurück“, Backups sind gut für „sauber wiederherstellen“, auch auf anderer Hardware.
In der Testumgebung prüfst du nicht nur, ob die Admin-Konsole startet. Du testest eingehende Anrufe, ausgehende Anrufe, Warteschlangen, Weiterleitungen, DTMF, App-Login, DECT und – wenn vorhanden – den SBC-Standort.
Timing: Update-Fenster, Kommunikation, Erwartungsmanagement
Plane ein Update-Fenster, das zu deinem Geschäft passt. Für viele Start-ups ist das früh morgens oder später am Abend besser als „Freitag 17 Uhr“. Freitag klingt verlockend, ist aber oft die schlechteste Idee, weil du im Problemfall ins Wochenende läufst.
Kommuniziere intern klar: Wann ist das Fenster, was kann kurz nicht funktionieren (z. B. Anrufannahme, App-Login), und was ist der Plan B? Ein kurzer Post im Team-Chat mit Zeitfenster und Verhalten („bei Störung kurz aufs Mobile ausweichen“) verhindert hektische Einzelmeldungen.
Durchführung: So läuft die Migration typischerweise ab
Wenn die Vorarbeit steht, ist die eigentliche Migration oft unspektakulär.
Du startest mit dem finalen Backup und – falls VM – einem Snapshot. Dann führst du das Update gemäss vorgesehenem Pfad aus und beobachtest die Dienste. Danach prüfst du systematisch die Kernfunktionen: Trunk registriert, eingehende/outgoing Calls, Audio in beide Richtungen, DTMF, Routing nach Bürozeiten, Warteschlangen und die wichtigsten Endgeräte.
Wenn du viele Endgeräte hast: Rechne damit, dass nicht jedes Telefon sofort „glücklich“ ist. Manche brauchen ein Reprovisioning, manche holen sich ein Firmware-Update, manche verlieren kurz die Registrierung. Das ist normal – solange du weisst, wie du es sauber wieder einfängst.
Typische Stolpersteine – und wie du sie pragmatisch vermeidest
Der Klassiker ist Audio nur in eine Richtung. Das ist selten „3CX kaputt“, sondern meist NAT/Firewall/SIP-ALG oder geänderte Ports/Regeln nach einem Update. Prüfe, ob SIP-ALG wirklich aus ist und ob die Firewall-Regeln weiterhin exakt zum Setup passen.
Der zweite Klassiker sind Apps und Zertifikate: Wenn FQDN, Zertifikat oder Provisioning-Links nicht mehr stimmen, melden sich Clients neu an oder gar nicht. Plane ein, dass einzelne Nutzer einmal neu scannen oder sich neu anmelden müssen – und dass du dafür eine klare Anleitung hast.
Drittens: DECT und SBC-Außenstandorte. Hier ist das Update oft nicht der Fehler, sondern Timing. Wenn die PBX neu startet, verlieren Außenstandorte kurz die Verbindung und brauchen manchmal einen Neustart oder einen Reconnect. Wenn du mehrere Standorte hast, teste mindestens einen Remote-Standort gezielt.
Viertens: Routing-Logik, die „über die Jahre“ gewachsen ist. Gerade bei KMU gibt es gerne Spezialfälle: VIP-Routing, Umleitungen auf Handy, Nachtklingeln, Notfallnummern. Ein Versionswechsel ist der Moment, um diese Logik einmal kurz zu verifizieren – nicht, um sie gleich komplett neu zu designen. Overengineering kannst du dir sparen. Aber die kritischen Pfade solltest du wirklich testen.
Rollback: Der Teil, den du hoffentlich nie brauchst
Ein Rollback-Plan ist kein Pessimismus, sondern Professionalität. Definiere vorab, wann du zurückrollst. Zum Beispiel: „Wenn Trunk nach X Minuten nicht registriert oder wenn eingehende Calls nicht stabil funktionieren.“
Rollback kann je nach Setup Snapshot-Restore sein oder Restore des 3CX-Backups auf die alte Version/Instanz. Wichtig ist: Der Entscheid muss schnell fallen. Das Ziel ist nicht, im Update-Fenster „noch zwei Stunden zu debuggen“, während das Team nicht erreichbar ist.
Wann lohnt sich eine Neuinstallation statt Upgrade?
Es gibt Fälle, in denen ein In-Place-Upgrade zwar möglich ist, aber nicht die beste Wahl. Wenn das System mehrfach „drübergewachsen“ ist, die OS-Basis alt ist oder du ohnehin auf eine neue VM/Cloud-Umgebung wechseln willst, ist „neu aufsetzen und Backup einspielen“ oft sauberer.
Das kostet am Anfang etwas mehr Disziplin, spart aber später Zeit: klarere Baseline, weniger Altlasten, einfacher Betrieb. Entscheidend ist, dass du die Abhängigkeiten (SBC, Provisioning, Zertifikate, Firewall) von Anfang an mitziehst.
Wenn du es nicht alleine machen willst
Viele Teams können ein 3CX-Update selbst durchführen – solange Setup und Abhängigkeiten überschaubar sind. Wenn aber mehrere Standorte, DECT-Flotten, kritische Erreichbarkeit oder ein enger Zeitplan im Spiel sind, lohnt sich ein Partner, der das schon oft gemacht hat und vor allem den Rollback ernst nimmt.
Bei Connectics ist der Ansatz genau so: keine Buzzwords, keine unnötigen Architektur-Workshops, sondern ein klarer Migrationsplan, ein belastbarer Testkatalog und ein Update-Fenster, in dem am Ende wirklich wieder telefoniert wird.
Nach der Migration: Die 30-Minuten-Nachkontrolle, die Ärger spart
Direkt nach dem Update lohnt sich eine kurze Nachkontrolle im Live-Betrieb. Schau dir Logs und Status an, prüfe stichprobenartig ein paar User, und teste die „Randfälle“, die nachts gerne übersehen werden: Anruf von extern in die Queue, Weiterleitung auf Mobile, IVR-Menü mit DTMF, Voicemail, und falls relevant Notfallrouting.
Wenn alles stabil ist, dokumentiere nur das Nötigste: neue Version, Datum, was angepasst wurde, wo das Backup liegt. Das ist kein Compliance-Theater, sondern macht das nächste Update planbar.
Am Ende ist eine 3CX-Migration kein Hexenwerk – aber sie belohnt Teams, die Klartext sprechen: Was ist kritisch, was kann kurz warten, und wann rollen wir zurück. Wenn du diesen pragmatischen Rahmen setzt, bleibt Telefonie das, was sie sein soll: einfach da, wenn man sie braucht.