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

Warum Teams den Wechsel hinauszogern (und warum das ein Fehler ist)

Die meisten Salesforce-Teams wissen, dass sie ein besseres DevOps-Tool brauchen, zoegern den Wechsel aber hinaus, weil sich die Migration riskant anfuehlt. Die Realitaet: 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 fliesst, 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.

Bevor Sie starten: die Checkliste vor der Migration

• ✅ Dokumentieren Sie Ihren aktuellen Releaseprozess - wie viele Schritte, wer genehmigt, was fuehrt 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 Laufhaeufigkeit
• ✅ Bestaetigen Sie, dass Ihr Git-Repository aktuell ist (falls bereits unter Versionskontrolle)
• ✅ Waehlen Sie ein verkehrsarmes Migrationsfenster - vermeiden Sie Monatsende oder Quartalsabschluesse

Migration von Change Sets

Change Sets sind der haeufigste 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 ausfuehren. 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. Fuehren Sie es einmal mit einer kleinen, sicheren Aenderung aus, um die Einrichtung zu verifizieren.
5. Change Sets ausser Dienst stellen. Nach 2-3 erfolgreichen automatisierten Deployments hoeren Sie auf, Change Sets fuer neue Arbeit zu nutzen. Behalten Sie bestehende genehmigte Change Sets fuer laufende Arbeit, bis sie abgeschlossen sind.

Zeit bis zur vollstaendigen Migration: 1-2 Wochen fuer 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 unveraendert.
3. Pipelines neu erstellen. Ordnen Sie jede Gearset-Pipeline ihrem Aequivalent in Serpent zu. Die meisten Konfigurationen uebertragen sich direkt.
4. Einen Sprint lang parallel laufen lassen. Halten Sie Gearset fuer bestehende Pipelines aktiv, waehrend Sie neue in Serpent bauen und testen. Ein Sprint parallel deckt eventuelle Luecken auf.
5. Umstellen. Nach einem Sprint ohne Probleme in Serpent deaktivieren Sie die Gearset-Pipelines und kuendigen das Abonnement.

Zeit bis zur vollstaendigen Migration: 2-4 Wochen inklusive Parallelbetrieb.

Migration von Copado

Copado-Migrationen sind am komplexesten, weil Copados User Stories und Branchverwaltung tief integriert sind. Der Schluessel ist, den Prozess zu migrieren, nicht nur das Tooling. Fuer den Feature-fuer-Feature-Vergleich lesen Sie zuerst unseren Vergleich als Copado-Alternative.

1. Laufende Arbeit abschliessen. Schliessen 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 Oberflaeche ist manchen Teammitgliedern sehr vertraut. Planen Sie 2-3 Stunden Team-Onboarding ein.
6. Zwei Sprints lang parallel laufen lassen. Angesichts der hoeheren Komplexitaet laufen Sie zwei volle Sprints parallel, bevor Sie umstellen.

Zeit bis zur vollstaendigen Migration: 4-8 Wochen inklusive Parallelbetrieb und Neuschulung.

Was Sie nicht tun sollten

• ❌ Migrieren Sie nicht waehrend einer Freeze-Periode oder vor einem grossen Release
• ❌ Ueberspringen Sie nicht den Parallel-Sprint - er faengt die Randfaelle 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	Hauptkomplexitaet
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 laengsten, weil sich Prozess und Teamgewohnheiten mit dem Tooling mitbewegen, nicht nur die Konfiguration.

Kann man mitten in einem Sprint migrieren?

Besser nicht. Schliessen Sie laufende Arbeit zuerst ab und vermeiden Sie Freeze-Perioden, Monatsende und Quartalsabschluesse. Ein verkehrsarmes Fenster zu waehlen bedeutet, dass keine Ueberraschung zusaetzlich 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 ausfuehren, und bestaetigen Sie, dass Ihr Git-Repository aktuell ist.

Bereit anzufangen?

Das Migrationsteam von Serpent kann eine kostenlose Migrationsbewertung durchfuehren - 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.