Salesforce-Release-Termine: Was die IT je Release prüft
Salesforce spielt dreimal im Jahr ein großes Release ein, und den Zeitpunkt bestimmen Sie nicht selbst. Salesforce plant die Releases für Februar, Juni und Oktober, je nach Instanz beginnen die Produktions-Upgrades schon im Monat davor. Der Release Schedule gibt der IT-Leitung damit den Takt für sechs Prüfungen vor: Release Notes, Release Updates, Regressionstest in einer Preview-Sandbox, Schnittstellen und installierte Pakete, Kommunikation an den Fachbereich und eine Kontrolle nach dem Upgrade. Dieser Artikel zeigt den Ablauf am Beispiel von Winter ’27, was jede Prüfung liefern sollte und welche Termine für Spring ’27 jetzt zu planen sind.
Wie läuft ein Salesforce-Release ab?
Laut Salesforce-FAQ zum Release-Zeitplan1 kommen neue Funktionen dreimal im Jahr mit den Releases Spring, Summer und Winter. Salesforce legt die Upgrades in Wartungsfenster je Instanz, in der Regel zu lastarmen Zeiten und am Wochenende. Den Wartungsplan veröffentlicht Salesforce ein Jahr im Voraus.
Der Ablauf ist bei jedem Release ähnlich, Termine und Vorlaufzeiten schwanken aber. Bei Winter ’27 sah er laut Admin-Blog von Salesforce2 so aus:
- Anmeldung für Pre-Release-Orgs
- Release Notes veröffentlicht
- Stichtag für Sandbox-Refresh
- Sandbox Preview beginnt
- Erste Produktionsinstanzen, weitere am 2. und 9. Oktober
Zwischen den Release Notes und dem letzten Produktionstermin lagen also rund sieben Wochen, bei den ersten Instanzen nur gut zwei. Wer erst nach dem eigenen Produktionstermin liest, was sich ändert, hat keinen Puffer mehr.
Mit einer Preview-Sandbox die Konfiguration für das nächste Release testen
Salesforce bietet mehrere Wege, ein Release früh zu sehen, und sie haben verschiedene Aufgaben. Entscheidend ist, ob Ihre eigene Konfiguration auf dem neuen Release läuft.
Drei Umgebungen rund um ein Salesforce-Release
Welches Release eine Sandbox erhält, hängt an ihrer Instanz. Laut Hinweisen zur Sandbox Preview3 erhalten Sandboxes auf Preview-Instanzen das Upgrade vorab, bei Winter ’27 am 28. und 29. August. Sandboxes auf anderen Instanzen bleiben zunächst auf dem bisherigen Release und werden zusammen mit der Produktion aktualisiert. Auch Ihre Produktionsorg liegt auf einer Instanz mit eigenem Termin, zu finden im Wartungskalender auf Salesforce Trust.
Prüfen Sie deshalb zuerst im Setup den Release Type jeder Sandbox. Oft ist gar kein Refresh nötig. Wenn doch, muss er vor dem Stichtag abgeschlossen sein, nicht nur gestartet, und er ersetzt den bisherigen Inhalt der Sandbox. Sichern Sie Daten und Konfiguration, die nur dort liegen, also vorher. Mindestens eine Sandbox sollte auf der Preview liegen. Wenn Entwicklung oder Hotfixes gegen die Produktion weiterlaufen müssen, planen Sie eine zweite auf dem aktuellen Release.
Wenn Partner für Sie entwickeln, gehört in die Vereinbarung, wer die Tests in der Preview-Sandbox übernimmt und bis wann Ergebnisse vorliegen. Ohne klaren Verantwortlichen und Termin bleiben Tests unvollständig oder werden von mehreren Partnern doppelt gemacht.
Welche Prüfungen sollte die IT-Leitung je Release verlangen?
Jede Prüfung braucht einen Verantwortlichen, einen Termin und ein Ergebnis, das die IT-Leitung einfordern kann:
Sechs Prüfungen je Release
Bei den Release Notes hilft ein Filter nach den Produkten, die die Org wirklich nutzt. Markieren Sie dann drei Arten von Änderungen: was Nutzer sehen, was eigene Anpassungen brechen kann und was abgeschaltet wird. Ein Beispiel für die Pipeline zeigt Salesforce Winter ’27: Was sich für Ihre Pipeline ändert.
Release Updates im Setup zeigen Änderungen der Plattform, bei denen Sie möglicherweise handeln müssen, bevor Salesforce sie verbindlich aktiviert. Prüfen Sie den Status und die Frist, bis zu der die Schritte erledigt sein müssen, und nutzen Sie den Testlauf in einer Sandbox, wo Salesforce einen anbietet. Termine können sich verschieben, schauen Sie also kurz vor der Produktion noch einmal nach.
Beim Regressionstest zählen die Prozesse, mit denen das Unternehmen Geld verdient oder Kunden bedient. Bei Herstellern sind das meist Ketten über mehrere Systeme: vom Angebot bis zum Auftrag im ERP, von der installierten Basis über den Servicefall bis zum Arbeitsauftrag, Ersatzteile mit Verfügbarkeitsprüfung und die Techniker-App, die auch offline funktionieren muss. Halten Sie die Testfälle von Release zu Release fest, damit der nächste Durchlauf schneller geht. Automatisierte Tests für die wichtigsten Abläufe lohnen sich hier besonders, weil sie dreimal im Jahr gegen ein Release laufen, das Sie nicht selbst gebaut haben. Für die mobile App im Außendienst gilt ein eigener Takt, den ich in Field Service App Updates testen beschreibe.
Bei den Schnittstellen prüfen Sie API-Versionen, Anmeldungen, Connected Apps und installierte Pakete, zusammen mit den Verantwortlichen der Systeme auf der anderen Seite und den Paketanbietern.
Für die Kommunikation reicht selten eine weitergeleitete Mail von Salesforce. Was der Fachbereich wissen muss, beschreibe ich in Salesforce-Releases an den Fachbereich kommunizieren.
Salesforce-Releases brauchen einen eigenen Pfad in der Release-Steuerung
Die Releases von Salesforce gehören in Ihre Release-Steuerung, brauchen dort aber einen eigenen Pfad: Den Termin legt Salesforce fest, und Ihr Team kann das Upgrade der Plattform weder stoppen noch zurückrollen. In einem Programm habe ich den Release-Prozess aufgebaut. Anfangs lief jeder Pull Request über meinen Schreibtisch. Als der Prozess stabil lief, habe ich ihn an einen internen Kollegen übergeben.
Dasselbe Prinzip trägt auch bei den Salesforce-Releases: Verantwortliche, Termine und Entscheidungspunkte verhindern, dass alle vier Monate kurzfristig ein Sonderfall organisiert werden muss. Tragen Sie die drei Releases als feste Termine in die Release-Planung ein. Halten Sie riskante eigene Deployments aus dem Upgrade-Wochenende und dem Test danach heraus, und halten Sie vor dem Upgrade einen Ausgangsstand fest. Dann lassen sich Änderungen vergleichen und mögliche Ursachen eingrenzen, wenn etwas ausfällt. Die DORA-Metriken für Salesforce helfen, Durchsatz und Instabilität der eigenen Auslieferung über die Zeit zu messen. Wie ich Release-Prozesse mit Kunden aufbaue, steht unter DevOps und Release-Management.
Spring ’27: Preview am 8. Januar, Produktion ab 16. Januar
Stand 6. November 2026 nennt der Sandbox Preview Guide von Salesforce4 den 8. Januar 2027 als Start der Preview für Spring ’27. Der Wartungskalender auf Trust5 nennt drei Produktionswochenenden.
- Sandbox Preview beginnt
- Erste Produktionsinstanzen
- Zweites Produktionswochenende
- Drittes Produktionswochenende
Die erste Welle braucht die früheste Vorbereitung: Orgs mit Upgrade am 16. Januar haben zwischen dem Start der Preview und der Produktion nur acht Tage, und die liegen direkt nach den Weihnachtsferien. Den Termin der Release Notes und den Stichtag für den Sandbox-Refresh hat Salesforce noch nicht angekündigt.
Welches der drei Wochenenden für Ihre Org gilt, finden Sie in zwei Schritten heraus. Zuerst steht die Instanz im Setup unter Unternehmensinformationen:
Dann öffnen Sie diese Instanz auf Salesforce Trust5 und wechseln auf den Reiter Wartungsvorgänge. Dort steht jedes große Release mit Datum:
Im Beispiel liegt die Org auf DEU90 in der letzten Welle und erhält Spring ’27 am 20. Februar. Für die Release-Planung zählt dieser Termin, nicht das erste Produktionswochenende.
Den Sandbox-Plan für Spring ’27 im Dezember festlegen
Schauen Sie zuerst im Setup nach, auf welcher Instanz Ihre Produktion liegt, und auf Trust, wann diese Instanz das Upgrade erhält. Dann wissen Sie, ob Sie zur Januar-Welle gehören. Legen Sie dann im Dezember fest, welche Sandbox auf die Preview für Spring ’27 geht und welche auf dem aktuellen Release bleibt. Prüfen Sie den Release Type jeder Sandbox im Setup, bestätigen Sie im Sandbox Preview Guide die empfohlene Aktion für ihre Instanz und planen Sie einen Refresh nur dort, wo er nötig ist. Benennen Sie für jede der sechs Prüfungen einen Verantwortlichen und tragen Sie die Termine in den Kalender des Teams ein, sobald Salesforce die Release Notes ankündigt.
Quellen5
- 1Salesforce-FAQ zum Release-Zeitplan (öffnet in einem neuen Tab)help.salesforce.com
- 2Admin-Blog von Salesforce (öffnet in einem neuen Tab)admin.salesforce.com
- 3Hinweisen zur Sandbox Preview (öffnet in einem neuen Tab)help.salesforce.com
- 4Sandbox Preview Guide von Salesforce (öffnet in einem neuen Tab)sandbox-preview-prd-24f76e67b11e.herokuapp.com
- 5Wartungskalender auf Trust (öffnet in einem neuen Tab)status.salesforce.com
Häufig gestellte Fragen
Wie oft gibt es ein Salesforce-Release?
Dreimal im Jahr. Salesforce plant die Releases für Februar, Juni und Oktober. Je nach Instanz beginnen die Produktions-Upgrades schon im Januar, Mai oder September.
Wann erscheinen die Salesforce Release Notes?
Salesforce kündigt den Termin für jedes Release einzeln an. Bei Winter '27 erschienen die Release Notes am 19. August 2026, 16 Tage vor dem ersten Produktionswochenende am 4. September.
Was ist die Salesforce Sandbox Preview?
Sandboxes auf Preview-Instanzen erhalten das neue Release vor der Produktion, laut Salesforce meist vier bis fünf Wochen vor dem Release. So können Sie prüfen, wie sich das neue Release auf Ihre Konfiguration auswirkt. Ob eine Sandbox die Preview erhält, hängt von ihrer Instanz ab. Prüfen Sie deshalb vor einem Refresh den Release Type im Setup.
Wann kommt Salesforce Spring '27?
Die Sandbox Preview beginnt laut Sandbox Preview Guide von Salesforce am 8. Januar 2027. Der Wartungskalender auf Trust nennt drei Produktionswochenenden: 16. Januar, 6. Februar und 20. Februar 2027. Welches gilt, hängt an der Instanz Ihrer Org.