Premium WordPress-Wartung · by Frontend GmbH
Wie wird ein Hostingwechsel technisch geplant?
Die Antwort.
Ein Hostingwechsel wird mit Bestandsaufnahme, Zielanforderungen, vollständiger Migration, Tests, DNS-Umschaltung und Rückfallplan technisch geplant. Vor dem Wechsel werden Dateien, Datenbank, E-Mail-Abhängigkeiten, Cronjobs, Zertifikate, Caches und externe Schnittstellen erfasst. Niedrige DNS-TTL, parallele Verfügbarkeit und Nachkontrollen begrenzen das Risiko beim Umschalten.
Wir koordinieren die WordPress-Migration und technische Prüfung mit Ihrem alten und neuen Hoster, sofern Zugänge und Befugnisse vorliegen. Hostingvertrag und Infrastrukturverantwortung verbleiben bei den jeweiligen Anbietern und Ihrem Unternehmen.
Ein Hostingwechsel in kontrollierten Etappen.
Die Migration wird vor der DNS-Umschaltung technisch und fachlich geprüft. So bleibt die alte Umgebung als Rückfalloption verfügbar.
- Bestand, Abhängigkeiten und Zielanforderungen erfassen.
- Dateien, Datenbank, Jobs und Konfiguration übertragen.
- Zielumgebung unter einer Testadresse prüfen.
- Datenänderungen synchronisieren und DNS umstellen.
- Erreichbarkeit, Zertifikat, Formulare und Logs nachkontrollieren.
Diese Abhängigkeiten verursachen die meisten Überraschungen.
Eine WordPress-Seite kann nach der Migration sichtbar funktionieren und trotzdem im Hintergrund unvollständig sein. Deshalb werden nicht nur Seitenaufrufe, sondern zeitgesteuerte und externe Wege geprüft.
- Cronjobs für Importe, Newsletter oder Bereinigung.
- SMTP-Absender, DNS-Authentisierung und Empfängerzustellung.
- Lizenzbindungen an Domain oder Serveradresse.
- Dateipfade, Uploadlimits und Bildverarbeitung.
- Webhooks, Firewallfreigaben und erlaubte Quell-IP-Adressen.
Der alte Hoster hält die Ausgangsumgebung bis zur Abnahme verfügbar. Der neue Hoster verantwortet Zielinfrastruktur; wir koordinieren Anwendungsmigration und Funktionsnachweis innerhalb der vereinbarten Befugnisse.
E-Mail und Domain sind eigene Teilprojekte.
Ein Webhostingwechsel darf MX-Einträge, Absenderauthentisierung oder Registrarzugänge nicht unbeabsichtigt verändern. Zuständigkeiten mit beiden Hostern werden vorab geklärt.
Umschaltstrategie nach Änderungsrate wählen.
Statische oder selten geänderte Websites lassen sich mit kurzer Änderungssperre migrieren. Bei laufenden Bestellungen, Formularen oder Mitgliederaktivität ist eine finale Synchronisation anspruchsvoller.
- Kurze Content-Sperre: einfach und transparent bei geringer Aktivität.
- Differenzsynchronisation: geeignet, wenn Dateien und Daten klar abgleichbar sind.
- Paralleler Betrieb: reduziert Zeitdruck, verlangt aber eindeutige Schreibquelle.
- Wartungsmodus: nur so lang wie nötig und mit verständlicher Information.
- Blue-Green-Ansatz: möglich bei geeigneter Infrastruktur und reproduzierbarem Deployment.
Die Wahl berücksichtigt Datenverlust, Komplexität und Rückfall. Eine komplizierte Null-Downtime-Architektur ist nicht automatisch risikoärmer als ein kurzes geplantes Fenster.
Migrationsabnahme vor und nach DNS.
Der Test vor der Umschaltung beweist Zielbereitschaft; der Test danach zeigt, ob Nutzer und Integrationen tatsächlich den neuen Weg verwenden.
Zur Abnahme gehören ein Test vor und mehrere Kontrollen nach der Umschaltung. Neben sichtbaren Seiten werden Schreibvorgänge, Jobs, Versand und Integrationen geprüft. Zugriffe auf den alten Server zeigen, ob DNS-Caches oder unbekannte Abhängigkeiten fortbestehen. Erst wenn neue Daten eindeutig am Ziel entstehen und der Rückfall nicht mehr benötigt wird, beginnt der geordnete Abbau der Altumgebung.
Ein Migrationsprotokoll hält Quell- und Zielversion, Datenzeitpunkt, DNS-Change und Abnahme fest. Dadurch lassen sich spätere Fehler dem Wechsel zuordnen. Secrets, personenbezogene Rohdaten und vollständige Zugangsdaten gehören nicht in dieses allgemeine Protokoll.
| Aspekt | Einordnung | Konsequenz |
|---|---|---|
| Zeitpunkt | Prüfung | Freigabe |
| Vor Datenkopie | Inventar und Zielanforderungen vollständig | Migrationsowner |
| Nach Erstkopie | Seiten, Admin, Jobs und Logs auf Testadresse | Technik |
| Vor Umschaltung | Finale Daten, Zertifikat und Rückfall bereit | Change-Verantwortlicher |
| Nach DNS | Öffentliche Domain, Formulare und externe Aufrufe | Technik und Fachbereich |
| Nach Beobachtung | Fehlerquote, alte Zugriffe und Datenkonsistenz | Betriebsowner |
Die alte Umgebung bleibt bis zur vereinbarten Abnahme unverändert verfügbar. Neue Daten dürfen nicht unkontrolliert auf beide Systeme verteilt werden.
Verwandte Fragen.
Wie wird Verfügbarkeit technisch gemessen?
Verfügbarkeit wird durch regelmäßige externe Abrufe definierter URLs gemessen und als Anteil erfolgreicher Prüfintervalle über einen festgelegten Zeitraum berechnet.
Wie werden PHP- und Datenbankversionen geplant?
Versionen werden anhand von Supportzeiträumen, Hosterplanung und Kompatibilität der Anwendung geplant.
Wie wird die Zusammenarbeit mit dem Hoster technisch eskaliert?
Die Zusammenarbeit mit dem Hoster wird über dessen vorgesehenen Supportkanal mit Priorität, Zeitstempel, betroffenen Diensten, Logs und bereits erfolgten Tests eskaliert.
Wann sollte die interne IT Premium-WordPress-Wartung beauftragen?
Eine erweiterte WordPress-Wartung ist sinnvoll, wenn WordPress-Spezialwissen, laufende Kapazität oder ein klarer externer Eskalationsweg fehlen und die Website für wichtige Geschäftsprozesse relevant ist.
Ihre Website-Betreuung klären.
Beschreiben Sie uns Ihre Website und Ihr Anliegen. Im Gespräch legen wir fest, welche Betreuung Sie benötigen.