Plesk-Backup rein, produktionsfertiges Git-Repo raus: Docker-Image, Helm-Chart, CI-Pipeline, Smoke-Test. Zum Festpreis, verbindlich online buchbar — bezahlt wird erst, wenn der Smoke-Test grün ist.
Festpreis · keine Beratungsschleife · Ergebnis in deinem Git-Repo
Der gesamte Weg von Plesk zu Kubernetes ist eine Pipeline — kein Beratungsprojekt. Du siehst jeden Schritt als Commit.
Du lädst ein Plesk-Full-Backup hoch und gibst uns Schreibzugriff auf ein Git-Repo (GitHub App, minimale Rechte). Kein SSH-Zugang, kein Server-Login nötig.
PHP-Version, Extensions, Datenbanken, Cronjobs, Domains, .htaccess-Regeln, Schreibpfade — alles wird maschinell aus dem Backup extrahiert und kartiert.
Dockerfile, Container-Image, Helm-Chart, Kubernetes-Manifeste und CI-Pipeline landen als Pull Request in deinem Repo. Uploads → Volume, Sessions → Redis, .htaccess → Webserver-Config.
Die containerisierte Site startet in einer Preview-Umgebung: Startseite, Login, Datenbank, Cronjobs. Erst wenn alles grün ist, wird der PR freigegeben. Merge = Go-Live.
Kein PDF, keine Präsentation — ein lauffähiges GitOps-Repo. So sieht der Pull Request aus, den unsere Pipeline stellt:
Du hostest 20, 50, 200 Kunden-Sites auf Plesk und dein Team verbrennt unabrechenbare Stunden mit Updates, PHP-Umzügen und „die Seite ist langsam"-Tickets. Wir heben die ganze Flotte auf GitOps — danach ist der Betrieb agentenfähig.
„WordPress-Updates über alle 80 Sites" ist danach ein Agent-Task mit Review-Gate — kein Wochenende mehr. Dein Team wächst an Kunden, nicht an Köpfen.
Jede Stunde Plesk-Pflege ist eine Stunde, die kein Kunde bezahlt. Nach der Migration macht dein Team wieder Projektarbeit — die Routine läuft als Pull Request.
Agenten arbeiten ausschließlich PR-basiert: CI baut, Smoke-Test prüft gegen eine Preview, erst dann wird gemergt und deployt. Kein Agent fasst Produktion direkt an.
Kein „Preis auf Anfrage". Was auf Plesk läuft, ist so standardisiert, dass wir es zum Festpreis migrieren — die Varianz steckt in der Anzahl, nicht in der App.
150 € je Postfach: IMAP-Sync des kompletten Bestands zu deinem Mail-Provider + fertige MX-, SPF-, DKIM- und DMARC-Records. Kubernetes hostet keine Mails — dein Provider schon.
Preise netto zzgl. USt. Zahlung: 50 % bei Beauftragung, 50 % nach grünem Smoke-Test. Schlägt die Migration einer Site fehl, entfällt der volle Preis dieser Site — Garantie.
Festpreise funktionieren nur mit einem sauberen Schnitt. Hier ist er.
Zwei Wege: Entweder du hast einen Dienstleister/eine Cloud, die dir ein Cluster stellt (die Manifeste laufen auf jedem konformen Kubernetes, von managed EKS/GKE/AKS bis k3s) — oder du buchst Agent-Ops dazu und die Sites laufen auf unserer Plattform in Deutschland. Du behältst in beiden Fällen das Repo und damit die volle Portabilität.
Die Analyse erkennt das vor dem Build: ionCube-encodierte Dateien, PHP ≤ 7.4, exotische Apache-Module oder Schreibzugriffe außerhalb erwarteter Pfade werden im Migration-Report markiert. Dann greift das Engineer-Review-Addon — oder du bekommst die klare Ansage, dass es nicht automatisiert geht, bevor Geld fließt.
Konfiguration festlegen, beauftragen, 50 % Anzahlung online zahlen. Danach bekommst du den Upload-Link für das Plesk-Backup und verbindest das Ziel-Repo. Die restlichen 50 % werden erst nach grünem Smoke-Test fällig. Kein Vertriebsgespräch nötig — wer eins will, bekommt es aber.
Eine maschinenlesbare Betriebsanleitung deines Repos: wie gebaut, getestet und deployt wird, was ein Agent darf und was nicht. Damit können KI-Coding-Agenten (Claude Code, Codex & Co.) Routinewartung als Pull Request erledigen — Updates, Dependency-Bumps, Rollbacks. Ohne GitOps-Struktur geht das nicht; genau die liefern wir.
Kubernetes hostet keine Mails — und das ist richtig so. Im Konfigurator buchst du die Mail-Migration je Postfach (150 €): Wir synchronisieren den kompletten Bestand per IMAP zu deinem Mail-Provider (mailbox.org, Google Workspace, Microsoft 365 …), legen Postfächer an, wo die Provider-API es erlaubt, und liefern MX-, SPF-, DKIM- und DMARC-Records fertig zur Umstellung. Der Wechsel passiert im selben DNS-Schwenk wie die Site — es geht keine Mail verloren.
Immer Gateway API, inklusive Implementierung. Das klassische Kubernetes-Ingress-
Objekt ist eingefroren; der offizielle Nachfolger ist die Gateway API. Unsere Basis
ist deshalb eine HTTPRoute — und weil eine Route ohne Controller nichts tut, liegt
der gleich mit im Repo: ohne Mesh-Schalter Envoy Gateway, mit Mesh-Schalter
übernimmt Istio diese Rolle (plus Sidecar, mTLS, Telemetrie). Läuft in deinem
Cluster schon ein Gateway-API-Controller, installieren wir nichts doppelt, sondern
binden per gatewayClassName an den vorhandenen an. Umschalten ist ein
Values-Flip — beim Bestellen oder jederzeit später.
Die Migration läuft komplett parallel zum bestehenden Plesk-Hosting — deine Site bleibt online. Der Umzug selbst ist eine DNS-Umstellung, nachdem die containerisierte Version den Smoke-Test bestanden hat. Für Datenbanken mit laufenden Schreibzugriffen liefern wir einen finalen Delta-Sync-Job mit.
Ausschließlich in Deutschland, DSGVO-konform, mit Auftragsverarbeitungsvertrag. Backups werden nach Abschluss der Migration (oder auf Wunsch sofort) gelöscht — der Löschzeitpunkt steht im Migration-Report.
Weil es keine Beratung ist. Was auf Plesk läuft, ist zu >80 % Standard-PHP mit MySQL — das migriert eine Pipeline, kein Projektteam. Der Mensch kommt nur da rein, wo die Analyse Sonderfälle findet. Deshalb können wir Festpreis und Garantie anbieten, eine Agentur mit Tagessätzen nicht.