Zusammenfassung

  • Die genaue Entität ist als kanadische Webhosting-Marke unter Verwendung von100megswebhosting.combelegbar, mit einer öffentlichen Kontaktadresse in Edmonton, Kundenhinweisen aus dem Jahr 2002, einem archivierten Dienstleistungskatalog von 2009–2010 und einer dokumentierten Übernahme durch Tech Assets im Jahr 2011. Die verfügbaren Aufzeichnungen belegen keine bestimmte Bundesgesellschaft oder ein firmeneigenes Netzwerk.
  • Bis 2010 beschrieb der Markenname das Produkt nicht mehr: Gemeinsam genutzte Tarife warben mit 10 GB bis 250 GB Speicherplatz, ein Tarif mit unbegrenztem Datenvolumen und dedizierte Angebote mit 2.000 GB. Die verbindlichen Grenzen lagen woanders – in einer 4-Prozent-Regel für gemeinsam genutzte Serverressourcen, Softwarekompatibilität, Supportermessen und Kündigungsbedingungen.
  • Der Katalog verkaufte einen kompletten Arbeitsablauf für kleine Unternehmen über cPanel, PHP, MySQL, E-Mail, SSL, geplante Aufgaben, Anwendungsinstallationsprogramme und Backups. Dieser Komfort konzentrierte auch die Wechselkosten, da eine nutzbare Website von viel mehr abhing als dem Kopieren ihrer öffentlichen Dateien.
  • Der Verkauf im Jahr 2011 und der spätere Bericht eines Kunden über Migration und höhere Gebühren veranschaulichen die kommerzielle Seite des Kontinuitätsrisikos. Eine Übernahme kann den Dienst bewahren, während Preis, Supportweg und Anreize rund um eine Arbeitslast geändert werden.
  • Die praktische Beschaffungslektion besteht darin, Eigentum, Laufzeitlebenszyklus, Ressourcenrichtlinie, Wiederherstellbarkeit, Datenstandort und Ausstieg vor dem Kauf zu testen. Kapazität ist billig umzubenennen; geprobte Portabilität ist schwerer zu fälschen.

Die wichtigste Zahl war sieben

Die folgenreichste Zahl im erhaltenen Material von 100 Megs Web Hosting ist nicht 100. Es ist sieben.

In einem archivierten AGB-Eintrag von 2010 gab der Anbieter an, dass er ein Kontoarchiv nur sieben Tage nach der Kündigung aufbewahrte. Eine Wiederherstellung innerhalb dieses Zeitraums konnte mit einer Gebühr von 50 $ verbunden sein, während der Kunde für die Sicherungskopien verantwortlich blieb. Dieselben AGB besagten, dass der Anbieter möglicherweise automatisch archivierte Dateien wiederherstellen könne, garantierte jedoch nicht, dass eine Sicherung existieren, korrekt sein oder regelmäßig erstellt werden würde. Diese Klauseln definierten den tatsächlichen Umfang des Dienstes klarer als jedes Speicherkontingent.

Ein Kunde konnte Hunderte von Gigabyte kaufen und hatte dennoch nur eine Woche Zeit, um festzustellen, dass die für die Abreise benötigte Kopie unvollständig war.

Dieser Kontrast ist der Schlüssel zum Verständnis von 100 Megs Web Hosting Services. DerBTW-Verzeichniseintragliefert den genauen Entitätsnamen und die kanonische Verzeichnisverbindung. Die eigenen archivierten Seiten des Unternehmens kürzten den Handelsnamen im Allgemeinen auf „100 Megs Web Hosting“ oder „100Megs Web Hosting“ ab. Die Zahl in diesem Namen klang konkret. Sie rief eine Ära in Erinnerung, in der ein Hosting-Angebot durch eine heute winzig erscheinende Menge differenziert werden konnte. Doch bis August 2010 warb der günstigste Shared-Tarif des Unternehmens mit 10 GB Speicher – dem Hundertfachen der vom Markennamen suggerierten Menge – und der größte mit 250 GB. Die dedizierten Angebote gingen noch weiter. Die alte Zahl war zu einer Gedächtnisstütze geworden, nicht zu einer Spezifikation.

Dies ist nicht nur eine amüsante Geschichte über technologische Inflation. Eine eingefrorene Marke kann verbergen, wie viele andere Versprechen sich um sie herum geändert haben. Der Speicherplatz wächst. Die Datenübertragungsgrenzen werden „unbegrenzt“. Der Anwendungsinstaller tauscht einen Softwarekatalog gegen einen anderen aus. PHP- und Datenbankversionen schreiten voran. Ein Bedienfeld entfernt eine alte Funktion. Ein Rechenzentrumsbesitzer wechselt. Ein Hosting-Unternehmen wird übernommen.

Der Kunde sieht immer noch dieselbe Domain und das vertraute Login, aber das zugrunde liegende Betriebsabkommen hat sich möglicherweise mehrfach geändert.

Die Beweislage ist ungewöhnlich aufschlussreich, weil der erhaltene Katalog vier Ansichten zusammenführt, die oft getrennt sind: beworbene Kapazität, der tatsächliche Software-Stack, die Durchsetzungspolitik des Anbieters und Kundenberichte. Zusammengelesen zeigen sie, dass Hosting ein Koordinationsdienst war. Er verband einen Domainnamen, DNS, Dateien, Datenbanken, Mailboxen, Zertifikate, geplante Aufgaben, Anwendungsversionen, Ressourcengrenzen, Support-Warteschlangen und Abrechnungsregeln. Der Kunde erlebte diese nicht als separate Technologien.

Der Kunde erlebte eine Website, die entweder weiterhin handelte, veröffentlichte und E-Mails empfing oder nicht.

Deshalb sind sieben Tage wichtig. Sie verwandeln „Backup inklusive“ von einer Funktion in eine Frage: inklusive für wen, wo aufbewahrt, von wem wiederherstellbar und wie lange nach dem Ende der kommerziellen Bindung verfügbar? Dieselbe Frage gilt für jeden anderen Punkt im Bündel. „Unbegrenzt“ ist keine Kapazitätsantwort, bis die Regel zur akzeptablen Nutzung gelesen wird. „cPanel-Migration“ ist keine Ausstiegsantwort, bis nicht unterstützte Erweiterungen, Datenbanken, DNS-Einträge und Mail-Routing getestet werden.

„Kanadisches Hosting“ ist keine Standortantwort, bis die physische Einrichtung und der grenzüberschreitende Datenverkehr identifiziert sind.

100 Megs ist daher nicht wertvoll, weil es riesig war – das wurde nicht nachgewiesen – oder weil der Name eine bestimmte Netzkapazität belegt – das tut er nicht. Es ist wertvoll, weil die Aufzeichnung eine kleine Hosting-Marke in dem Moment erfasst, als Rohzuteilungen reichlich wurden, die Betriebskontinuität jedoch knapp blieb.

Die Marke beweisen, ohne eine Gesellschaft zu erfinden

Die erste Disziplin ist die Identität. „100 megs“ ist eine einheitenartige Phrase und könnte Speicher, Übertragung oder Leitungsgeschwindigkeit beschreiben. Sie kann allein kein Unternehmen beweisen, geschweige denn dessen Größe. Die belegbare Identität stützt sich stattdessen auf eine Kette unternehmensspezifischer Aufzeichnungen.

Der Registereintrag für100MEGSWEBHOSTING.COMgibt ein Erstellungsdatum vom 16. März 2001 an. Eine Domain-Registrierung beweist nicht, dass der Dienst an diesem Tag begann, aber sie legt eine Untergrenze für die genaue Web-Identität fest. Unabhängige Kundendiskussionen datieren die Nutzung des Dienstes dann auf 2002. In einem Oktober 2002PHPBuilder-Threadgab ein Teilnehmer an, er hoste auf einem 100megswebhosting-Konto und beschrieb einen „Advanced“-Tarif für 20 $ pro Monat mit 1 GB Speicher, 10 GB monatlichem Datenvolumen, CGI, PHP, MySQL, einem Bedienfeld, installierbaren Skripten, Statistiken und Fehlerprotokollen. Eine weitere Oktober 2002Straight-Dope-Diskussionenthält einen Kunden, der sagt, er hoste eine Site bei 100 Megs Web Hosting und sei mit dem Service und Support zufrieden gewesen. Dies sind Nutzeraussagen, keine geprüften Unternehmensaufzeichnungen, aber sie ordnen die genaue Domain und den Dienstnamen unabhängig voneinander im Markt ein.

Die archivierteÜber-uns-Seitedes Unternehmens, aufgenommen im Juli 2009, bezeichnete 100 Megs Web Hosting als ein in Kanada ansässiges Unternehmen. Es gab mehr als acht Jahre Branchenerfahrung und einen Kundenstamm in Tausenderhöhe an. Die erste Behauptung ist weitgehend konsistent mit der Domain-Registrierung von 2001 und den Kundenhinweisen von 2002. Die Kundenanzahl-Behauptung ist nicht unabhängig verifiziert und sollte nicht als Maßstab für die Größe verwendet werden. Die archivierteKontaktseite, aufgenommen im August 2010, zeigte die genaue Marke, Support- und Rechnungsadressen unter der Domain sowie eine Straßenadresse unter 1131, 9363 Simpson Drive in Edmonton, Alberta. Sie verwendete auch die Fußzeile „100Megs Web Hosting“. Zusammengenommen beweisen diese Seiten eine kanadische, öffentlichkeitswirksame Marke und Betriebskontakt, nicht nur eine beschreibende Verzeichnisbezeichnung.

Das Ende der Phase als unabhängige Marke ist klarer. Tech Assets gibt in seinerUnternehmensgeschichtean, dass es „100MegsWebHosting“ im Jahr 2011 übernommen hat, und beschreibt es als einen beliebten cPanel-Host. Die Schreibweise lässt die Leerzeichen weg, wie es die Domain tat, aber die cPanel-Beschreibung, der genaue Namensstring und der Zeitpunkt stimmen mit dem archivierten Dienst überein. Das ist eine direkte Unternehmensbrücke. Es passt auch zu der späteren Aussage eines Kunden von 2012, dass Konten und Websites, die mit „100megs-Domains“ verbunden waren, zu Jumpline, der ursprünglichen Hosting-Marke von Tech Assets, verschoben worden waren.

Es gibt eine wichtige Einschränkung. Eine Suche in der offiziellenCorporations Canada Bundesdatenbanknach dem genauen Namen ergab während dieser Recherche keine Übereinstimmung. Die Datenbank selbst warnt, dass sie Provinz- und Territorialgesellschaften, Finanzgesellschaften und ausländische Gesellschaften ausschließt. Ein Null-Ergebnis kann daher nicht beweisen, dass kein rechtliches Unternehmen existierte. Es bedeutet nur, dass die hier zusammengetragenen öffentlichen Belege es nicht rechtfertigen, einen bundesrechtlich eingetragenen Eigentümer zu benennen. Auch die archivierte Site hängt nicht durchgängig ein „Inc.“ oder eine Gesellschaftsnummer an. Die vertretbare Formulierung ist, dass 100 Megs Web Hosting Services eine kanadische Betriebsmarke war, die öffentlich über eine Adresse in Edmonton erreichbar war, deren genauer rechtlicher Eigentümer vor dem Verkauf von 2011 in den hier verwendeten Quellen unbestätigt bleibt.

Das dokumentierte Betriebsfenster sollte ebenso sorgfältig eingegrenzt werden. Die Domain wurde 2001 erstellt. Kunden diskutierten die Nutzung des Dienstes im Jahr 2002. Unternehmensseiten sind von 2009 und 2010 erhalten. Tech Assets vermerkt eine Übernahme im Jahr 2011. Das stützt einen aktiven Zeitraum von mindestens 2002 bis 2011, wobei der Domain-Nachweis auf eine Vorbereitung oder einen Start bis 2001 hindeutet. Es stützt keine Behauptung über einen Vorläufer in den späten 1990er Jahren, ein genaues Gründungsdatum, Jahresumsatz, Mitarbeiterzahl oder die Anzahl der Server.

Diese attraktiv klingenden Details tauchen in schwachen Auflistungen und selbstberichteten Biografien auf, aber die zuverlässige Brücke erfordert sie nicht.

Diese engere Identität reicht dennoch aus, um das Unternehmen zu untersuchen. Marken sind reale kommerzielle Oberflächen, selbst wenn ihre rechtliche Hülle undurchsichtig ist. Kunden zahlten die Marke, eröffneten Support-Tickets unter der Marke, nutzten ihre Nameserver und ihr Bedienfeld, verließen sich auf ihre Richtlinien und trafen später auf einen Nachfolger. Der analytische Fehler wäre, diese Realität in falsche unternehmerische Präzision zu verwandeln.

Ein kanadischer Laden auf einer Betriebsfläche in Colorado

Die archivierte Site zog eine klare Grenze zwischen dem Ort, an dem der Verkäufer auftrat, und dem, wo die Maschinen liefen. Die Über-uns-Seite sagte, das Netzwerk sei in der Data393 Denver Tech Center Einrichtung in Englewood, Colorado, untergebracht. Sie warb mit redundanter Strom- und Generatorversorgung, Umweltkontrollen, Branderkennung, biometrischem und Kartenzugang, Videoüberwachung und verschlossenen Schränken. Bei der Konnektivität nannte sie Savvis und Internap, beschrieb eine nahegelegene Internap-Verbindung und listete Fortigate-Firewalls und HP ProCurve-Switches auf.

Sie sagte auch, dass die Server rund um die Uhr überwacht würden und die normale Konfiguration Red Hat Linux verwendete.

Die meisten dieser Details sind Behauptungen des Unternehmens. Sie sollten nicht in eine Betriebszeit-Feststellung oder eine Zertifizierung umgewandelt werden. Es gibt jedoch eine unabhängige Bestätigung, dass die genannte Einrichtung und ihre breiten physischen Fähigkeiten zum relevanten Zeitpunkt existierten. Eine Ankündigung von Data393 vom Juli 2008berichteteüber eine Erweiterung um 10.000 Quadratfuß am Standort Denver Tech Center, wodurch sich die Doppelbodenfläche auf etwa 30.000 Quadratfuß vergrößerte. Sie beschrieb Hochdichte-Stromversorgung und -Kühlung, sechs parallele 600-kW-Generatoren mit N+1-Redundanz, Cabinet- und Cage-Colocation sowie die Übernahme von Data393 durch Managed Data Holdings im Dezember 2007. Da es sich um eine Pressemitteilung des Einrichtungsbetreibers handelt, bestätigt sie die Einrichtung, nicht aber jede 100-Megs-Konfiguration darin unabhängig.

Das Archiv liefert eine weitere technische Verbindung. Common Crawl hat die Unternehmensseiten von 2009 und 2010 von209.197.254.38abgerufen. Der aktuelleARIN-RDAP-Eintrag für diese Adresseordnet sie der Zuweisung mit dem NamenD393-ENG01-209-197-254-0-25zu. Der derzeitige Registrant ist nicht 100 Megs, und ein aktueller Eintrag kann die Zuweisung nicht so rekonstruieren, wie sie im Jahr 2010 bestand. DieD393-Benennung ist konsistent mit dem archivierten Data393-Konto, aber es ist eine Bestätigung des Standorts, kein Beweis dafür, dass 100 Megs den Adressblock besaß.

Dieser Aufzeichnung wird kein unternehmenseigenes autonomes System oder eine direkte Adresszuweisung nachgewiesen. Diese Abwesenheit ist von Bedeutung. Kleine Hosting-Anbieter mieteten häufig Cabinets, Server, Transit oder verwaltete Dienste von einer größeren Einrichtungs- und Netzwerkbetreibergesellschaft. Ihr Wert lag in der Paketierung und dem Betrieb der Kundenschicht, nicht im Besitz von Glasfaser oder im Ankündigen von Routen.

Die archivierte Site selbst sprach in Marketingsprache von ihrem Netzwerk und ihren Servern, aber die vorsichtigere Interpretation ist, dass 100 Megs einen Hosting-Dienst kontrollierte, der über die von anderen bereitgestellte Infrastruktur und Konnektivität geliefert wurde.

Diese Abhängigkeitsstruktur verändert die Lesart des Maßstabs. Ein Anbieter kann viele Domains bedienen, ohne ein Rechenzentrum zu besitzen. Er kann mehrere Aufwärtspfade bewerben, ohne eine eigene Netznummer zu halten. Er kann einen dedizierten Server anbieten, während er das Rack, den Strom und den Transit darunter mietet. Nichts davon macht den Dienst unwirklich. Es bedeutet, dass die Beschaffung die Betriebsverantwortung von der Asset-Eigentümerschaft trennen muss. Wenn der Strom ausfällt, wer hat den Facility-Vertrag? Wenn eine Aufwärtssstrecke nachlässt, wer kann sie ändern?

Wenn das Support-Team des Resellers ein Problem sieht, welcher Zulieferer berührt tatsächlich den Switch oder Server? Die Marke besitzt das Kundenversprechen, auch wenn ein anderes Unternehmen die Betriebsfläche besitzt.

Die kanadisch-coloradische Aufteilung antizipiert auch eine moderne Cloud-Frage: Die Zuständigkeit folgt den Daten und Verträgen, nicht den Slogans. „In Kanada ansässig“ sagte den Käufern, wo der Anbieter sich identifizierte. „Rechenzentren in Denver, die die Welt bedienen“, wie es in den eigenen Metadaten der Site hieß, sagte ihnen etwas anderes über die Verarbeitung. Beides konnte wahr sein. Keines für sich beantwortete, welches Recht bei einem Streit galt, wo die Backups lagen oder welche Subunternehmer auf Kundeninformationen zugreifen konnten.

Diese Antworten waren über die AGB, die Datenschutzseite und die Infrastrukturbeschreibung verstreut.

Was der Katalog 2010 tatsächlich verkaufte

Die archivierteShared-Hosting-Seitestellte im August 2010 drei Tarife vor. Value kostete 5 $ monatlich oder 50 $ jährlich, mit 10 GB Speicher, 50 GB Datenvolumen und einer gehosteten Domain. Pro kostete 10 $ monatlich oder 100 $ jährlich, mit 100 GB Speicher, 250 GB Datenvolumen und fünf Domains. Ultra kostete 20 $ monatlich oder 200 $ jährlich, mit 250 GB Speicher, „unbegrenztem“ Datenvolumen und 30 Domains. Die Seite legte keine Währung in der erfassten Tabelle fest, daher ist die sichere Beschreibung eine Dollar-denominierte Preisgestaltung, nicht eine Annahme über kanadische oder US-Dollar.

Die Progression offenbart die Shared-Hosting-Logik dieser Zeit. Jede Stufe kaufte mehr als Kapazität. Value beinhaltete zwei MySQL-Datenbanken und fünf POP-Postfächer; Pro erhöhte diese auf zehn Datenbanken und 25 Postfächer; Ultra warb mit beidem als unbegrenzt. Alle drei beinhalteten cPanel, CGI, Perl, PHP, FrontPage 2000-Erweiterungen, Shared SSL, einen Warenkorb, Statistiken, geplante Aufgaben, Spam-Filter, einen Site-Builder, webbasiertes Backup, tägliches Backup und Fantastico. Benutzerdefiniertes SSL und Shell-Zugang waren nur als optionale Funktionen bei den größeren Tarifen verfügbar.

WebHost Manager Zugang war ebenfalls optional bei Pro und Ultra. Der Anbieter bot an, bestehende Kunden auf Wunsch auf einen vergleichbaren neuen Tarif umzustellen – eine frühe Anerkennung, dass selbst eine Neugestaltung der Tariftabelle einen operativen Übergang erfordern konnte.

Fantastico ließ das Hosting-Konto wie einen App-Store aussehen, bevor dieser Begriff gebräuchlich wurde. Die archivierte Seite listete WordPress, Drupal, Joomla, Mambo, phpBB2, Simple Machines Forum, osCommerce, Zen Cart, CubeCart, Helpdesks, Projektwerkzeuge, Wikis, Abrechnungsprogramme und Umfragen auf. Eine kleine Organisation musste nicht jede Komponente separat beschaffen. Sie konnte ein Skript auswählen, den Installer Dateien und eine Datenbank anlegen lassen, E-Mail und eine Domain verbinden und mit dem Publizieren oder Verkaufen beginnen.

Oberhalb des Shared Hosting gab es eineVirtual Dedicated Server-Seite. Sie bot einen „VDS Power 300“ für 60 $ pro Monat mit 10 GB Speicher, 300 GB Datenvolumen, 256 MB Arbeitsspeicher, einer 600-MHz-Prozessorzuweisung, CentOS, Root-Zugang, cPanel und WHM, unbegrenzten Domains und Fantastico. Die erfasste Seite markierte den Tarif als ausverkauft. Dieses Detail ist aufschlussreicher als eine allgemeine Verfügbarkeitsbehauptung: Der Anbieter hatte eine Upgrade-Stufe konstruiert, bot aber zu diesem Zeitpunkt keine Kapazität darauf an.

DieDedicated-Server-Seitebot drei Konfigurationen an. Ein Tarif namens Cloud war für 135 $ pro Monat gelistet mit einer 400-GB-Festplatte, 1 GB Arbeitsspeicher und einem einzelnen 2,2 GHz Intel-Prozessor. Premium war 199 $ mit zwei 500-GB-Festplatten, 2 GB Arbeitsspeicher und einem 2,4 GHz Core 2 Duo. Enterprise war 349 $ mit zwei 500-GB-Festplatten, 2 GB Arbeitsspeicher und zwei Dual-Core 2,8 GHz Xeons. Alle warben mit 2.000 GB Datenvolumen, täglichen Backups, unbegrenzten Domains, cPanel und WHM, Root-Zugang, Fantastico, keiner Einrichtungsgebühr und einer 30-Tage-Garantie.

Der Name „Cloud“ sollte nicht als Beleg für eine elastische oder verteilte Architektur gelesen werden. Auf der Seite war es einfach die Einstiegskonfiguration für dedizierte Server. Es gibt in dem Material keine Hinweise auf automatisiertes Failover, nutzungsabhängige Abrechnung, eine Anwendungsschnittstelle oder schnelle horizontale Skalierung. Das Unternehmen warb auch mit der Wahl der Linux-Distribution und nannte Savvis, Internap und Level 3 im Zusammenhang mit dem Dedicated-Service, veröffentlichte jedoch keine Routing-Messungen oder eine Service-Level-Berechnung in dem erfassten Material.

DasReseller-Angebotvervollständigte den Katalog. Ein Reseller konnte die drei Shared-Tarife unter eigenem Namen zu 25 Prozent unter dem Einzelhandelspreis verkaufen, den Endkundenpreis festlegen und WebHost Manager sowie private Nameserver nutzen. Der Reseller übernahm den Erstkontakt-Support; 100 Megs lieferte die Systemadministration und Second-Level-Hilfe. Es gab keine Anforderung, einen großen Block im Voraus zu kaufen, und der Anbieter sagte zu, die Reseller-Abrechnung monatlich zu aktualisieren.

Zusammengenommen waren dies nicht vier unzusammenhängende Produkte. Sie waren ein Eskalationspfad. Ein Kunde konnte mit einem kostengünstigen Shared-Konto beginnen, Domains und Datenbanken hinzufügen, Reseller werden, einen virtuellen Server für mehr Kontrolle anstreben oder zu einer dedizierten Maschine wechseln. cPanel und der vertraute Anwendungskatalog reduzierten die sichtbare Distanz zwischen den Stufen. Diese Kontinuität war kommerziell nützlich, aber sie hielt auch das Betriebswissen des Kunden an eine Familie von Werkzeugen und Konventionen gebunden.

Hosting-Ökonomie versteckte sich hinter großzügigen Kontingenten

Die Shared-Tarife wirken angesichts ihrer Preise verblüffend großzügig, insbesondere das Ultra-Konto mit 250 GB. Aber Speicher war nur eine Eingangsgröße und selten die bindende. Ein Hosting-Unternehmen konnte weit mehr nominellen Speicher und Datenvolumen zuweisen, als alle Kunden gleichzeitig nutzen würden. Was es nicht ignorieren konnte, war die Spitzen-Prozessornachfrage, der Speicherdruck, die Datenbank-Konkurrenz, die Mail-Reputation, die Support-Arbeit, der Backup-Speicher und das Betriebsrisiko, das durch angreifbare Skripte entsteht.

100 Megs machte diese Unterscheidung in seiner archiviertenRichtlinie zur akzeptablen Nutzungexplizit. Ein Skript oder Prozess auf der Shared-Plattform durfte zu keinem Zeitpunkt mehr als 4 Prozent der verfügbaren Systemressourcen verwenden. Die Regel galt auch dann, wenn der Kunde innerhalb der Speicher- und Datenvolumen-Grenzen blieb. Der Anbieter behielt sich das Ermessen über die Reaktion vor und warnte, dass die Dienste für Website-Material bestimmt seien und nicht für unzusammenhängende Archive, Softwarepakete oder große Mediendateien.

Daher bedeutete „unbegrenzte Bandbreite“ nicht unbegrenzte Rechenleistung oder uneingeschränkte Speichernutzung. Es bedeutete, dass der Anbieter einen Zähler aus der Tariftabelle entfernt hatte, während er anderweitig Kontrollen beibehielt. Das wirtschaftliche Abkommen war probabilistisch: Die meisten Sites würden die meiste Zeit ruhig sein; eine kleine Anzahl von vielbesuchten oder ineffizienten Anwendungen könnte den gemeinsam genutzten Server gefährden; das Management behielt sich die Möglichkeit zum Eingreifen vor. Der Käufer, der nur Gigabyte verglich, übersah die Variable, die den Dienst am ehesten unterbrechen würde.

Das Reseller-Angebot verschärfte dieselbe Ökonomie. Ein Großhandelsrabatt von 25 Prozent schuf Raum für Vertrieb und Support, aber der Reseller übernahm die Erstverantwortung. Jede verwirrende Mail-Einstellung, jedes zurückgesetzte Passwort und jeder Anwendungsfehler konnte diese Marge aufbrauchen. 100 Megs behielt die Systemadministrationsebene, wo die Skaleneffekte am stärksten waren. Der Reseller behielt das Kundengespräch, wo die Kosten volatil und schwer zu automatisieren waren.

cPanel selbst hat seitdem einen weiteren Kostentreiber sichtbarer gemacht. Sein aktuellerLizenzierungsleitfadenbesagt, dass die Lizenzpreise auf der Anzahl der Konten auf einem Server basieren, mit Stufen und einer Pro-Konto-Behandlung oberhalb bestimmter Schwellenwerte. Dies ist eine gegenwärtige Richtlinie, kein Beweis für die 100-Megs-Lizenzrechnung von 2010. Sie zeigt dennoch, wie ein Bedienfeld, das den Mehrbenutzerbetrieb vereinfacht, selbst zu einer Kostenstelle werden kann. Die Ökonomie eines Anbieters ändert sich, wenn die Verwaltungsebene, Sicherheitserweiterungen, Backup-Speicher und Support pro Konto abgerechnet werden, während Kunden weiterhin niedrige Pauschalgebühren erwarten.

Die dedizierte Stufe verschob einige Einschränkungen, anstatt sie zu beseitigen. Root-Zugang reduzierte die Kontrolle des Hosts über installierte Software. Er übertrug auch mehr Verantwortung auf den Kunden. Die Seite warb mit verwalteten Ergänzungen und Support, definierte jedoch nicht, welche Updates, Incident-Response oder Anwendungsreparaturen im Grundpreis enthalten waren. Zwei Kunden, die für identische Hardware bezahlten, konnten sehr unterschiedliche Supportkosten verursachen, abhängig von ihren Anwendungen und Fähigkeiten.

Die dauerhafte Lektion ist, dass billige Kapazität mit teurer Kontinuität koexistieren kann. Der Anbieter verdient eine Marge, indem er allgemeine Aufgaben standardisiert und außergewöhnliche Nutzung kontrolliert. Der Kunde erzielt einen Wert, indem er die Serververwaltung vermeidet. Reibung entsteht dort, wo jede Seite glaubt, die andere sei für die Ausnahme zuständig: ein vielbesuchtes Skript, eine veraltete Anwendung, eine fehlgeschlagene Wiederherstellung, eine Mail-Blacklist, ein benutzerdefiniertes Zertifikat oder eine Migration, die nicht in das normale Werkzeug passt.

Der Kunden-Workflow war eine Kette, kein Ordner

Eine kleine Unternehmenswebsite bei 100 Megs konnte mit einer trügerisch einfachen Aktion beginnen: eine Domain auf den Anbieter zeigen und Dateien hochladen. Der Katalog lud dann den Kunden ein, Schichten hinzuzufügen. Eine MySQL-Datenbank erstellen. WordPress, ein Forum oder einen Warenkorb über Fantastico installieren. POP-Postfächer und Weiterleitungsregeln hinzufügen. Ein Wartungsskript terminieren. Ein Zertifikat aktivieren. Verkehrsstatistiken lesen. Über das Bedienfeld sichern. Vielleicht mehrere Domains hosten, dann Konten an Kunden weiterverkaufen.

Jeder Schritt war bequem, weil cPanel ihn an einem Ort präsentierte. Jeder schuf auch einen Zustand, der bei einer Störung oder Abwanderung verstanden werden musste. Die öffentlichen Dateien waren nur ein Teil. Eine dynamische Site benötigte Datenbankinhalte und Zugangsdaten. Die Mail-Kontinuität hing von Postfachdaten, Aliassen, Weiterleitungen, Filtern und MX-Einträgen ab. Geplante Aufgaben lebten außerhalb des Dokumentenbaums. Zertifikatsschlüssel und Erneuerungsverfahren hatten ihren eigenen Lebenszyklus. Ein Forum oder Shop hing vom genauen Verhalten der PHP-Erweiterungen, Dateiberechtigungen und Datenbankversionen ab.

Die Domain-Kontrolle konnte beim Host, einem Reseller oder dem Kunden liegen.

Zeitgenössische Kundenhinweise zeigen dieses Bündel in Gebrauch. Der PHPBuilder-Teilnehmer von 2002 lobte nicht nur den Speicher; er listete PHP, MySQL, das Bedienfeld, installierbare Skripte, Statistiken, Fehlerprotokolle und Zugriffskontrollen auf. Der Straight-Dope-Kunde bewertete ebenfalls Service und Support neben der Kapazität. Diese Berichte sind subjektiv, aber sie zeigen, was Käufer als das Produkt betrachteten.

Eine Diskussion im osCommerce-Forum vom April 2006illustriertdie Grenze der verwalteten Erfahrung. Ein Benutzer identifizierte 100 Megs als Host und beschrieb, dass er nach einem SSL-Erneuerungsproblem, das einen bestehenden Warenkorb betraf, zu einer osCommerce-Installation geführt wurde. Der Benutzer war sich dann unsicher, wie Händlerkonto- und Zahlungseinstellungen zusammenpassten. Es ist der Bericht eines einzelnen Kunden ohne Antwort des Anbieters, daher kann er kein allgemeines Serviceversagen belegen. Er zeigt aber, wie ein vom Host bereitgestellter Installer die Bereitstellung einfach machen konnte, während die geschäftskritische Konfiguration dem Kunden überlassen blieb.

Dieselbe Komplexität zeigte sich bei alltäglichen Änderungen. Eine Site, die PHP in Dateien mit der Endung.htmlparste, konnte funktionieren, weil Apache diese Dateien durch einen bestimmten Handler bearbeitete. Ändert man die Art und Weise, wie PHP läuft, können die Seiten Code offenlegen oder die Ausführung stoppen. Ein geplantes Haushaltsskript kann wesentlich sein, auch wenn kein Besucher es sieht. Eine ausgehende Mail-Regel kann Bestellbestätigungen unterbrechen, während die Website sichtbar online bleibt. Eine Domain kann weiterhin auf eine statische Seite aufgelöst werden, während das Abrechnungssystem, der Warenkorb oder das Postfach dahinter ausgefallen ist.

Diese Kette erklärt, warum „Migration inklusive“ nicht selbsterklärend ist. Eine Übertragung kann Kontodateien kopieren und dennoch eine Registrar-Anmeldeinformation, eine externe DNS-Zone, eine Drittanbieter-Zahlungseinstellung, eine nicht unterstützte FrontPage-Komponente oder ein lokales Mail-Archiv auslassen. Sie kann Daten bewahren, aber Timing, Berechtigungen oder Zeichenbehandlung ändern. Sie kann die Website verschieben und den alten Mail-Server weiterhin Nachrichten annehmen lassen. Der Kunde benötigt eine Abhängigkeitslandkarte, nicht nur ein komprimiertes Home-Verzeichnis.

Die archivierteSupport-Seitezeigt, dass 100 Megs ein Ticket-System, Ankündigungen und eine Wissensdatenbank hatte, die in die Kategorien Vorverkauf, Abrechnung, E-Mail und Einrichtung unterteilt war. Das ist die Form eines Unternehmens, das versucht, eine heterogene Kette in wiederholbare Anfragen zu verwandeln. Doch die Kategoriennamen offenbaren auch die Übergaben: Ein Abrechnungsproblem und ein Mail-Routing-Problem können für den Kunden das gleiche Symptom haben – der Dienst funktioniert nicht –, durchlaufen aber unterschiedliche Warteschlangen und erfordern unterschiedliche Befugnisse.

Für ein KMU ist die wertvollste Hosting-Fähigkeit daher nicht das größte Kontingent. Es ist ein gepflegtes Inventar von allem, was für das Geschäftsergebnis erforderlich ist. Site, Mail, Domain, Datenbank, Zertifikat, geplante Arbeiten und Drittanbieter-Verbindungen müssen benannte Eigentümer und Exportpfade haben. Der Katalog von 100 Megs machte all das zugänglich. Seine Richtlinien machten klar, dass die Verantwortung für deren Erhalt nicht verschwand.

Der Software-Stack trug Verfallsdaten, die die Marke nicht hatte

Die Common-Crawl-Erfassungen legen mehr frei als den Seiteninhalt. Ihre HTTP-Response-Header identifizieren die Software, die die eigene Site des Unternehmens präsentierte. Die About-Antwort von Juli 2009 meldete Apache 1.3.41, PHP 4.4.9, FrontPage 5.0.2-Erweiterungen, OpenSSL 0.9.7a und zugehörige Module. Bis August 2010 meldeten die erfassten Diensteseiten immer noch Apache 1.3.41 und dieselben FrontPage- und OpenSSL-Generationen, während PHP auf 5.2.11 umgestellt hatte.

Diese Beobachtungen beschreiben den Server, der die Marketing-Seiten auslieferte, nicht unbedingt jede Kundenmaschine. Sie beweisen nicht, dass eine bestimmte Kundenanwendung angreifbar war oder dass Patches fehlten. Sie beweisen etwas Grundlegenderes: Der Dienst hing von versionierten Komponenten ab, die nicht einfach deshalb stillstehen konnten, weil die Marke es tat.

PHPs aktuelleSupport-Richtliniegibt jedem Release-Zweig zwei Jahre vollen Support, gefolgt von zwei Jahren kritischem Sicherheits-Support vor dem Ende der Lebensdauer. Die heutigenWordPress-Anforderungenempfehlen PHP 8.3 oder höher, MariaDB 10.11 oder MySQL 8.0 oder höher und HTTPS. WordPress warnt, dass Legacy-PHP 7.4 und MySQL 5.5.5 möglicherweise noch laufen, aber nicht mehr unterstützt werden und eine Site einem Sicherheitsrisiko aussetzen können. Diese aktuellen Basiswerte sollten nicht rückwirkend als Urteil über einen Host von 2010 projiziert werden. Sie zeigen die Distanz, die ein langlebiges Kundenvermögen zurücklegen muss.

Die Migration ist kein reines Versionsnummern-Upgrade. Anwendungen, die für PHP 4 oder PHP 5 geschrieben wurden, können auf entfernte Funktionen, lockere Fehlerbehandlung, alte Datenbankbibliotheken oder Annahmen darüber angewiesen sein, wie Strings und Variablen funktionieren. Ein Forenthema oder eine Warenkorb-Erweiterung kann aufgegeben werden, selbst wenn die Hauptanwendung überlebt. Der Host hat drei unattraktive Optionen: eine alte Laufzeitumgebung beibehalten, ein Upgrade erzwingen, das Kundenseiten beschädigen könnte, oder Legacy-Workloads isolieren, während genug berechnet wird, um sie sicher zu betreiben.

cPlans aktuelleRichtlinie zum Ende der Lebensdauer von Drittanbieter-Softwaremacht die Anbieterseite explizit. Wenn ein Upstream-Anbieter Updates einstellt, kann cPanel die Software entfernen und die Unterstützung einstellen. Wenn ein Betriebssystem das Ende seiner Lebensdauer erreicht, können bestehende Installationen möglicherweise weiterlaufen, aber Neuinstallationen, Upgrades und betriebssystemspezifische Korrekturen können blockiert werden. In einigen Fällen besteht der empfohlene Weg darin, einen neuen Server bereitzustellen und Konten und Dienstkonfiguration zu migrieren.

FrontPage ist eine besonders konkrete Brücke vom 100-Megs-Katalog zu modernen Migrationsgrenzen. Die Shared-Tarife von 2010 warben noch mit FrontPage 2000-Erweiterungen. Die aktuellecPanel Transfer Tool Dokumentationbesagt, dass cPanel FrontPage nicht unterstützt und FrontPage-spezifische Dateien und Verzeichnisse nicht wiederherstellt; sie empfiehlt dringend, FrontPage vor der Übertragung zu deaktivieren. Eine Funktion, die einst in jeder Tarifspalte aufgeführt war, wurde später zu Daten, die der Standard-Migrationspfad absichtlich zurücklassen würde.

Dies ist Software-Lock-in ohne eine proprietäre Programmiersprache. Der Kunde mag die PHP- und Datenbankinhalte besitzen und dennoch an eine enge Umgebung gebunden sein, weil die gleichzeitige Aktualisierung aller Abhängigkeiten riskant ist. Der Anbieter zieht es möglicherweise vor, die alte Umgebung beizubehalten, weil die Migration Arbeitskraft verbraucht und Support-Anrufe erzeugt. Beide Seiten schieben die Änderung auf, bis eine Sicherheitsfrist, eine Übernahme oder ein Hardware-Wechsel den Zeitplan verdichtet.

Die alte Marke verstärkt die Illusion von Stabilität. Wenn „100 Megs“ noch ans Telefon geht, mag ein Kunde annehmen, der Dienst sei derselbe. In Wirklichkeit erfordert Kontinuität wiederholte Substitutionen: PHP-Zweig für PHP-Zweig, Datenbank-Engine für Datenbank-Engine, Installer für Installer, Zertifikatsprozess für Zertifikatsprozess und Server für Server. Gutes Hosting verbirgt diese Substitutionen vor dem normalen Gebrauch. Gute Governance zeichnet sie auf, damit versteckte Arbeit nicht zu verstecktem Risiko wird.

„Unbegrenzt“ traf auf eine 4-Prozent-Regel

Die 4-Prozent-Ressourcenklausel ist der Punkt, an dem die Marketing-Kapazität auf die Mehrbenutzer-Technik traf. Sie besagte, dass ein Skript oder Prozess eines Shared-Kontos die Richtlinie jederzeit verletzen konnte, selbst wenn der Kunde Speicher oder Datenvolumen nicht erschöpft hatte. Das mag hart klingen, aber eine gewisse Grenze war unvermeidlich. Ein einziger außer Kontrolle geratener Prozess oder eine teure Datenbankabfrage kann Hunderte benachbarter Sites beeinträchtigen.

Das Problem war nicht die Existenz einer Grenze. Es war die Lücke zwischen der Sprache der Tariftabelle und der Betriebsregel. „Unbegrenzte Bandbreite“ ermutigt einen Käufer, in Verkehrsvolumen zu denken. Die AUP regelte CPU, Speicher, Netzwerk- und Speicherverhalten und überließ das Mittel dem Ermessen des Managements. Ein Kunde konnte unter dem sichtbaren Zähler bleiben und dennoch die unsichtbare Grenze überschreiten.

Ein Bericht aus erster Hand von 2009 aufTulsaMJ's Tech Blogsagt, 100 Megs habe geplante Haushaltsskripte ohne Vorankündigung gestoppt, später weitere Skripte gestoppt und schließlich das Konto des Schreibers gesperrt. Der Schreiber sagte, die Sites seien wieder aktiviert und dann woanders hingezogen worden. Es gibt keine Antwort von 100 Megs und keine Server-Telemetrie, daher kann der Bericht nicht zeigen, ob jeder Eingriff gerechtfertigt war. Er ist nützlich, weil er die Unsicherheit des Kunden beschreibt: Die Arbeitslast hing von Skripten ab, deren Betriebsstatus erst offensichtlich wurde, als der Anbieter handelte.

Die korrekte Beschaffungsreaktion ist nicht, einen buchstäblich unbegrenzten Shared-Server zu verlangen. Es ist, nach einer beobachtbaren und abgestuften Ressourcenpolitik zu fragen. Welche Messungen werden verwendet – durchschnittliche CPU, Spitzen-CPU, Speicher, Prozessanzahl, Datenbankzeit oder Eingabe/Ausgabe? Über welches Intervall? Sieht der Kunde sie? Gibt es eine Warnung vor der Sperrung? Kann ein Burst toleriert werden? Wird ein Umzug auf einen virtuellen Server angeboten? Wie schnell können Daten abgerufen werden, wenn das Konto deaktiviert wird?

100 Megs lud Kunden mit Ressourcenfragen ein, jederzeit den Support zu kontaktieren, und die virtuellen und dedizierten Stufen boten einen Upgrade-Pfad. Aber der erfasste VDS-Tarif war ausverkauft. Das legt ein weiteres Kontinuitätsproblem offen: Ein Eskalationspfad auf einer Produktkarte ist nicht nützlich, wenn die Kapazität nicht verfügbar ist, wenn ein wachsender Kunde sie braucht. Ein Käufer sollte nicht nur testen, ob die nächste Stufe existiert, sondern auch, wie die Migration funktioniert, wie lange die Bereitstellung dauert und was passiert, wenn diese Stufe eingeschränkt ist.

Der Name der Marke macht die Lektion ungewöhnlich deutlich. Die Menge, die in einem Namen oder Tarif beworben wird, ist selten die Menge, die den Ausfall bestimmt. Speicher war reichlich vorhanden. Shared-Contention, Kompatibilität und Support-Aufmerksamkeit waren knapp. Moderne „Unlimited“-Angebote wiederholen dasselbe Muster, wenn Fair-Use-Bedingungen, Inode-Zählungen, Worker-Limits oder Datenbank-Obergrenzen außerhalb der Schlagzeile stehen.

Support war Teil der Kontrollebene

100 Megs warb mit 24-Stunden-E-Mail-Support, einem Online-Helpdesk, Ankündigungen und einer Wissensdatenbank. Die Reseller-Vereinbarung teilte den Support bewusst auf: Der Reseller beantwortete zuerst den Kunden, während 100 Megs die Systemadministration und die Second-Level-Probleme übernahm. Dieses Design war keine administrative Dekoration. Es war die Art und Weise, wie die Betriebsbefugnis wanderte.

Betrachten Sie einen fehlgeschlagenen Checkout. Der Reseller könnte die Anwendung und die Zahlungseinstellungen überprüfen. 100 Megs könnte PHP, das Zertifikat oder einen blockierten Prozess überprüfen. Data393 könnte den physischen Eingriff besitzen. Ein Netzwerk-Lieferant könnte einen Routing-Fehler besitzen. Der Kunde jedoch hatte eine einzige Störung. Die Qualität des Dienstes hing davon ab, dass die Diagnose diese Grenzen überschritt, ohne den Kontext zu verlieren.

Die frühen Forumsberichte sind günstig: Ein Kunde nannte den Host „insgesamt gut“, ein anderer sagte, er sei mit Service und Support zufrieden. Der Migrationsbericht von 2009 ist negativ und beschreibt stillschweigende Eingriffe. Keine Seite legt eine durchschnittliche Reaktionszeit oder Vorfallrate fest. Zusammen zeigen sie, warum Testimonials das Support-Design nicht ersetzen können. Ein Host kann zufriedene Nutzer haben und dennoch ein ernstes Risiko für eine Arbeitslast darstellen, die außerhalb der Standardpraxis fällt.

Die Kategorien der Support-Seite – Einrichtung, E-Mail, Abrechnung und Vorverkauf – deuteten auf eine konventionelle, organisierte Oberfläche hin. Was in der öffentlichen Aufzeichnung fehlt, ist ebenso wichtig: keine erhaltene Service-Level-Verpflichtung für Ticket-Bestätigung oder -Wiederherstellung, keine Schweregraddefinitionen, kein veröffentlichter Eskalationspfad und keine klare Abgrenzung der verwalteten Arbeit bei den dedizierten Tarifen. Das Fehlen in diesen Quellen beweist nicht, dass das Unternehmen keine privaten Verfahren hatte. Es bedeutet, dass ein Käufer sie nicht sicher aus der Tariftabelle ableiten konnte.

Für ein KMU sollte Support als Kontrollsystem bewertet werden. Kann der Käufer ein Ticket eröffnen, wenn die Hauptdomain oder das Postfach nicht erreichbar ist? Gibt es einen Out-of-Band-Kontakt? Führt der Anbieter eine zeitgestempelte Änderungshistorie? Kann das Abrechnungspersonal eine automatische Sperrung verhindern, während ein technischer Streit untersucht wird? Kann ein Reseller direkt eskalieren? Wer darf die Wiederherstellung aus dem Backup autorisieren? Welche Beweise werden nach einem Vorfall zurückgegeben?

Der Wert eines kleinen Hosts liegt oft gerade in der menschlichen Hilfe. Der Kunde wählt ihn vielleicht, weil jemand einen Berechtigungsfehler beheben oder eine DNS-Änderung erklären kann. Dieser Vorteil wird nur dann dauerhaft, wenn der Hilfspfad dokumentiert und portabel ist. Wenn alles Betriebswissen in alten Tickets lebt, kann eine Übernahme oder ein Personalwechsel den Kontext löschen, selbst wenn jede Datei überlebt.

Kanadische Identität bedeutete nicht kanadische Daten

Die archivierte Kontaktseite platzierte die Marke in Edmonton. Die Über-uns-Seite platzierte die Infrastruktur in Colorado. Die archivierteDatenschutzerklärungder Site besagte, dass der Anbieter Namen, Adressen, Telefonnummern, Kreditkarteninformationen, Kontostatus, Serviceauswahl, Protokolle, E-Mails und andere Kommunikation im Rahmen des Dienstes sammelte und speicherte. Es hieß, Kundeninformationen könnten mit ausgewählten Partnern geteilt, für Service- und Produktkommunikation verwendet und in bestimmten rechtlichen oder schützenden Umständen offengelegt werden.

Diese Aussagen machen die Geographie operativ. Ein kanadischer Kunde konnte Abrechnungs- und Kommunikationsdaten an eine in Kanada tätige Marke weitergeben, während Website-Inhalte und Serviceprotokolle in den Vereinigten Staaten verarbeitet wurden. Ein Reseller konnte eine weitere Vertragsebene hinzufügen. Eine E-Commerce-Site konnte Zahlungsdienste und Kundenaufzeichnungen einführen, die der Host nicht vollständig kontrollierte.

Aktuelle Leitlinien desOffice of the Privacy Commissioner of Canadabesagen, dass eine Organisation für personenbezogene Daten verantwortlich bleibt, die zur Verarbeitung an einen Dritten übermittelt werden. Bei der Verarbeitung außerhalb Kanadas empfiehlt sie eine Risikobewertung, vergleichbaren Schutz durch vertragliche oder andere Mittel, Nutzungsbeschränkungen und Transparenz über ausländische Zugriffe. Dies sind aktuelle Leitlinien und sollten nicht als rückwirkende Feststellung behandelt werden, dass 100 Megs im Jahr 2010 konform war oder nicht.

Was das historische Material erlaubt, ist eine Beschaffungsschlussfolgerung. „In Kanada ansässig“ war kein ausreichender Nachweis für den Datenstandort. Ein Käufer musste fragen, wo die primäre Site, die Mail, die Bedienfelddaten und die Backups gespeichert waren; welches Unternehmen jede Schicht betrieb; welcher Rechtsprozess auf sie zugreifen konnte; und ob derselbe Standort nach Failover oder Wiederherstellung galt.

Die archivierten AGB verkomplizierten das Bild weiter, indem sie das Recht der Vereinigten Staaten wählten, trotz der in Kanada tätigen Identität. Die Klausel spezifizierte in dem erfassten Text keinen Bundesstaat. Die rechtliche Auslegung würde den vollständigen Vertrag und professionellen Rat erfordern, aber die Diskrepanz selbst war eine Warnung, über die Adresse hinaus zu lesen. Markennationalität, Serverstandort, geltendes Recht und datenschutzrechtliche Verantwortlichkeit sind vier verschiedene Attribute.

Dies bleibt relevant, weil „lokales“ Hosting oft als Vertrauen verkauft wird. Lokaler Support und lokale Abrechnung können wirklich wertvoll sein. Sie implizieren nicht automatisch eine lokale Infrastruktur oder eine einzige Gerichtsbarkeit. Der richtige Test folgt jeder Datenkategorie durch Erhebung, Verarbeitung, Backup, Support-Zugriff, Offenlegung und Löschung. Die eigenen Seiten von 100 Megs enthielten genug Informationen, um die Trennung zu offenbaren, aber ein Kunde musste die Seiten zusammenfügen.

Die Übernahme von 2011 verwandelte Kontinuität in eine Migration

Die Übernahme von Tech Assets im Jahr 2011 ist die entscheidende kommerzielle Änderung. Die Geschichte des Käufers betont wiederholte Hosting-Übernahmen und Migrationsfähigkeit. Er hatte Jumpline 1997 gestartet, seinen Kundenstamm 2002 auf eine virtualisierte Plattform verschoben und eine Reihe von Spezialisten- und cPanel-Hosts übernommen, bevor er 100MegsWebHosting kaufte. Das macht den Kauf als Portfolio-Transaktion lesbar: Der Kundenstamm, die wiederkehrenden Abrechnungen und die cPanel-Arbeitslasten konnten in ein größeres Betriebssystem überführt werden.

Eine Übernahme kann die Kontinuität verbessern. Ein größerer Eigentümer kann neuere Infrastruktur, bessere Kaufkraft, breiteren Support und diszipliniertere Sicherheit bieten. Sie kann auch das kommerzielle Abkommen ändern, während der technische Service online bleibt. Kunden können mit einem neuen Portal, einem neuen Verlängerungszyklus, einem neuen Support-Team, einer neuen Tarifzuordnung oder einem neuen Preis konfrontiert werden.

Die Migration kann im engeren Sinne erfolgreich sein – Dateien und Domains funktionieren noch –, während sie im weiteren Sinne störend wirkt, weil der Dienst nicht mehr dem entspricht, warum der Kunde ihn gekauft hat.

Eine Bewertung vom Juli 2012 auf derWHTop-Seite von Jumplineliefert einen spezifischen Kundenbericht. Der Rezensent sagte, ein Unternehmen, das er „100megs-Domains“ nannte, sei an Jumpline verkauft worden, die gehosteten Domains und Sites seien übertragen worden, die jährliche Hosting-Gebühr sei von 60 $ auf über 130 $ gestiegen und die Domain-Verlängerungskosten seien gestiegen. Der Schreiber sagte, er habe dann die Domains zu einem anderen Registrar und das Hosting woandershin verlegt. Dies ist eine einzige, nicht verifizierte Beschwerde, die auf einer Bewertungsseite veröffentlicht wurde. Sie belegt keine universelle Preisgestaltung, das genaue Migrationsdatum oder eine Vertragsverletzung. Sie bestätigt jedoch auf Kundenebene, dass eine 100-Megs-Arbeitslast nach der dokumentierten Übernahme Jumpline erreichte, und zeigt die Dimensionen, anhand derer der Kunde die Kontinuität beurteilte.

Die Unternehmenskette bewegte sich später erneut. Die aktuelleJumpline-Kundenseitesagt, Jumpline sei Teil der HostPapa-Familie und bietet einen Login-Pfad für bestehende Kunden. Sie sagt, Dateien und Website-Inhalte blieben zugänglich, es gebe keine sofortigen Service- oder Preisänderungen und zukünftige Anpassungen würden mitgeteilt. Diese Seite beweist nicht, dass ein bestimmtes 100-Megs-Konto im Jahr 2026 noch aktiv ist. Sie etabliert die gegenwärtige Nachfolgeoberfläche für Jumpline und zeigt, wie eine Hosting-Marke als Kunden-Zugangstür bestehen bleiben kann, nachdem sich die Eigentumsverhältnisse geändert haben.

Die Bewertung von 2012 ist besonders aufschlussreich, wenn man sie neben den Katalog von 2010 stellt. Der Jahrespreis des Value-Tarifs betrug 50 $ und der des Pro-Tarifs 100 $. Ein gemeldeter Umzug eines Kunden von 60 $ auf über 130 $ wäre nicht nur eine Inflation der Speicherkapazität; es wäre eine Neuzuordnung des gesamten Bündels. Vielleicht enthielt der Nachfolgetarif Funktionen, die der Kunde nicht brauchte. Vielleicht unterschied sich seine Kostenbasis. Die öffentliche Beweislage kann den Grund nicht beurteilen. Was zählt, ist, dass die Wechselkosten dem Nachfolger Raum gaben, das Angebot zu ändern.

Ein Kunde musste Domains, Hosting und Anwendungszustand trennen, bevor der Preiswettbewerb wieder wirksam wurde.

Übernahmeklauseln verdienen dieselbe Aufmerksamkeit wie Backup-Klauseln. Die AGB von 2010 erlaubten 100 Megs, den Vertrag abzutreten, während sie die Möglichkeit des Kunden dazu einschränkten. Diese Asymmetrie ist in Serviceverträgen üblich, aber sie bedeutet, dass der Anbieter die Vertragspartei wechseln kann, ohne dass der Kunde die Arbeitslast ändert. Ein Kontinuitätsplan muss daher auch Unternehmensänderungen sowie Hardware-Ausfälle antizipieren.

Die angemessene Frage ist nicht „Wird dieser Host jemals übernommen?“, sondern „Was können wir unabhängig verschieben, wenn das passiert?“ Domain-Registrierung, DNS-Autorität, anbieterunabhängige Backups, Anwendungsdokumentation und Abrechnungsunterlagen schaffen Verhandlungsmacht. Ohne sie kann selbst eine technisch kompetente Migration den Kunden kommerziell gefangen halten.

Der Ausstieg war eine Dateninventur, kein Download-Button

Die historischen AGB gaben den Kunden eine Backup-Funktion im Bedienfeld, während sie die Regelmäßigkeit und Richtigkeit der Backups des Anbieters ablehnten. Diese Regelung war nur sinnvoll, wenn Kunden tatsächlich ihre eigenen Kopien exportierten und testeten. Ein auf demselben Hosting-Konto verbliebenes Backup war keine Ausgangskopie. Ein vollständiges Archiv, das nur der Host wiederherstellen konnte, war noch kein Wiederherstellungsverfahren.

Die aktuellecPanel-Backup-Dokumentationmacht die Unterscheidung genau. Ein Benutzer kann ein vollständiges Konto-Backup erstellen und herunterladen, auch auf einen entfernten FTP- oder Secure-Copy-Speicher. Aber ein vollständiges Backup kann nicht automatisch über die normale cPanel-Oberfläche wiederhergestellt werden; die automatische Wiederherstellung erfordert WHM und damit in der Regel den Hosting-Anbieter. Die Dokumentation warnt auch, dass die Erstellung eines Backups fehlschlagen kann, wenn ein Konto nahe an seinem Kontingent ist, weil der Prozess Arbeitsplatz benötigt, und dass automatische Konto-Backups nur existieren, wenn der Anbieter sie aktiviert.

Das schafft eine praktische Falle. Der Kunde, der am dringendsten gehen muss, ist möglicherweise nahe am Kontingent, gesperrt oder innerhalb des siebentägigen Kündigungsfensters. Der Anbieter kann das Wiederherstellungswerkzeug kontrollieren. Der richtige Zeitpunkt, den Export zu testen, ist vor einem Konflikt oder Ausfall.

Das aktuelle cPanel Transfer Tool kann Konten, Pakete und Konfigurationen kopieren, wenn der Bediener über ausreichende Berechtigungen verfügt. Es kann DNS und Mail-Routing aktualisieren und eine Live-Übertragung durchführen, die Ausfallzeiten reduzieren soll. Doch seine Dokumentation listet Grenzen auf: Benutzerdefinierte DNS-Vorlagen werden nicht übertragen, Zwei-Faktor-Einstellungen müssen neu konfiguriert werden, Datenbank-Namenskonflikte können eine Umbenennung auslösen, Remote-Mail-Vereinbarungen erfordern Sorgfalt, und FrontPage-spezifische Dateien werden nicht wiederhergestellt.

Selbst eine Übertragung innerhalb derselben Bedienfeld-Familie erfordert daher einen Abgleichsschritt.

Der TulsaMJ-Bericht liefert ein historisches Beispiel für diesen Abgleich. Nach dem Wegzug von 100 Megs im Jahr 2009 dokumentierte der Schreiber, dass PHP bei 100 Megs als Apache-Modul, am Zielort jedoch als CGI lief. Die.htaccess-Handler-Syntax musste geändert werden, und die Feststellung des Unterschieds dauerte Zeit und Support. Die Dateien waren umgezogen; ihr Ausführungskontext nicht.

Ein vollständiges 100-Megs-Ausstiegsinventar hätte mindestens Folgendes enthalten müssen:

  1. Das Registrar-Konto, der Registrantenkontakt, der Übertragungssperrstatus und die Autorisierungsberechtigung für jede Domain.
  2. Jede DNS-Zone und der Ort der autoritativen Nameserver, einschließlich Mail-, Verifikations- und Servicerecords, die nicht von cPanel generiert wurden.
  3. Website-Dateien, versteckte Konfigurationsdateien, Berechtigungen, symbolische Links und geplante Aufgaben.
  4. Jede Datenbank, Benutzer, Berechtigungen und Zeicheneinstellungen sowie eine Konsistenzprüfung auf Anwendungsebene.
  5. Mailboxen, Nachrichten, Aliase, Weiterleitungen, Filter, Mailinglisten, Spam-Einstellungen und die Geräte oder lokalen Archive, die vom POP-Verhalten abhingen.
  6. Private Schlüssel des Zertifikats, Zertifikatskette, Erneuerungsmethode und Nachweis, dass das Ziel HTTPS ausliefern konnte, bevor DNS geändert wurde.
  7. Anwendungsversionen, Erweiterungen, Themes, Lizenzschlüssel, Installationsverlauf und Laufzeitanforderungen.
  8. Verkehrsstatistiken, Zugriffsprotokolle und Fehlerprotokolle, die für die Fehlersuche oder Aufbewahrungspflichten erforderlich sind.
  9. Abrechnungsunterlagen, Support-Tickets, Richtlinienversionen und Nachweis der Kündigung.
  10. Ein Rollback-Fenster, in dem der alte Dienst verfügbar blieb, während die neue Site, Mail und Jobs getestet wurden.

Die Domain-Übertragung ist ein separater Kontrollpfad von der Hosting-Migration. Die aktuelleICANN-Transfer-Policyverlangt von einem Registrar, den AuthInfo-Code der Domain bereitzustellen und eine Übertragungssperre innerhalb von fünf Kalendertagen zu entfernen, wenn kein Self-Service verfügbar ist, vorbehaltlich der Bedingungen der Richtlinie. Sie besagt auch, dass ein Registrar diese Schritte nicht allein wegen einer Zahlungsstreitigkeit zurückhalten kann. Dieser Schutz ist nur nützlich, wenn das Unternehmen weiß, welcher Registrar die Domain hält, den Registrantenkontakt aktuell hält und vor Ablauf oder Krise beginnt.

Mail erfordert besondere Vorsicht. Eine Website kann visuell unter einer temporären Adresse verglichen werden; E-Mail ist verteilter Zustand. Nachrichten können am alten Server ankommen, während DNS-Caches ablaufen. POP-Benutzer können einzigartige lokale Verläufe haben. Weiterleitungen und Filter reproduzieren sich möglicherweise nicht genau. Die Migration benötigt eine Phase paralleler Beobachtung, eine im Voraus eingestellte niedrige DNS-Lebensdauer, Testnachrichten von externen Netzwerken und die Bestätigung, dass die alte Warteschlange leer ist.

Datenbankgesteuerte Shops und Foren erfordern Anwendungskonsistenz. Das Kopieren von Dateien um 12:00 Uhr und einer Datenbank um 13:00 Uhr kann eine Site erzeugen, deren Uploads, Bestellungen und Aufzeichnungen nicht übereinstimmen. Der Kunde benötigt ein Wartungsfenster oder eine Replikationsmethode, einen abschließenden Schreibstopp, Prüfsummen oder Datensatzzählungen und einen Test auf Transaktionsebene am Zielort. Die Verwirrung des osCommerce-Kunden im Jahr 2006 ist eine Erinnerung daran, dass ein technisch installierter Warenkorb kein validierter kommerzieller Workflow ist.

Kündigungsbedingungen verwandeln diese technischen Schritte in Fristen. Die archivierte Vereinbarung erlaubte jeder Partei, mit einer Frist zu kündigen, verhängte in einigen Fällen eine Gebühr für vorzeitige Kündigung und begrenzte das Archivfenster nach der Kündigung. Sie deckelte auch die angegebene Haftung auf 500 $ und schloss Kategorien von Datenverlust, Gewinn und Nutzung aus. Diese historischen Klauseln werden nicht als aktuelle Nachfolgebedingungen dargestellt. Sie zeigen, warum ein Kunde die Haftungsobergrenze des Hosts nicht zu seinem Wiederherstellungsplan machen konnte.

Der stärkste Ausstiegstest ist eine Wiederherstellung, die von einer anderen Person als der, die die Site erstellt hat, unter Verwendung einer außerhalb des Anbieters gespeicherten Kopie durchgeführt wird. Wenn diese Person die Website, Datenbank, den Mail-Fluss, DNS und das Zertifikat innerhalb der erforderlichen Zeit wiederherstellen kann, ist die Portabilität real. Wenn die Übung bei „Wir haben eine tar-Datei heruntergeladen“ endet, hat der Kunde ein Artefakt, keine Kontinuität.

Sicherheitsbehauptungen benötigten Betriebsnachweise

Die archivierte Über-uns-Seite verwendete das Sicherheitsvokabular ihrer Zeit: kontrollierter physischer Zugang, Überwachung, Firewalls, redundante Stromversorgung, Umweltkontrollen und kontinuierliche Überwachung. Die Data393-Ankündigung bestätigt unabhängig mehrere Fähigkeiten auf Einrichtungsebene. Die Datenschutzseite sagte, dass physische, elektronische und verwaltungstechnische Schutzmaßnahmen vorhanden seien. Dies sind relevante Eingaben, aber sie offenbaren keine Patch-Latenz, Zugriffsüberprüfung, Verwundbarkeitsmanagement, Backup-Isolation oder Incident Response.

Die offengelegten Response-Header zeigen, warum die Versionsverwaltung zur Sicherheitsbewertung gehört. Sie gaben Außenstehenden genaue Apache-, PHP-, OpenSSL- und FrontPage-Generationen für die Marketing-Site preis. Versionsstrings allein beweisen keine Exploitierbarkeit; Software kann zurückportiert oder defensiv konfiguriert werden. Sie geben einem Käufer jedoch einen Grund, nach der Lebenszyklus-Politik und kompensierenden Kontrollen zu fragen.

Die Richtlinie zur akzeptablen Nutzung legte dem Kunden erhebliche Sicherheitsverantwortung auf. Sie verbot offene Mail-Relays, unbefugten Zugriff, bösartige Software, störende Aktivitäten und mehrere Formen von Missbrauch. Sie besagte, dass der Anbieter Informationen entfernen oder eine Site abschalten könne, wenn er von schädlichen Aktivitäten erfuhr. Solche Befugnisse können Nachbarn auf einem gemeinsam genutzten Server schützen, aber sie machen auch Hinweise, Beweissicherung und Einspruchsverfahren wichtig für ein legitimes Unternehmen, das von einem Fehlalarm betroffen ist.

Keine zuverlässige öffentliche Quelle, die hier verwendet wird, belegt eine unternehmensspezifische Sicherheitszertifizierung, unabhängig gemessene Betriebszeit, Vorgeschichte von Sicherheitsvorfällen oder Vorfallrate für 100 Megs. Das ist eine Beweislücke, kein Beweis, dass kein Vorfall stattgefunden hat. Das Archiv kann auch nicht zeigen, wie oft Backups erfolgreich wiederhergestellt wurden oder wie schnell der Support mit Missbrauchsmeldungen umging.

Ein Käufer in dieser Position sollte eher Betriebsnachweise als Adjektive verlangen: unterstützte Laufzeitversionen; Patch- und Notfalländerungsfenster; Trennung zwischen Kundenkonten; privilegierte Zugriffskontrollen; Malware- und ausgehende Mail-Überwachung; Backup-Verschlüsselung und -Unveränderlichkeit; Wiederherstellungstestergebnisse; Benachrichtigungspflichten; und die Einrichtungs-, Netzwerk- und Support-Unternehmen, die auf Daten zugreifen können. Wenn sich der Anbieter auf eine Rechenzentrumszertifizierung stützt, sollte der Käufer fragen, welche Dienste und Kontrollen sie abdeckt.

Ein zertifiziertes Gebäude zertifiziert nicht die PHP-Anwendung des Kunden.

Bei E-Commerce muss die Aufgabenteilung besonders klar sein. Der Host kann HTTPS und einen Anwendungsinstaller bereitstellen. Er validiert damit nicht den Warenkorb, die Zahlungsintegration, die Administrator-Passwörter oder die Datenaufbewahrungsentscheidungen. Der Kunde sollte Zahlungsdaten minimieren, ein Zahlungsdesign verwenden, das seinen Compliance-Verpflichtungen entspricht, Anwendungen unterstützt halten und den vollständigen Checkout- und Rückerstattungspfad nach jeder wesentlichen Änderung überprüfen.

Sicherheit und Portabilität verstärken sich gegenseitig. Ein Anbieter muss möglicherweise eine veraltete Komponente aus Sicherheitsgründen entfernen. Ein Kunde, der testen und migrieren kann, hat Spielraum für ein Upgrade. Ein Kunde, der auf einer alten Laufzeit festsitzt, übt Druck auf den Anbieter aus, das Risiko zu bewahren. Die beste Investition in die Kontinuität ist oft dieselbe wie die beste Investition in die Sicherheit: dokumentierte Abhängigkeiten, aktuelle Software, reproduzierbare Konfiguration und getestete Wiederherstellung.

Ein Beschaffungstest, der aus der 100-Megs-Aufzeichnung entwickelt wurde

Der moderne Käufer, der zwischen Shared Hosting, verwaltetem Anwendungs-Hosting, einem virtuellen Server, einer dedizierten Maschine oder einer größeren Cloud-Plattform wählt, sollte nicht fragen, welche Kategorie inhärent am besten ist. Jede verschiebt Arbeit und Kontrolle. Shared Hosting standardisiert den Betrieb zu geringen Kosten, schränkt aber Ressourcen und Versionen ein. Verwaltetes Anwendungs-Hosting kann die Patch-Arbeit reduzieren, schränkt aber die unterstützten Erweiterungen ein. Ein virtueller Server erhöht die Kontrolle und Administration.

Dedizierte Hardware isoliert die Kapazität, bietet aber nicht automatisch Ausfallsicherheit. Eine breite Cloud-Plattform bietet viele Bausteine, macht aber die Architektur und das Kostenmanagement zur Verantwortung des Kunden.

100 Megs selbst verkaufte mehrere dieser Stufen, was seine Aufzeichnung zu einem nützlichen Beschaffungstest macht. Ein Käufer kann jede verlockende Behauptung aus dem Katalog von 2010 nehmen und nach der Betriebstatsache darunter fragen.

Identität und Vertragspartner.Welches genaue rechtliche Unternehmen unterzeichnet den Vertrag und stellt dem Kunden die Rechnung? Welche öffentliche Marke liefert den Support? Darf die Vereinbarung abgetreten werden? Die Marke 100 Megs ist gut belegt, aber ihre rechtliche Hülle vor der Übernahme ist es nicht. Diese Unterscheidung sollte geklärt werden, bevor Geld oder regulierte Daten bewegt werden.

Domain-Kontrolle.Ist der Kunde der Registrant mit unabhängigen Zugangsdaten und Wiederherstellungskontakten? Kann die Domain ohne ein aktives Hosting-Konto übertragen werden? Eine Site, deren Domain und Hosting gemeinsam ausfallen, hat zwei Abhängigkeiten in eine verwandelt.

Standort und Lieferanten.Wo werden Primärdaten, Mails, Protokolle und Backups verarbeitet? Wem gehören die Einrichtung und das Netzwerk? Welche Standorte werden bei der Wiederherstellung genutzt? 100 Megs war in Kanada tätig und in Colorado gehostet; keine Tatsache hob die andere auf.

Kapazität und Durchsetzung.Was schließt „unbegrenzt“ aus? Welche CPU-, Speicher-, Prozess-, Dateianzahl-, Datenbank- und Mail-Grenzen gelten? Wie werden sie gemessen und sichtbar gemacht? Die 4-Prozent-Regel war wichtiger als die Datenvolumen-Schlagzeile des Ultra-Tarifs.

Lebenszyklus.Welche PHP-, Datenbank-, Betriebssystem- und Bedienfeldversionen werden angeboten, wann werden sie eingestellt und wer bezahlt für die Behebung? Kann ein Kunde einen Staging-Betrieb gegen die nächste Version durchführen? Das Vorhandensein von PHP, MySQL und FrontPage in einer Funktionsliste war nur der Anfang der Verpflichtung.

Anwendungsgrenze.Deckt „managed“ das Betriebssystem, das Bedienfeld, die Open-Source-Anwendung, Erweiterungen, die Leistungsoptimierung und die Wiederherstellung ab oder nur einige davon? Welche Änderungen erfordern einen kostenpflichtigen Einsatz? Die 100-Megs-Dedicated-Seite warb mit Support und verwalteten Ergänzungen, ohne genügend Details zu bewahren, um die Grenze zu bepreisen.

Support-Design.Was sind die Bestätigungs- und Wiederherstellungsziele nach Schweregrad? Gibt es einen Out-of-Band-Weg? Wer besitzt die erste und zweite Linie? Sind Ticketverläufe exportierbar? Die Reseller-Seite legte ihre Zweischicht-Anordnung nützlich offen; ein Käufer bräuchte dennoch Eskalationszeiten.

Backup und Wiederherstellung.Ist die Kopie außerhalb des Produktionskontos und der Fehlerdomäne? Wie lange wird sie aufbewahrt? Kann der Kunde ohne Anbieterrechte wiederherstellen? Werden Datenbanken konsistent erfasst? Das siebentägige Nach-Kündigungs-Archiv und die Nicht-Garantie machen diesen Test unverhandelbar.

Migration.Welche Komponenten werden automatisch übertragen und welche erfordern manuelle Arbeit? Kann der Käufer eine Live-Probe durchführen? Sind DNS, Mail, geplante Aufgaben, Zertifikate, Zwei-Faktor-Einstellungen und alte Erweiterungen enthalten? Die eigene Dokumentation von cPanel zeigt, warum „cPanel zu cPanel“ nicht mit vollständig gleichzusetzen ist.

Preisgestaltung im Zeitverlauf.Was ist der Preis für die erste Laufzeit, die Verlängerung und die Migration? Welche Artikel sind heute optional, aber in der Praxis erforderlich – benutzerdefiniertes SSL, Backups, Sicherheit, dedizierte Adressen oder Support? Wie werden übernommene Konten auf neue Tarife abgebildet? Die Jumpline-Beschwerde von 2012 ist keine Preisliste, aber sie identifiziert das Risiko.

Ausstieg und Löschung.Wie viel Vorlauf ist nötig, wann endet der Zugang, welche Gebühren fallen an und wann werden primäre und Backup-Kopien gelöscht? Kann der Kunde Protokolle und Tickets nach der Kündigung abrufen? Die historischen AGB machten den Zugang zeitlich begrenzt und die Haftung des Anbieters begrenzt.

Dieser Test verdeutlicht auch den Wettbewerb. Ein Konkurrent, der weniger Speicher, aber transparente Ressourcen-Telemetrie, unterstützte Laufzeiten und eine bewährte Wiederherstellung bietet, kann betriebswirtschaftlich günstiger sein. Ein Konkurrent mit einer niedrigen Einführungsgebühr, aber teurer Verlängerung, proprietärem Site-Builder und host-kontrollierter Domain kann teurer sein. Ein virtueller Server kann eine Form der Einschränkung reduzieren, während die Kosten für Sicherheit und Verwaltung steigen. Der Vergleich sollte neben der Rechnung auch Personalzeit, erwartete Migrationen und Ausfallzeiten berücksichtigen.

Für ein KMU sind die Wechselkosten oft asymmetrisch. Der Beitritt dauert Minuten, weil der Host die Einrichtung automatisiert. Der Abschied dauert Tage, weil der Kunde Jahre angesammelten Zustand wiederentdecken muss. Die Beschaffung sollte diese Asymmetrie vor der Unterzeichnung umkehren: ein Beispielkonto exportieren, das Archiv prüfen, es anderswo wiederherstellen, eine Testdomain übertragen, Mail-Regeln reproduzieren und aufzeichnen, wie lange der Support für eine Antwort braucht. Ein Anbieter, der sich seiner Kontinuität sicher ist, sollte in der Lage sein, die Übung zu erklären.

Derselbe Test gilt nach einer Übernahme. Vertrag, Support-Kontakte, Datenstandorte, Laufzeit-Roadmap, Backup-Zugriff, Verlängerungspreis und Kündigungsverfahren neu validieren. Gehen Sie nicht davon aus, dass eine funktionierende Startseite beweist, dass jede Abhängigkeit überlebt hat. Der Bericht von 100 Megs zu Jumpline deutet darauf hin, dass technische Übertragung und kommerzielle Zufriedenheit auseinanderklaffen können.

Was wissbar bleibt – und was beobachtet werden sollte

Die genaue Unternehmensgeschichte hat feste Anker und echte Lücken. Fest: Die Domain wurde 2001 registriert; Benutzer beschrieben den Dienst 2002; die Marke veröffentlichte 2009–2010 einen detaillierten kanadischen Kontakt und einen in Colorado gehosteten Katalog; der Dienst bot Shared-, Reseller-, Virtual- und Dedicated-Tarife rund um cPanel an; Tech Assets gibt an, die Marke 2011 übernommen zu haben; ein späterer Kunde beschrieb den Transfer zu Jumpline; und Jumpline präsentiert heute HostPapa als seine Mutteroberfläche.

Unbewiesen: die vollständige rechtliche Identität vor der Übernahme, die behauptete Kundenanzahl, der Umsatz, die Mitarbeiterzahl, die Anzahl und Auslastung der Server, der Besitz von Netzwerkressourcen, die gemessene Betriebszeit, die Häufigkeit von Sperrungen, erfolgreiche Wiederherstellungsraten und ob irgendein ursprüngliches 100-Megs-Kundenkonto heute noch aktiv ist. Dies sind nicht nur dekorative Auslassungen. Sie definieren, wie stark die Geschichte genutzt werden kann.

Die aktuelle Domain-Registrierung sollte als Kontinuitätssignal beobachtet werden, nicht mit einem operativen Unternehmen verwechselt werden. Eine registrierte Domain kann auf einen Nachfolger, einen inaktiven Dienst oder eine Platzhalterseite verweisen. Die sinnvollen Fragen sind, ob alte Kunden noch einen authentifizierten Weg zu Kontodaten haben, welche Bedingungen jetzt für sie gelten, welche Laufzeitversionen noch vorhanden sind und ob der Nachfolger einen vollständigen Export erstellen kann.

Die Nachfolgekette verdient ebenfalls Überwachung. Die aktuelle Jumpline-Seite verspricht fortgesetzten Zugang und frühzeitige Mitteilung über wesentliche Änderungen. Käufer mit geerbten Konten sollten Kopien dieser Mitteilungen aufbewahren, Tarif- und Verlängerungsbedingungen vergleichen, Backups vor Plattformänderungen testen und sicherstellen, dass die Domain-Registrierung nicht stillschweigend mit dem Hosting gebündelt ist. Der Moment vor einer geplanten Migration ist der günstigste Zeitpunkt, um eine nicht unterstützte Komponente zu finden.

Für Historiker des Hostings könnten weitere Primäraufzeichnungen die rechtlichen und operativen Lücken schließen: Handelsnamen- und Gesellschaftseinträge in Alberta, vollständige Vor-Übernahme-Verträge, archivierte Routing-Aufzeichnungen, Kundenrechnungen, Übernahmemitteilungen und Support-Kommunikation. Bis solche Aufzeichnungen erscheinen, sollten sie nicht durch Aggregatorschätzungen oder Annahmen ersetzt werden, die vom Wort „Megs“ abgeleitet sind.

Die tiefere Lektion der Marke hängt nicht davon ab, diese Lücken zu füllen. Bis 2010 beschrieb 100 Megabyte nicht einmal mehr den kleinsten beworbenen Tarif. Das Versprechen überlebte, weil es zu einem Namen geworden war. Was die Kunden tatsächlich kauften, war die kontinuierliche Ausrichtung vieler beweglicher Teile: Software, die noch lief, eine Domain, die noch aufgelöst wurde, Mails, die noch ankamen, eine Datenbank, die noch zu den Dateien passte, Support, der die richtige Schicht erreichen konnte, und ein Backup, das irgendwo anders zu einem funktionierenden Dienst werden konnte.

Kapazität wächst fast automatisch. Kontinuität tut das nicht. Sie muss in Eigentum, Verträge, Architektur und Proben einbezogen werden. Die Sieben-Tage-Archiv-Klausel machte das 2010 sichtbar, und die Übernahme tat es 2011 erneut. Eine Hosting-Marke kann eine alte Zahl jahrzehntelang tragen. Ihre Kunden sollten etwas Nützlicheres tragen: die getestete Fähigkeit zu gehen.