Die ColdFusion-Migration beginnt vor Lizenzablauf

Die Entscheidung, ColdFusion nicht zu verlängern, setzt eine Frist, ist aber kein Migrationsplan. Die eigentliche Aufgabe besteht darin, jedes Verhalten zu erhalten, auf das Nutzer und angebundene Systeme angewiesen sind, solange die CFML-Laufzeit noch als verlässliche Referenz dient. Wer zuerst Tags in eine andere Sprache überträgt, bildet den unwichtigsten Teil des Systems nach und übersieht Verträge in Datenbankergebnissen, Sitzungszuständen, geplanten Jobs, Dateiablagen und Fehlerbehandlung.

Eine sichere ColdFusion-Migration lässt die bestehende Anwendung weiter Anfragen bedienen, während der Ersatz Routen und Jobs in messbaren Abschnitten übernimmt. Die Reihenfolge zählt: Live-Verhalten erfassen, Anwendungsgrenze festlegen, Datenbanksemantik isolieren, nicht visuelle Einstiegspunkte verlagern und danach Lese- und Schreibzugriffe Route für Route übertragen. Der alte Server verschwindet erst, wenn aufgezeichneter Traffic die Parität belegt und der Rückweg nicht mehr gebraucht wird.

Nichtverlängerung als kaufmännische Grenze behandeln

Die Nichtverlängerung sagt, wann das Unternehmen das Produkt nicht mehr bezahlen will. Sie sagt allein nicht, was ein installierter Server an diesem Tag tut. ColdFusion-Editionen und Lizenzmodelle unterscheiden sich, und Adobe stellte die Version 2025 von Seriennummern auf abonnementbasierte Named User Licensing und Feature Restricted Licensing um. Ältere Installationen können anderen Bedingungen unterliegen. Prüfen Sie Bestellung, Lizenzvertrag, Bereitstellungsnachweise, Supportdaten und Aktivierungsmethode der produktiven Version. Ingenieure dürfen Nutzungsrechte nicht daraus ableiten, ob ein Prozess noch startet.

Führen Sie vier Termine getrennt: Verlängerungsentscheidung, Ende des Herstellersupports, mögliche Aktivierungs- oder Berechtigungsereignisse und den Tag, an dem die Produktion ohne CFML läuft. Sie müssen nicht übereinstimmen. Einkauf oder Rechtsabteilung klären das Nutzungsrecht, der Betrieb testet das Aktivierungsverhalten in einem isolierten Klon. Keine Antwort ersetzt die andere.

Halten Sie die lizenzierte Produktion während des Ausstiegs stabil. Frieren Sie Laufzeit-, JVM- und Treiberwechsel sowie spontane Framework-Aufräumarbeiten ein, sofern keine Sicherheitslage sie erzwingt. Dokumentieren Sie JVM, Konnektoren, Hotfixes, Mappings, Datenquellen, Aufgaben und externe Dienste. Behaupten Sie weder einen Ausfall um Mitternacht noch ewigen Weiterbetrieb. Beides bleibt ohne Vertragsprüfung und Test eine Vermutung.

Verhalten statt Dateiendungen inventarisieren

Eine Zählung von CFM- und CFC-Dateien ist keine Systemkarte. Beginnen Sie bei produktiven Einstiegspunkten und verfolgen Sie, was jeder davon liest, ändert, ausgibt und aufruft. Ein kleines Template kann Includes laden, ein CFC aufrufen, eine Sitzung ändern, SQL ausführen, ein PDF schreiben, E-Mail senden und über einen Fehlerhandler umleiten. Seine Zeilenzahl sagt nichts über das Risiko.

Erstellen Sie ein Routen- und Jobverzeichnis mit einer Zeile pro beobachtbarem Einstiegspunkt. Erfassen Sie HTTP-Methode und Pfad, Authentifizierungszustand, wichtige Eingabefelder, Status und Inhaltstyp der Antwort, geänderte Cookies, gelesene und geschriebene Tabellen, Dateien oder Nachrichten, externe Aufrufe und den fachlichen Prüfer. Nehmen Sie geplante Aufgaben, Remote-CFC-Methoden, Webservices, Dateiimporte, Administrator-Mappings und manuelle Abläufe auf, die nie im Quellcode liegen.

Die unbequemen Abhängigkeiten liegen häufig außerhalb von CFML. ColdFusion Administrator kann Zugangsdaten, Mail-Einstellungen, JVM-Argumente, Sandboxregeln, Custom-Tag-Pfade, Aufgaben und Webserver-Konnektoren enthalten. Application.cfc prägt Anfragen, doch Serverkonfiguration kann die Bedeutung des Codes verändern. Exportieren Sie sie und erstellen Sie zusätzlich eine diffbare Textinventur. Ein Screenshot ist dafür schwach.

Protokollieren Sie echte Nutzung, bevor Sie etwas streichen. Erfassen Sie Routenvorlage, Status, Dauer, Rolle und einen datenschutzgerechten Fingerabdruck. Bei Jobs zählen Beginn, Ende, Ergebnis und Geschäftsartefakt. Eine Seite ohne aktuellen Zugriff kann jährlich laufen. Löschen Sie sie erst, wenn ein Verantwortlicher bestätigt, dass niemand ihr Verhalten nutzt.

Application.cfc zuerst zur Grenze machen

Application.cfc definiert den Lebenszyklus, den der Ersatz nachbilden oder bewusst ändern muss. Lesen Sie onApplicationStart, onSessionStart, onRequestStart, onRequest, onRequestEnd, onError und die Behandlung fehlender Templates als einen Kontrollfluss. Prüfen Sie auch Application.cfm und OnRequestEnd.cfm. Laut Adobe CFML Reference ignoriert ColdFusion diese CFM-Dateien im Anwendungskontext, sobald Application.cfc vorhanden ist. Der Ablageort entscheidet daher, welcher Lebenszyklus läuft.

Ordnen Sie jeden Scope nach Lebensdauer und Besitzer. Application ist gemeinsamer Prozesszustand, session enthält Nutzerzustand, request lebt nur während einer Anfrage, server kann Anwendungen übergreifen und variables hat in Templates und Komponenten verschiedene Bedeutung. Der Ersatz braucht nicht dieselben Namen, muss aber sichtbares Verhalten wie Sitzungsablauf, Sprache, Autorisierung, Korrelation und Referenzdaten erhalten.

Übertragen Sie Prozessspeicher nicht versehentlich über die Migrationsgrenze. Ein in application gespeichertes CFC kann Daten cachen, die ein neuer Dienst bereits ändert. Geben Sie jedem Cache Quelle, Ablaufregel, Invalidierung und Besitzer. Bei Parallelbetrieb ist Abschalten oft sicherer als eine unklare Eigenheit nachzubauen.

Machen Sie Lebenszyklusverhalten vor der Darstellung zu Middleware und Diensten. Authentifizierung, Mandantenermittlung, Transaktionskorrelation, Fehlerzuordnung und Antwortheader gehören an den Rand des Ersatzsystems. Tests verhindern dann, dass eine migrierte Route Regeln umgeht, und der Proxy kann beiden Antworten dieselbe Anfrage-ID geben.

CFCs sind mehrere Verträge mit derselben Endung

Ein CFC kann internes Objekt, Remote-Endpunkt, zustandsbehafteter Singleton oder dünne SQL-Hülle sein. Aus jeder .cfc-Datei eine Klasse zu machen erhält nur die Dateistruktur und verdeckt den öffentlichen Vertrag. Ordnen Sie jede Komponente nach Aufrufern und Zustandsbesitz ein.

Bei Remote-Methoden erfassen Sie Namen, Argumentformen, Standardwerte, Authentifizierungsprüfungen, Serialisierung, HTTP-Status und Fehlerform. CFML-Aufrufer tolerieren oft Großschreibung und flexible Typen, die ein typisierter TypeScript-Handler ablehnt. Ein CFML-Array kann je nach Einstellung als Query mit Spalten und Daten serialisiert werden. Erfassen Sie die Bytes beim echten Aufrufer statt die Debuggeransicht.

Verfolgen Sie bei internen CFCs zuerst die Aufrufstellen. Eine Komponente, die Templates per createObject erzeugen, kann ein Anfragedienst sein. Eine Instanz im application-Scope braucht eventuell Nebenläufigkeitsschutz. Eine remote markierte Methode ohne externen Nutzer darf nicht allein wegen des Quelltexts öffentliche API bleiben.

Definieren Sie Ersatzverträge als klare Anfrage- und Antwort-Fixtures:

{"request":{"method":"GET","path":"/account/orders","sessionRole":"buyer"},"response":{"status":200,"contentType":"text/html; charset=UTF-8","setCookieNames":[],"bodyNormalizers":["csrf-token","generated-at"]}}

Das Fixture schreibt keine Architektur vor. Es benennt Parität und zulässige Abweichungen. Ergänzen Sie negative Fälle für fehlende Sitzungen, fehlerhafte Argumente, doppelte Übermittlung und Timeouts. Auch Fehler haben Verbraucher.

Tag-Suppe vor der Übersetzung trennen

Gemischte CFML-Templates enthalten mindestens Anfragekontrolle, Geschäftsregeln, Datenzugriff und HTML-Ausgabe. Eine mechanische Umschreibung verknüpft dieselben Dinge in einer neuen Sprache. Identifizieren Sie Entscheidungen und Antwortvertrag und implementieren Sie diese hinter der bestehenden Routengrenze.

Eine Seite mit cfparam-Standardwerten, Autorisierungs-Include, zwei cfquery-Blöcken, cfloop, cfoutput-Escaping und Umleitung nach einem Formular hat mehr Vertrag als ihr HTML. Dazu gehören Standardregeln, Redirect-Status, Doppelklickverhalten, Sortierung, Nulldarstellung, Kodierung, Cookies und womöglich ein von einem Client erwarteter Validierungstext. Halten Sie dies vor Änderungen fest.

Verschieben Sie die reine Darstellung innerhalb einer Route zuletzt. Bilden Sie zuerst Anfragemodell und Datenoperationen nach, dann rendern Sie ein stabiles View Model im neuen Client oder Server-Template. So greift eine TypeScript-Oberfläche nicht auf undokumentierte Query-Objekte zurück und HTML lässt sich vergleichen, ohne Geschäftsabweichungen zu verdecken.

Vereinheitlichen Sie während des Ausstiegs nicht jeden Bildschirm. Ein Redesign ändert Navigation, Validierung, Barrierefreiheit und Support auf einmal. Sichtbare neue Seiten wirken wie Fortschritt, helfen aber nicht, wenn die Lizenzfrist bindet. Erhalten Sie die Nutzerreise, entfernen Sie die Laufzeit und verbessern Sie danach mit eigenen Abnahmekriterien.

Das Query-Objekt gehört zum Anwendungsvertrag

ColdFusions Query-Schicht transportiert nicht nur SQL. Adobes Dokumentation beschreibt cfquery als Query-Objekt mit Datensätzen und Eigenschaften wie RecordCount, ColumnList, SQL, Cached, SQLParameters und ExecutionTime. Templates iterieren darüber, behandeln Spalten als Arrays, erwarten Namen ohne Beachtung der Großschreibung, führen Query of Queries aus oder serialisieren das Objekt. Zeilen aus einem PostgreSQL-Treiber bilden dies nicht automatisch nach.

Inventarisieren Sie jede Datenquelle und klassifizieren Sie Abfragen als Lesen, Schreiben, Transaktion, Stored Procedure, Query of Queries, dynamisches SQL oder Cache-Abfrage. Finden Sie fehlendes cfqueryparam, vermischen Sie aber keine breite Sicherheitsüberarbeitung mit Paritätsarbeit, sofern das Risiko es nicht verlangt. Parameter verändern implizite Konvertierungen und Ausführungspläne und brauchen Tests.

Bauen Sie einen Datenbankadapter, der klare Domänensätze statt eines universellen CF-Query-Nachbaus liefert. Erfassen Sie an der alten Grenze Spaltennamen, Reihenfolge, Nullwerte, Präzision, Zeitzonen, Zeilenzahl, erzeugte Schlüssel und Fehler. Vergleichen Sie sie an der neuen Grenze. Bewahren Sie Reihenfolge nur bei ORDER BY; wenn Verbraucher von Zufallsreihenfolge abhängen, machen Sie sie explizit.

Adobe dokumentiert QueryExecute mit SQL, Parametern und Optionen; Parameter können Arrays oder Structs sein. Das hilft bei vorbereitendem Refactoring, weil SQL und Bindungen sichtbar werden. Es löst die Migration nicht. Der Vertrag liegt in Ergebnisform, Transaktionen, Datenquellen und Verbrauchercode.

Nutzen Sie pro wichtiger Operation einen kleinen Vertrag:

operation: findOpenOrders
inputs: customerId integer, cutoff timestamp UTC
reads: orders, order_items
ordering: orders.created_at DESC, orders.id DESC
nulls: shipped_at remains null
precision: total_amount decimal(18,2), never float
errors: missing customer returns empty rows; unavailable DB returns dependency error

Dieser nüchterne Eintrag verhindert, dass die neue Route richtige Zeilen falsch sortiert, Geld über Fließkomma rundet oder Datenbank-null in einen leeren Text verwandelt.

Jobs und nicht visuelle Endpunkte vor stark genutzten Seiten bewegen

Geplante Jobs, Importprozesse, Feeds und schmale Remote-Methoden eignen sich früh, weil ihre Ein- und Ausgaben leichter aufzuzeichnen sind. Sie decken auch verborgene Serverkonfiguration auf: Dateipfade, Dienstkonten, Mailrelay, Proxyregeln, Sprache, Zeitzone und Wiederholung.

Kopieren Sie nicht nur einen Cron-Ausdruck. Prüfen Sie, ob ColdFusion Überlappung verhinderte, wie Fehler wiederholt und protokolliert wurden, welches Arbeitsverzeichnis galt und ob Teilabläufe wiederholbar waren. Geben Sie dem Ersatz einen Idempotenzschlüssel oder Checkpoint, wenn bisher ein Einzelprozess zufällig geschützt hat. Lassen Sie ihn mit kopierten Eingaben im Schatten laufen, bevor er schreiben darf.

Remote-CFC-Aufrufe und Feeds sind gute Proxy-Kandidaten. Leiten Sie eine interne Gruppe zum Ersatz, vergleichen Sie Antworten nach erlaubter Normalisierung und erhöhen Sie dann dessen Verantwortung. Schreiben beide Schatteninstanzen, drohen doppelte Effekte. Vergleichen Sie auf einer wiederhergestellten Datenbank oder lassen Sie nur eine Implementierung committen.

Diese Phase prüft Bereitstellung, Secrets, Beobachtbarkeit, Rollback und Zuständigkeit bei kleinem Nutzerrisiko. Wer einen migrierten Job nicht durch einen Fehler bedienen kann, sollte noch keine Konto- oder Berichtsroute bewegen.

Den Proxy über die Reihenfolge entscheiden lassen

Ein Reverse Proxy oder Load Balancer sollte bestimmen, welche Implementierung eine Route besitzt. DNS ist zu grob, und ein Schalter in CFML zwingt jede Anfrage weiter durch die alte Laufzeit. Der Betrieb braucht eine sichtbare Routingtabelle, die sich ohne Doppeldeployment ändern lässt.

Wählen Sie klare Grenzen: genaue Pfade, Methoden, Hosts, Mandanten oder stabile Nutzergruppen. Vermeiden Sie prozentuale Verteilung zustandsbehafteter Schreibzugriffe, solange Sitzung und Datenverhalten nicht kompatibel sind. Ein Formular auf einer Seite und seine Umleitung auf der anderen legt Token-, Nachrichten- und Cacheabweichungen offen.

Eine brauchbare Reihenfolge ist:

1. Statische Inhalte und Health-Endpunkte ohne Geschäftszustand.
2. Geplante Jobs und schmale schreibgeschützte APIs mit Fixtures.
3. Leseseiten über den neuen Datenbankadapter.
4. Schreibrouten mit Idempotenz-, Transaktions- und Rollbacktests.
5. Anmeldung, Sitzungserzeugung, Uploads, Exporte und übrige Querschnittsrouten.

Halten Sie pro Abschnitt eine Datenbankautorität. Dual Writes erzeugen Abgleichsarbeit, wenn ein sauberer Rückweg nötig ist. Bevorzugen Sie einen Writer, kompatible Schemaänderungen und Änderungsprotokolle. Liegt das Ziel in Postgres, führen Sie es hinter einem Adapter ein und übertragen Sie Tabellenbesitz einzeln.

Aufgezeichneter Traffic macht Parität belegbar

Unit-Tests beweisen gewählte Beispiele; Produktionsverkehr zeigt echte Eingaben. Erfassen Sie Anfragen und Ergebnisse mit Datenschutzkontrollen, spielen Sie sie isoliert gegen den Ersatz ab und vergleichen Sie Status, Header, normalisierten Inhalt, Datenbankwirkungen und Seiteneffekte. Tokenisieren Sie sensible Felder, ohne fachlich relevante Unterschiede zu verlieren.

Ordnen Sie jede Abweichung ein: gewollte Änderung, flüchtiges Feld, vorläufig akzeptierter Quellfehler oder Ersatzfehler. Normalisierer müssen eng und prüfbar bleiben. Wer alle Zeitangaben ignoriert oder alle Arrays sortiert, kann eine kaputte Antwort passend machen. Normalisieren Sie nur benannte Felder, deren Variation der Vertrag erlaubt.

Ein reproduzierbarer HTTP-Check bleibt einfach:

curl -sS -D old.headers -o old.body -b session.txt https://old.internal/orders/1042
curl -sS -D new.headers -o new.body -b session.txt https://new.internal/orders/1042

Der Bericht ist wichtiger als die Befehle. Speichern Sie Fingerabdruck, alten und neuen Status, Headerdifferenzen, Bodyvergleich, Datenbankänderung, Seiteneffekte und Prüferentscheidung. Fordern Sie Belege für Erfolg, abgelehnte Berechtigung, ungültige Eingaben, leere Ergebnisse, Wiederholungen und Ausfälle von Abhängigkeiten.

CodeHero setzt dieses Modell auf ganze Codebasen ein: Die Plattform liest den gemischtsprachigen Baum vollständig, und ein Paritätsharness prüft den Ersatz mit aufgezeichnetem Produktionsverkehr. Dieser Maßstab gilt auch für einen eigenen Harness, denn die Lizenz darf nicht wegen konvertierter Dateizahlen enden.

Schreibzugriffe bei intaktem Rollback umstellen

Eine Route darf schreiben, wenn der Ersatz die Datensemantik belegt hat und der alte Pfad ohne Reparatur inkompatibler Zustände zurückkehren kann. Nutzen Sie Expand-and-Contract: kompatible Spalten ergänzen, tolerante Leser verteilen, Writer verschieben, prüfen und alte Strukturen erst nach Ablauf des Rückwegs entfernen.

Für Sitzungen braucht es eine Entscheidung. Teilen Sie Store und Cookie-Vertrag, übersetzen Sie am Proxy oder erzwingen Sie für eine umgestellte Gruppe eine kontrollierte Neuanmeldung. Teilen funktioniert nur bei gleicher Serialisierung, Ablaufzeit, Rotation und Verschlüsselung. Neuanmeldung ist oft sauberer, muss aber laufende Formulare schützen.

Legen Sie für Uploads und Dateien einen Besitzer außerhalb lokaler Serverplatten fest. Prüfen Sie Dateinamen, Rechte, vorhandene Virenprüfung, Aufbewahrung und atomare Sichtbarkeit. Ein Ersatz, der lokal schreibt, während CFML ein Share liest, besteht Anfragetests und verliert später Dateien.

Definieren Sie Rückkehrsignale vor der Umstellung: Paritätsfehler in geschützten Abläufen, veränderte Fehlerrate, wachsende Queue, verletzte Dateninvariante oder nicht abgleichbare Seiteneffekte. Benennen Sie Entscheider und den Umgang mit bereits bestätigten Schreibvorgängen. Nur Traffic zurückzuschalten repariert keine Daten.

Verschieben Sie eine begrenzte Schreibfamilie nach der anderen und halten Sie den alten Code deploybar. Nach dem Belegfenster entziehen Sie der alten Anwendung die Schreibrechte für diese Route. Damit läuft die Rückkehroption bewusst aus.

Betrieb vom alten Admin-Console lösen

Die Migration ist unvollständig, solange Betriebspersonal ColdFusion Administrator zur Diagnose oder Wiederherstellung braucht. Übertragen Sie Health Checks, strukturierte Logs, Anfrage-IDs, Jobhistorie, Schalter und Abhängigkeitsstatus in das aktuelle Betriebssystem. Erhalten Sie die Bedeutung der Alarme, nicht eine Konsole wegen bekannter Knöpfe.

Schreiben Sie für jede migrierte Last ein Runbook, solange der CFML-Betrieb noch vergleichen kann. Es erklärt Deployment, Pause, Wiederholung, Rollback, Fehleranalyse, Abgleich von Teilergebnissen, Secret-Rotation und Datenbankprüfung. Testen Sie es an einem kontrollierten Fehler.

Behandeln Sie Konfiguration ebenso. Datenquellen, Mappings, Mail, Zeitzonen und JVM-Werte sind oft versteckte Eingaben. Stellen Sie Ersatzkonfiguration unter Review, trennen Sie Secrets und lassen Sie den Start bei fehlenden Pflichtwerten verständlich scheitern. Dokumentieren Sie alte zu neuen Werten sowie bewusst verworfene Einstellungen.

Halten Sie Beobachtbarkeit vergleichbar. Nutzen Sie die Proxy-Anfrage-ID in Logs, Audits, Queues und Paritätsberichten. Vergleichen Sie Geschäftsergebnisse statt Logtexte: Der Betrieb muss wissen, ob Auftrag 1042 einmal angenommen und gemeldet wurde.

Proben Sie Restore und Recovery. Stellen Sie Daten und Konfiguration isoliert wieder her, spielen Sie akzeptierten Traffic ab und lassen Sie Jobs pausiert, bis ein Operator sie aktiviert. So finden Sie fehlende Secrets, lokale Dateien, Datenbankerweiterungen und Startreihenfolgen. Nie getestete Backups sind kein Beleg.

Testen Sie den Ersatz mit denselben Zeit- und Spracheinstellungen wie die Produktion. Monatsgrenzen, Zeitumstellungen, Datenbankzonen, JVM-Defaults und lokales Zahlenformat können normale Replays bestehen und an Randzeiten abweichen. Setzen Sie Zeitzone und Uhr explizit und nehmen Sie aufgezeichnete Grenzfälle auf. Gleiche HTML-Zeitangaben können andere Zeilen wählen oder einen Job eine Stunde zu spät planen.

Geben Sie jeder Kompatibilitätsschicht einen Besitzer und ein Löschkriterium. Cookie-Übersetzer, Query-Adapter, Proxy-Normalisierer und Leser für zwei Schemas helfen vorübergehend, werden aber leicht unsichtbare Dauerinfrastruktur. Tragen Sie jede Brücke mit alter Abhängigkeit, nötigem Beleg und spätestem Endpunkt ins Routenverzeichnis ein. Löschen Sie sie, sobald eine Route kein CFML-Verhalten mehr braucht. Die Entfernung gehört mit Prüfer und Produktionsbeleg zur Routenabnahme.

Bewahren Sie Entscheidungen zu Paritätsausnahmen und Datenumwandlungen auf und schulen Sie den Bereitschaftsdienst in neuen Grenzen und Fehlern. Ein späterer Vorfall muss zu einem aktuellen Dienst, Query, Job oder Runbook führen, nicht zu einer Person, die sich an ein Include erinnert.

ColdFusion erst nach der versteckten Arbeit abschalten

Null Browser-Traffic bedeutet nicht null Nutzung. Prüfen Sie Schedulerhistorie, Firewalllogs, Webserverrouten, Dienstkonten, Datenbanksitzungen, Shares, Mailrelay, Monitoring, Backups und Admin-Lesezeichen. Suchen Sie direkte Hosts und IPs in anderen Repositories und Runbooks. Lassen Sie unerwartete Aufrufe in einer Sperr- und Beobachtungsphase sichtbar scheitern.

Entziehen Sie Befugnisse stufenweise. Deaktivieren Sie Aufgaben, Datenbankschreibrechte und externe Konnektoren, entfernen Sie den Knoten aus dem Proxy und beobachten Sie. Archivieren Sie zulässigen Quellcode, Konfiguration, Deploymenthinweise, Paritätsberichte, Lizenzunterlagen und Datenzuordnungen. Bewahren Sie Erklärbarkeit, nicht eine lauffähige Sicherheitslast.

Der Ersatz sollte keine CFML-Konzepte ohne fachliche Bedeutung behalten. Go-Dienste können Anfrage- und Domänenverhalten besitzen, TypeScript die Clientinteraktion und Postgres Datenregeln. Architekturänderung folgt messbarer Parität, muss aber stattfinden, bevor alte Abstraktionen im neuen Code fest werden. Transliteration ändert nur die Laufzeitrechnung.

Ein ColdFusion-Umbau durch CodeHero wird in unter 30 Tagen geliefert, mit geänderter Architektur statt mechanisch kopierter Tags. Der Termin zählt, weil Routenbesitz, Traffic, Datenbankwirkungen und akzeptierte Abweichungen konkret zeigen, warum der alte Server entfernt werden kann.

Das Abschalten soll ereignislos sein. Kein Nutzerpfad, Job, Integrationspartner oder Betriebsablauf darf es bemerken. Fühlt es sich mutig an, fehlen Inventar oder Paritätsbelege.