Wie Sie Ihr Salesforce-DevOps-Tool wechseln, ohne die Pipeline zu brechen

Warum Teams den Wechsel hinauszögern (und warum das ein Fehler ist)

Die meisten Salesforce-Teams wissen, dass sie ein besseres DevOps-Tool brauchen, zögern den Wechsel aber hinaus, weil sich die Migration riskant anfühlt. Die Realität: Bei einem Tool zu bleiben, das nicht zum Team passt, ist riskanter. Jeder manuelle Releasezyklus, jeder Produktionsausfall durch ein ungetestetes Change Set, jede Stunde, die in Arbeit fließt, die automatisiert sein sollte - das sind Ihre echten Kosten.

Dieser Leitfaden zeigt, wie Sie sicher das Salesforce-DevOps-Tool wechseln, egal ob Sie von Change Sets, Copado oder Gearset kommen.

Noch unklar, zu welchem Tool Sie wechseln? Unser Vergleich der besten Salesforce DevOps-Tools stellt zehn Plattformen nach Preis, Einsatz und Ansatz nebeneinander.

Bevor Sie starten: die Checkliste vor der Migration

• ✅ Dokumentieren Sie Ihren aktuellen Releaseprozess - wie viele Schritte, wer genehmigt, was führt Tests aus
• ✅ Identifizieren Sie alle verbundenen Orgs (Sandbox, Staging, UAT, Produktion) und ihre Beziehungen zueinander
• ✅ Listen Sie alle aktiven Metadatentypen auf, die deployt werden (Flows, Apex, LWC, Permission Sets usw.)
• ✅ Notieren Sie vorhandene automatisierte Tests und deren Laufhäufigkeit
• ✅ Bestätigen Sie, dass Ihr Git-Repository aktuell ist (falls bereits unter Versionskontrolle)
• ✅ Wählen Sie ein verkehrsarmes Migrationsfenster - vermeiden Sie Monatsende oder Quartalsabschlüsse

Migration von Change Sets

Change Sets sind der häufigste Ausgangspunkt. Die gute Nachricht: Diese Migration ist am saubersten, weil keine bisherige Toolkonfiguration mitgenommen werden muss.

1. Orgs verbinden. Verbinden Sie mit Serpent alle Orgs per OAuth - Produktion, Sandboxes und alle Developer-Orgs. Das dauert 10-15 Minuten.
2. Versionskontrolle initialisieren. Falls Sie kein Git-Repo haben, legen Sie eines an. Serpent verbindet sich direkt mit GitHub, GitLab oder Bitbucket.
3. Metadaten-Snapshot ausführen. Ziehen Sie Ihre aktuellen Produktionsmetadaten als Baseline in die Versionskontrolle. Das ist Ihr Ausgangspunkt.
4. Erste Pipeline bauen. Konfigurieren Sie ein einfaches Deployment von Dev-Sandbox → UAT → Produktion. Führen Sie es einmal mit einer kleinen, sicheren Änderung aus, um die Einrichtung zu verifizieren.
5. Change Sets außer Dienst stellen. Nach 2-3 erfolgreichen automatisierten Deployments hören Sie auf, Change Sets für neue Arbeit zu nutzen. Behalten Sie bestehende genehmigte Change Sets für laufende Arbeit, bis sie abgeschlossen sind.

Zeit bis zur vollständigen Migration: 1-2 Wochen für die meisten Teams.

Migration von Gearset

Gearset-Teams verstehen Pipelines und Versionskontrolle bereits - die Migration besteht vor allem darin, Ihre Pipeline-Definitionen und Org-Verbindungen neu zu konfigurieren. Noch unentschlossen? Unser Vergleich als Gearset-Alternative zeigt, wo sich die beiden Plattformen wirklich unterscheiden.

1. Gearset-Pipelinekonfiguration exportieren. Dokumentieren Sie, welche Orgs mit welchen verbunden sind, welche Metadatenfilter Sie nutzen und welche Tests pro Umgebung verpflichtend sind.
2. Orgs neu verbinden. Nutzen Sie denselben OAuth-Flow, um alle Orgs mit der neuen Plattform zu verbinden. Ihr bestehendes Git-Repo funktioniert unverändert.
3. Pipelines neu erstellen. Ordnen Sie jede Gearset-Pipeline ihrem Äquivalent in Serpent zu. Die meisten Konfigurationen übertragen sich direkt.
4. Einen Sprint lang parallel laufen lassen. Halten Sie Gearset für bestehende Pipelines aktiv, während Sie neue in Serpent bauen und testen. Ein Sprint parallel deckt eventuelle Lücken auf.
5. Umstellen. Nach einem Sprint ohne Probleme in Serpent deaktivieren Sie die Gearset-Pipelines und kündigen das Abonnement.

Zeit bis zur vollständigen Migration: 2-4 Wochen inklusive Parallelbetrieb.

Migration von Copado

Copado-Migrationen sind am komplexesten, weil Copados User Stories und Branchverwaltung tief integriert sind. Der Schlüssel ist, den Prozess zu migrieren, nicht nur das Tooling. Für den Feature-für-Feature-Vergleich lesen Sie zuerst unseren Vergleich als Copado-Alternative.

1. Laufende Arbeit abschließen. Schließen Sie alle aktiven Copado-User-Stories ab, bevor Sie mit der Migration beginnen. Migrieren Sie nicht mitten in einem Sprint.
2. Branchstrategie dokumentieren. Copado-Teams haben typischerweise ein spezifisches Branching-Modell - stellen Sie sicher, dass sich Ihr Team darauf einigt, bevor Sie das Tool wechseln.
3. Org-Verbindungen migrieren. Derselbe OAuth-Prozess wie oben.
4. Pipelinephasen neu aufbauen. Ordnen Sie Copado-Umgebungen den Serpent-Pipelinephasen zu. Die Konzepte sind gleichwertig.
5. Team neu schulen. Copados Oberfläche ist manchen Teammitgliedern sehr vertraut. Planen Sie 2-3 Stunden Team-Onboarding ein.
6. Zwei Sprints lang parallel laufen lassen. Angesichts der höheren Komplexität laufen Sie zwei volle Sprints parallel, bevor Sie umstellen.

Zeit bis zur vollständigen Migration: 4-8 Wochen inklusive Parallelbetrieb und Neuschulung.

Was Sie nicht tun sollten

• ❌ Migrieren Sie nicht während einer Freeze-Periode oder vor einem großen Release
• ❌ Überspringen Sie nicht den Parallel-Sprint - er fängt die Randfälle ab, an die Sie nicht gedacht haben
• ❌ Migrieren Sie nicht alle Orgs auf einmal - beginnen Sie mit einer einzigen Sandbox-Pipeline
• ❌ Vergessen Sie nicht, Ihre CI/CD-Webhooks (GitHub Actions usw.) zu aktualisieren, damit sie auf die neue Plattform zeigen

Wie lange dauert es wirklich?

Von	Realistischer Zeitrahmen	Hauptkomplexität
Change Sets	1-2 Wochen	Die erste Pipeline von Grund auf bauen
Gearset	2-4 Wochen	Pipelinekonfigurationen neu erstellen
Copado	4-8 Wochen	Prozessabstimmung und Team-Neuschulung

FAQ

Wie wechselt man DevOps-Tools, ohne die Pipeline zu brechen?

Migrieren Sie eine Pipeline nach der anderen und lassen Sie altes und neues Tool mindestens einen Sprint lang parallel laufen, bevor Sie umstellen. Beginnen Sie mit einer einzigen Sandbox-Pipeline statt mit allen Orgs auf einmal, und richten Sie dabei Ihre CI/CD-Webhooks neu aus.

Wie lange dauert eine Migration des Salesforce-DevOps-Tools?

Planen Sie etwa ein bis zwei Wochen ab Change Sets, zwei bis vier Wochen ab Gearset und vier bis acht Wochen ab Copado ein. Copado dauert am längsten, weil sich Prozess und Teamgewohnheiten mit dem Tooling mitbewegen, nicht nur die Konfiguration.

Kann man mitten in einem Sprint migrieren?

Besser nicht. Schließen Sie laufende Arbeit zuerst ab und vermeiden Sie Freeze-Perioden, Monatsende und Quartalsabschlüsse. Ein verkehrsarmes Fenster zu wählen bedeutet, dass keine Überraschung zusätzlich zu einem Release landet.

Was sollte man vor dem Wechsel des DevOps-Tools vorbereiten?

Dokumentieren Sie Ihren aktuellen Releaseprozess und wer was genehmigt, listen Sie jede verbundene Org und ihre Beziehungen auf, notieren Sie die Metadatentypen, die Sie deployen, und die Tests, die Sie bereits ausführen, und bestätigen Sie, dass Ihr Git-Repository aktuell ist.

Bereit anzufangen?

Das Migrationsteam von Serpent kann eine kostenlose Migrationsbewertung durchführen - wir bilden Ihre aktuelle Einrichtung auf eine Serpent-Konfiguration ab und geben Ihnen einen realistischen Zeitrahmen, bevor Sie sich auf irgendetwas festlegen. Starten Sie hier Ihre Migration.