ScriptCase-Anwendung auf einen neuen Server umziehen: Checkliste

Kurz gesagt: Eine ScriptCase-Anwendung läuft auf einem neuen Server nur, wenn drei Dinge zusammenpassen: die PHP-Version mit den nötigen Erweiterungen, die ScriptCase-Produktionsumgebung in der Version, mit der generiert wurde, und die Verbindung zur Datenbank. Testen Sie den Umzug vorher auf dem neuen Server mit einer Kopie der Datenbank und schalten Sie erst um, wenn die wichtigsten Arbeitsabläufe funktionieren.

Ein Serverumzug wirkt bei einer generierten Anwendung zunächst einfach: Dateien kopieren, Datenbank kopieren, fertig. In der Praxis scheitert er oft an Details, die auf dem alten Server einmal eingestellt und dann vergessen wurden.

Vor dem Umzug: Bestandsaufnahme

• Welche PHP-Version läuft auf dem alten Server? Ein Aufruf von phpinfo() in einer Testdatei zeigt Version und geladene Erweiterungen. Die Datei danach wieder löschen.
• Mit welcher ScriptCase-Version wurde die Anwendung zuletzt generiert?
• Welche Datenbank (MySQL, MariaDB, PostgreSQL, SQL Server …) in welcher Version wird genutzt?
• Gibt es Zusatzdienste: Cronjobs für Berichte, Mailversand, Dateiablagen für hochgeladene Dokumente, Schnittstellen zu anderen Systemen?
• Liegt die ScriptCase-Projektdatei noch vor, falls neu generiert werden muss?

Checkliste für den neuen Server

1. PHP-Version

Die PHP-Version muss zu der ScriptCase-Version passen, mit der generiert wurde. Ist der neue Server nur mit neuerem PHP verfügbar, muss die Anwendung vorher mit einer aktuellen ScriptCase-Version neu generiert werden. Siehe ScriptCase-Anwendung auf PHP 8 bringen.

2. PHP-Erweiterungen

Vergleichen Sie die Erweiterungen mit dem alten Server. Typisch benötigt werden Datenbanktreiber (z. B. mysqli, pdo_mysql, pgsql oder sqlsrv), mbstring, gd, zip, xml, curl und intl. Welche genau Ihre Version verlangt, steht in der ScriptCase-Dokumentation. Fehlt eine Erweiterung, scheitern oft nur einzelne Funktionen, etwa PDF-Export oder Diagramme, und das fällt erst Tage später auf.

3. PHP-Einstellungen

• max_input_vars: Große Formulare und Rasterbearbeitungen senden viele Felder. Ist der Wert zu klein, gehen Eingaben stillschweigend verloren.
• upload_max_filesize und post_max_size: für Dokument-Uploads.
• memory_limit und max_execution_time: für große Berichte und Exporte.
• Zeitzone (date.timezone): sonst stimmen Zeitstempel nicht.

4. Produktionsumgebung

Generierte Anwendungen brauchen die ScriptCase-Bibliotheken der Produktionsumgebung. Sie müssen zur ScriptCase-Version passen, mit der generiert wurde. Übertragen Sie sie zusammen mit den Anwendungen oder legen Sie sie über das Deployment von ScriptCase neu an.

5. Datenbankverbindung

Die Zugangsdaten zur Datenbank ändern sich beim Umzug fast immer: Server, Benutzer, Passwort, manchmal der Port. Passen Sie die Verbindung in der Produktionsumgebung an. Prüfen Sie auch Zeichensatz und Sortierung der Datenbank, sonst werden Umlaute plötzlich falsch angezeigt.

6. Schreibrechte

Ordner für temporäre Dateien, Uploads und erzeugte Dokumente müssen für den Webserver beschreibbar sein. Nach dem Kopieren per FTP stimmen die Rechte oft nicht.

7. Sicherheit

• HTTPS mit gültigem Zertifikat.
• Verwaltungsbereiche der Produktionsumgebung mit starkem Passwort schützen und, wenn möglich, auf bestimmte IP-Adressen beschränken.
• Fehleranzeige im Produktivbetrieb abschalten.
• Alte Server erst abschalten, wenn der neue mindestens eine Woche stabil läuft, und danach die Daten dort sicher löschen.

Testen vor dem Umschalten

Lassen Sie die Personen testen, die täglich mit der Anwendung arbeiten, nicht nur die IT. Typische Prüfungen: Anmelden, Datensatz anlegen und ändern, Suche, Bericht als PDF, Export nach Excel, Dokument hochladen, E-Mail-Versand. Erst dann den Umzug mit aktueller Datenbank wiederholen und umschalten.

Professionelle Hilfe

Ich ziehe ScriptCase-Anwendungen auf neue Server um, generiere bei Bedarf mit aktueller Version neu und sorge dafür, dass am Tag nach dem Umzug alle normal weiterarbeiten können. Mehr unter ScriptCase-Entwickler.