Seven Days After “Unlimited”: The 100 Megs Web Hosting Continuity Test

Summary

• The exact entity is supportable as a Canadian web-hosting brand using 100megswebhosting.com, with a public Edmonton contact address, customer traces from 2002, an archived 2009–2010 service catalogue and a documented 2011 acquisition by Tech Assets. The available record does not establish a particular federal corporation or a company-owned network.
• By 2010, the brand name had ceased to describe the product: shared plans advertised 10GB to 250GB of disk, one plan advertised unlimited transfer, and dedicated offers advertised 2,000GB. The binding limits sat elsewhere—in a 4 per cent shared-server resource rule, software compatibility, support discretion and cancellation terms.
• The catalogue sold a complete small-business workflow through cPanel, PHP, MySQL, email, SSL, scheduled tasks, application installers and backups. That convenience also concentrated switching costs because a usable site depended on much more than copying its public files.
• The 2011 sale and a later customer's account of migration and higher charges illustrate the commercial side of continuity risk. An acquisition can preserve service while changing the price, support path and incentives around a workload.
• The practical procurement lesson is to test ownership, runtime lifecycle, resource policy, restoreability, data location and exit before buying. Capacity is cheap to rename; rehearsed portability is harder to fake.

The most important number was seven

The most consequential number in the surviving 100 Megs Web Hosting material is not 100. It is seven.

In a 2010 archived terms record, the provider said it kept an account archive for only seven days after cancellation. Reinstatement during that interval could carry a $50 charge, while the customer remained responsible for maintaining backups. The same terms said the provider might be able to restore automatically archived files, but did not guarantee that a backup would exist, be accurate or be produced regularly. Those clauses defined the real perimeter of the service more clearly than any disk quota did. A customer could buy hundreds of gigabytes and still have one week in which to discover that the copy needed for departure was incomplete.

That contrast is the key to understanding 100 Megs Web Hosting Services. The BTW directory entry supplies the exact entity name and canonical directory connection. The company's own archived pages generally shortened the trading style to “100 Megs Web Hosting” or “100Megs Web Hosting.” The number in that name sounded concrete. It evoked an era when a hosting offer could be differentiated by a quantity that now appears tiny. Yet by August 2010 the company's least expensive shared plan advertised 10GB of disk—one hundred times the quantity suggested by the brand—and the largest advertised 250GB. The dedicated offers went further. The old number had become a memory aid, not a specification.

This is not merely an amusing story about technological inflation. A frozen brand can conceal how many other promises have changed around it. Storage expands. Transfer allowances become “unlimited.” The application installer swaps one software catalogue for another. PHP and database versions advance. A control panel removes an old feature. A data-centre owner changes. A hosting company is acquired. The customer still sees the same domain and familiar login, but the operating bargain underneath may have moved several times.

The evidence is unusually revealing because the surviving catalogue joins four views that are often separated: advertised capacity, the actual software stack, the provider's enforcement policy and accounts from customers. Read together, they show that hosting was a coordination service. It joined a domain name, DNS, files, databases, mailboxes, certificates, scheduled jobs, application versions, resource limits, support queues and billing rules. The customer did not experience those as separate technologies. The customer experienced a website that either continued to trade, publish and receive mail or did not.

That is why seven days matters. It turns “backup included” from a feature into a question: included for whom, retained where, restorable by whom, and available for how long after the commercial tie ends? The same question applies to every other item in the bundle. “Unlimited” is not a capacity answer until the acceptable-use rule is read. “cPanel migration” is not an exit answer until unsupported extensions, databases, DNS records and mail routing are tested. “Canadian hosting” is not a location answer until the physical facility and cross-border processing are identified.

100 Megs is therefore valuable not because it was huge—it was not proved to be—or because the name establishes any particular network capacity—it does not. It is valuable because the record catches a small hosting brand at the moment when raw allotments were becoming abundant but operational continuity remained scarce.

Proving the brand without inventing a corporation

The first discipline is identity. “100 megs” is a unit-like phrase and could describe storage, transfer or line speed. It cannot by itself prove a business, much less its scale. The supportable identity rests instead on a chain of company-specific records.

The registry record for 100MEGSWEBHOSTING.COM gives a creation date of March 16, 2001. A domain registration does not prove that service began that day, but it establishes a lower boundary for the exact web identity. Independent customer discussion then places the service in use in 2002. In an October 2002 PHPBuilder thread, a entity said they hosted on a 100megswebhosting account and described an “advanced” plan at $20 per month with 1GB of storage, 10GB of monthly transfer, CGI, PHP, MySQL, a control panel, installable scripts, statistics and error logs. Another October 2002 Straight Dope discussion contains a customer saying they hosted a site with 100 Megs Web Hosting and were happy with the service and support. These are user statements, not audited company records, but they independently place the exact domain and service name in the market.

The company's archived About record, captured in July 2009, called 100 Megs Web Hosting a Canadian-based company. It claimed more than eight years of industry experience and a customer base in the thousands. The first claim is broadly consistent with the 2001 domain registration and 2002 customer traces. The customer-count claim is not independently verified and should not be used as a measure of scale. The archived Contact record, captured in August 2010, displayed the exact brand, support and billing addresses at the domain, and a street address at 1131, 9363 Simpson Drive in Edmonton, Alberta. It also used the site footer “100Megs Web Hosting.” Together, these pages prove a Canadian public-facing brand and operating contact, not merely a descriptive directory label.

The endpoint of the independent-brand period is clearer. Tech Assets says in its corporate history that it acquired “100MegsWebHosting” in 2011 and describes it as a popular cPanel host. The spelling compresses the spaces, as the domain did, but the cPanel description, exact name string and timing match the archived service. That is a direct corporate bridge. It also fits a 2012 customer's later statement that accounts and sites associated with “100megs domains” had moved to Jumpline, Tech Assets' original hosting brand.

There is an important limit. A search of the official Corporations Canada federal database for the exact name returned no match during this research. The database itself warns that it excludes provincial and territorial corporations, financial corporations and foreign corporations. A zero result therefore cannot prove that no legal business existed. It means only that the public evidence assembled here does not justify naming a federally incorporated owner. Nor does the archived site consistently append “Inc.” or a corporation number. The defensible formulation is that 100 Megs Web Hosting Services was a Canadian operating brand, publicly reachable through an Edmonton address, whose exact legal owner before the 2011 sale remains unconfirmed in the sources used here.

The documented operating window should be bounded just as carefully. The domain was created in 2001. Customers discussed using the service in 2002. Company pages survive from 2009 and 2010. Tech Assets records an acquisition in 2011. That supports an active period from at least 2002 through 2011, with the domain evidence suggesting preparation or launch by 2001. It does not support a claim about a late-1990s predecessor, a precise founding day, annual revenue, headcount or the number of servers. Those attractive-looking details appear in weak listings and self-reported biographies, but the reliable bridge does not require them.

This narrower identity is still enough to study the company. Brands are real commercial surfaces even when their legal wrapper is obscure. Customers paid the brand, opened support tickets under the brand, used its nameservers and control panel, relied on its policies and later encountered a successor. The analytical mistake would be to turn that reality into false corporate precision.

A Canadian storefront on a Colorado operating surface

The archived site drew a clean distinction between where the seller presented itself and where the machines ran. Its About page said the network was housed in Data393's Denver Tech Center facility in Englewood, Colorado. It advertised redundant utility and generator power, environmental controls, fire detection, biometric and card access, video surveillance and locked cabinets. On connectivity, it named Savvis and Internap, described a nearby Internap connection, and listed Fortigate firewalls and HP ProCurve switching. It also said servers were monitored around the clock and that its normal configuration used Red Hat Linux.

Most of those details are company claims. They should not be converted into an uptime finding or a certification. There is, however, independent confirmation that the named facility and its broad physical capabilities existed at the relevant time. A July 2008 Data393 announcement reported a 10,000-square-foot expansion at its Denver Tech Center site, taking raised-floor space to about 30,000 square feet. It described high-density power and cooling, six parallel 600kW generators with N+1 redundancy, cabinet and cage colocation, and the December 2007 acquisition of Data393 by Managed Data Holdings. Because this is a release from the facility operator, it corroborates the facility rather than independently proving every 100 Megs configuration inside it.

The archive supplies one more technical connection. Common Crawl fetched the 2009 and 2010 company pages from 209.197.254.38. The current ARIN RDAP record for that address places it within the assignment named D393-ENG01-209-197-254-0-25. The present registrant is not 100 Megs, and a current record cannot reconstruct the assignment as it stood in 2010. The D393 naming is consistent with the archived Data393 account, but it is corroboration of location, not proof that 100 Megs owned the address block.

No company-specific autonomous system or direct address allocation is established by this record. That absence matters. Small hosting providers frequently rented cabinets, servers, transit or managed services from a larger facility and network operator. Their value lay in packaging and operating the customer layer, not owning fibre or announcing routes. The archived site itself spoke of its network and its servers in marketing language, but the more cautious interpretation is that 100 Megs controlled a hosting service delivered over infrastructure and connectivity supplied by others.

This dependency structure changes how scale should be read. A provider can serve many domains without owning a data centre. It can advertise multiple upstream paths without holding its own network number. It can offer a dedicated server while renting the rack, power and transit beneath it. None of that makes the service unreal. It means procurement must separate operational responsibility from asset ownership. If power fails, who holds the facility contract? If an upstream route degrades, who can change it? If the reseller's support team sees an issue, which supplier actually touches the switch or server?

The brand owns the customer promise even when another company owns the operating floor.

The Canadian–Colorado split also anticipates a modern cloud question: jurisdiction follows data and contracts, not slogans. “Canadian based” told buyers where the provider identified itself. “Data center locations in Denver serving the world,” used in the site's own metadata, told them something different about processing. Both could be true. Neither alone answered which law governed a dispute, where backups sat, or which subcontractors could access customer information. Those answers were dispersed across the terms, privacy page and infrastructure description.

What the catalogue actually sold in 2010

The archived shared-hosting page set out three plans in August 2010. Value cost $5 monthly or $50 yearly, with 10GB of disk, 50GB of transfer and one hosted domain. Pro cost $10 monthly or $100 yearly, with 100GB of disk, 250GB of transfer and five domains. Ultra cost $20 monthly or $200 yearly, with 250GB of disk, “unlimited” transfer and 30 domains. The page did not establish a currency in the captured table, so the safe description is dollar-denominated pricing rather than an assumption about Canadian or US dollars.

The progression reveals the period's shared-hosting logic. Each step bought more than capacity. Value included two MySQL databases and five POP mailboxes; Pro raised those to ten databases and 25 mailboxes; Ultra advertised both as unlimited. All three included cPanel, CGI, Perl, PHP, FrontPage 2000 extensions, shared SSL, a shopping cart, statistics, scheduled tasks, spam filtering, a site builder, web-based backup, daily backup and Fantastico. Custom SSL and shell access appeared only as optional features on the larger plans. WebHost Manager access was also optional on Pro and Ultra.

The provider offered to move existing customers to a comparable new plan on request, an early acknowledgement that even a plan-table redesign could require an operational transition.

Fantastico made the hosting account look like an application store before that phrase became common. The archived page listed WordPress, Drupal, Joomla, Mambo, phpBB2, Simple Machines Forum, osCommerce, Zen Cart, CubeCart, support desks, project tools, wikis, billing programs and surveys. A small organisation did not have to procure each component separately. It could choose a script, let the installer lay down files and a database, connect mail and a domain, and begin publishing or selling.

Above shared hosting sat a virtual dedicated server page. It offered a “VDS Power 300” at $60 per month with 10GB of disk, 300GB of transfer, 256MB of memory, a 600MHz processor allocation, CentOS, root access, cPanel and WHM, unlimited domains and Fantastico. The captured page marked the plan sold out. That detail is more informative than a generic availability claim: the provider had constructed an upgrade rung but was not offering capacity on it at that moment.

The dedicated-server page offered three configurations. A plan named Cloud was listed at $135 per month with a 400GB disk, 1GB of memory and a single 2.2GHz Intel processor. Premium was $199 with two 500GB disks, 2GB of memory and a 2.4GHz Core 2 Duo. Enterprise was $349 with two 500GB disks, 2GB of memory and two dual-core 2.8GHz Xeons. All advertised 2,000GB of transfer, daily backups, unlimited domains, cPanel and WHM, root access, Fantastico, no setup charge and a 30-day guarantee.

The name “Cloud” should not be read as proof of elastic or distributed architecture. On the page it was simply the entry dedicated configuration. No evidence there describes automated failover, consumption billing, an application interface or rapid horizontal scaling. The company also advertised Linux choice and named Savvis, Internap and Level 3 in connection with the dedicated service, but did not publish routing measurements or a service-level calculation in the captured material.

The reseller offer completed the catalogue. A reseller could sell the three shared plans under its own name at 25 per cent below retail, set the end-customer price and use WebHost Manager and private nameservers. The reseller handled first-line support; 100 Megs supplied system administration and second-line help. There was no requirement to buy a large block in advance, and the provider said it updated reseller billing monthly.

Taken together, these were not four unrelated products. They were an escalation path. A customer could begin on a low-cost shared account, add domains and databases, become a reseller, seek a virtual server for control, or move to a dedicated machine. cPanel and the familiar application catalogue reduced the visible distance between tiers. That continuity was commercially useful, but it also kept the customer's operating knowledge tied to one family of tools and conventions.

Hosting economics hid behind generous quotas

The shared plans look startlingly generous relative to their prices, especially the 250GB Ultra account. But disk was only one input, and rarely the binding one. A hosting company could allocate far more nominal disk and transfer than every customer would use simultaneously. What it could not ignore was peak processor demand, memory pressure, database contention, mail reputation, support labour, backup storage and the operational risk introduced by vulnerable scripts.

100 Megs made that distinction explicit in its archived acceptable-use policy. A script or process on the shared platform was prohibited from using more than 4 per cent of available system resources at any time. The rule applied even when the customer remained within disk and transfer allowances. The provider reserved discretion over the response and warned that services were intended for website material rather than unrelated archives, software packages or large media files.

Thus “unlimited bandwidth” did not mean unlimited computing or unrestricted storage use. It meant the provider had removed one meter from the plan table while retaining controls elsewhere. The economic bargain was probabilistic: most sites would be quiet most of the time; a small number of busy or inefficient applications could threaten the shared server; management reserved the ability to intervene. The buyer who compared only gigabytes missed the variable most likely to interrupt service.

The reseller offer sharpened the same economics. A 25 per cent wholesale discount created room for sales and support, but the reseller accepted first-line responsibility. Every confusing mail setting, password reset and application failure could consume that margin. 100 Megs kept the system-administration layer, where economies of scale were strongest. The reseller kept the customer conversation, where costs were volatile and hard to automate.

cPanel itself has since made another cost driver more visible. Its current licensing guide says licence pricing is based on the number of accounts on a server, with tiers and per-account treatment above specified thresholds. That is a present-day policy, not evidence of 100 Megs' 2010 licence bill. It nevertheless shows how a control panel that simplifies multi-tenant operations can become a unit of cost in its own right. A provider's economics change when the management layer, security extensions, backup storage and support are priced per account while customers still expect low flat fees.

The dedicated tier shifted some constraints rather than eliminating them. Root access reduced the host's control over installed software. It also transferred more responsibility to the customer. The page advertised managed additions and support, but it did not define which updates, incident response or application repairs were included in the base price. Two customers paying for identical hardware could generate very different support costs depending on their applications and skills.

The durable lesson is that cheap capacity can coexist with expensive continuity. The provider earns a margin by standardising common tasks and controlling exceptional use. The customer earns value by avoiding server administration. Friction appears where each side believes the other owns the exception: a busy script, an obsolete application, a failed restore, a mail blacklist, a custom certificate or a migration that does not fit the normal tool.

The customer workflow was a chain, not a folder

A small-business website on 100 Megs could begin with a deceptively simple action: point a domain at the provider and upload files. The catalogue then invited the customer to add layers. Create a MySQL database. Install WordPress, a forum or a shopping cart through Fantastico. Add POP mailboxes and forwarding rules. Schedule a maintenance script. Enable a certificate. Read traffic statistics. Back up through the control panel. Perhaps host several domains, then resell accounts to clients.

Each step was convenient because cPanel presented it in one place. Each also created state that had to be understood during an outage or departure. The public files were only one portion. A dynamic site needed database contents and credentials. Mail continuity depended on mailbox data, aliases, forwarders, filters and MX records. Scheduled jobs lived outside the document tree. Certificate keys and renewal procedures had their own lifecycle. A forum or shop depended on the precise behaviour of PHP extensions, file permissions and database versions. Domain control could sit with the host, a reseller or the customer.

Contemporary customer traces show this bundle in use. The 2002 PHPBuilder entity did not praise disk alone; they listed PHP, MySQL, the control panel, installable scripts, statistics, error logs and access controls. The Straight Dope customer likewise evaluated service and support alongside capacity. Those accounts are subjective, but they demonstrate what buyers considered the product.

An April 2006 osCommerce forum discussion illustrates the edge of the managed experience. A user identified 100 Megs as the host and described being directed toward an osCommerce installation after an SSL renewal problem affected an existing cart. The user was then unsure how merchant-account and payment settings fit together. It is one customer's account, with no provider response, so it cannot establish a general service failure. It does show how a host-supplied installer could make deployment easy while leaving business-critical configuration to the customer.

The same complexity appeared in mundane changes. A site that parsed PHP inside files ending in .html could work because Apache treated those files through a particular handler. Change the way PHP runs and the pages can expose code or stop executing. A scheduled housekeeping script can be essential even if no visitor sees it. An outgoing-mail rule can break order confirmations while the website remains visibly online. A domain can continue resolving to a static page while the billing system, cart or mailbox behind it has failed.

This chain explains why “migration included” is not self-defining. A transfer can copy account files and still omit a registrar credential, an external DNS zone, a third-party payment setting, an unsupported FrontPage component or a local mail archive. It can preserve data but change timing, permissions or character handling. It can move the website and leave the old mail server accepting messages. The customer needs a dependency map, not merely a compressed home directory.

The archived support page reveals that 100 Megs had a ticket system, announcements and a knowledge base divided into pre-sales, billing, email and setup categories. That is the shape of a company trying to turn a heterogeneous chain into repeatable requests. Yet the category names also reveal the handoffs: a billing problem and a mail-routing problem may have the same symptom to the customer—service has stopped—but travel through different queues and require different authority.

For an SME, the highest-value hosting capability is therefore not the largest allotment. It is a maintained inventory of everything required for the business outcome. The site, mail, domain, database, certificate, scheduled work and third-party connections must have named owners and export paths. 100 Megs' catalogue made all of them accessible. Its policies made clear that responsibility for preserving them did not disappear.

The software stack carried expiry dates the brand did not

The Common Crawl captures expose more than page copy. Their HTTP response headers identify the software presenting the company's own site. The July 2009 About response reported Apache 1.3.41, PHP 4.4.9, FrontPage 5.0.2 extensions, OpenSSL 0.9.7a and associated modules. By August 2010, the captured service pages still reported Apache 1.3.41 and the same FrontPage and OpenSSL generations, while PHP had moved to 5.2.11.

Those observations describe the server that returned the marketing pages, not necessarily every customer machine. They do not prove that a particular customer application was vulnerable or that patches were absent. They do prove something more basic: the service depended on versioned components that could not remain still simply because the brand did.

PHP's current support policy gives each release branch two years of full support followed by two years of critical security support before end of life. Today's WordPress requirements recommend PHP 8.3 or later, MariaDB 10.11 or MySQL 8.0 or later, and HTTPS. WordPress warns that legacy PHP 7.4 and MySQL 5.5.5 may still run but are out of support and may expose a site to security risk. These current baselines should not be projected backwards as a verdict on a 2010 host. They show the distance a long-lived customer estate must travel.

The migration is not a straight version-number upgrade. Applications written for PHP 4 or PHP 5 may rely on removed functions, loose error handling, old database libraries or assumptions about how strings and variables behave. A forum theme or shopping-cart extension can be abandoned even while the main application survives. The host has three unattractive choices: retain an old runtime, force an upgrade that may break customer sites, or isolate legacy workloads while charging enough to operate them safely.

cPanel's current third-party end-of-life policy makes the provider side explicit. When an upstream vendor stops updates, cPanel can remove the software and stop supporting it. When an operating system reaches end of life, existing installations may continue to run, but fresh installs, upgrades and operating-system-specific fixes can be blocked. In some cases the recommended path is to provision a new server and migrate accounts and service configuration.

FrontPage is a particularly concrete bridge from the 100 Megs catalogue to modern migration limits. The 2010 shared plans still advertised FrontPage 2000 extensions. The current cPanel Transfer Tool documentation says cPanel does not support FrontPage and does not restore FrontPage-specific files and directories; it strongly recommends disabling FrontPage before transfer. A feature once printed in every plan column later became data the standard migration path would intentionally leave behind.

This is software lock-in without a proprietary programming language. The customer may own the PHP and database contents yet still be locked to a narrow environment because upgrading all dependencies at once is risky. The provider may prefer to keep the old environment because migration consumes labour and creates support calls. Both parties postpone the change until a security deadline, acquisition or hardware move compresses the timetable.

The old brand amplifies the illusion of stability. If “100 Megs” still answers the phone, a customer may assume the service is the same. In reality, continuity requires repeated substitutions: PHP branch for PHP branch, database engine for database engine, installer for installer, certificate process for certificate process and server for server. Good hosting hides those substitutions from ordinary use. Good governance records them so that hidden work does not become hidden risk.

“Unlimited” met a 4 per cent rule

The 4 per cent resource clause is the point where marketing capacity met multi-tenant engineering. It said a shared-account script or process could violate policy at any instant even if the customer had not exhausted disk or transfer. That may sound harsh, but some limit was inevitable. A single runaway process or expensive database query can degrade hundreds of neighbouring sites.

The problem was not the existence of a limit. It was the gap between the plan-table language and the operating rule. “Unlimited bandwidth” encourages a buyer to think in traffic volume. The AUP governed CPU, memory, network and storage behaviour and left the remedy to management discretion. A customer could remain under the visible meter and still cross the invisible one.

A 2009 first-person account on TulsaMJ's Tech Blog says 100 Megs had stopped scheduled housekeeping scripts without notice, later stopped other scripts and eventually suspended the writer's account. The writer said the sites were re-enabled and then moved elsewhere. There is no response from 100 Megs and no server telemetry, so the account cannot show whether each intervention was justified. It is useful because it describes the customer's uncertainty: the workload depended on scripts whose operational status was not obvious until the provider acted.

The correct procurement response is not to demand a literally limitless shared server. It is to ask for an observable and graduated resource policy. Which measurements are used—average CPU, peak CPU, memory, process count, database time or input/output? Over what interval? Does the customer see them? Is there a warning before suspension? Can a burst be tolerated? Is a move to a virtual server offered? How quickly can data be retrieved if the account is disabled?

100 Megs did invite customers with resource questions to contact support at any time, and its virtual and dedicated tiers offered an upgrade path. But the captured VDS plan was sold out. That exposes another continuity issue: an escalation path on a product map is not useful if capacity is unavailable when a growing customer needs it. A buyer should test not only whether the next tier exists, but how migration works, how long provisioning takes and what happens if that tier is constrained.

The brand's name makes the lesson unusually crisp. The quantity advertised in a name or plan is rarely the quantity that governs failure. Storage was abundant. Shared contention, compatibility and support attention were scarce. Modern “unmetered” offers repeat the same pattern whenever fair-use terms, inode counts, worker limits or database caps sit outside the headline.

Support was part of the control plane

100 Megs advertised 24-hour email support, an online help desk, announcements and a knowledge base. The reseller arrangement divided support deliberately: the reseller answered the customer first, while 100 Megs handled system administration and second-line issues. That design was not administrative decoration. It was how operational authority travelled.

Consider a failed checkout. The reseller might inspect the application and payment settings. 100 Megs might inspect PHP, the certificate or a blocked process. Data393 might own the physical intervention. A network supplier might own a routing fault. The customer, however, had one outage. The quality of the service depended on diagnosis moving across these boundaries without losing context.

The early forum accounts are favourable: one customer called the host “overall good,” another said they were happy with service and support. The 2009 migration account is negative and describes silent intervention. Neither side establishes an average response time or incident rate. Together they show why testimonials cannot substitute for support design. A host can have satisfied users and still create serious risk for a workload that falls outside standard practice.

The support page's categories—setup, email, billing and pre-sales—suggested a conventional, organised surface. What is missing from the public record is equally important: no preserved service-level commitment for ticket acknowledgement or restoration, no severity definitions, no published escalation route and no clear demarcation of managed work on the dedicated plans. Absence from these sources does not prove the company lacked private procedures. It means a buyer could not safely infer them from the plan table.

For an SME, support should be evaluated as a control system. Can the buyer open a ticket when the main domain or mailbox is down? Is there an out-of-band contact? Does the provider retain a timestamped change history? Can billing staff prevent an automated suspension while a technical dispute is investigated? Can a reseller escalate directly? Who may authorise restoration from backup? What evidence is returned after an incident?

The value of a small host often lies precisely in human help. The customer may choose it because someone can repair a permission error or explain a DNS change. That advantage becomes durable only when the help path is documented and portable. If all operating knowledge lives in old tickets, an acquisition or staff departure can erase the context even when every file survives.

Canadian identity did not mean Canadian data

The archived Contact page placed the brand in Edmonton. The About page placed the infrastructure in Colorado. The site's archived privacy policy said the provider collected and stored names, addresses, telephone numbers, credit-card information, account status, service choices, logs, email and other communications in the course of service. It said customer information could be shared with selected partners, used for service and product communications, and disclosed in specified legal or protective circumstances.

Those statements make geography operational. A Canadian customer could provide billing and communication data to a Canadian-facing brand while website content and service logs were processed in the United States. A reseller could add another contractual layer. An ecommerce site could introduce payment services and customer records that the host did not fully control.

Current guidance from the Office of the Privacy Commissioner of Canada says an organisation remains responsible for personal information transferred to a third party for processing. For processing outside Canada, it recommends risk assessment, comparable protection through contractual or other means, limits on use and transparency about foreign access. This is current guidance and should not be treated as a retrospective finding that 100 Megs complied or failed to comply in 2010.

What the historical material permits is a procurement conclusion. “Canadian based” was not sufficient data-residency evidence. A buyer needed to ask where the primary site, mail, control-panel data and backups were stored; which company operated each layer; what legal process could reach them; and whether the same location applied after failover or restoration.

The archived terms further complicated the picture by selecting the laws of the United States, despite the Canadian-facing identity. The clause did not specify a state in the captured text. Legal interpretation would require the complete contract and professional advice, but the mismatch itself was a warning to read beyond the address. Brand nationality, server location, governing law and privacy accountability are four different attributes.

This remains relevant because “local” hosting is often sold as trust. Local support and billing can be genuinely valuable. They do not automatically imply local infrastructure or a single jurisdiction. The right test follows each category of data through collection, processing, backup, support access, disclosure and deletion. 100 Megs' own pages contained enough information to reveal the split, but a customer had to join the pages together.

The 2011 acquisition turned continuity into a migration

Tech Assets' 2011 acquisition is the pivotal commercial change. The buyer's history emphasises repeated hosting acquisitions and migration capability. It had launched Jumpline in 1997, moved its customer base to a virtualised platform in 2002 and acquired a series of specialist and cPanel hosts before buying 100MegsWebHosting. That makes the purchase legible as a portfolio transaction: the customer base, recurring billing and cPanel workloads could be moved into a larger operating system.

Acquisition can improve continuity. A larger owner may offer newer infrastructure, better purchasing power, broader support and more disciplined security. It can also alter the commercial bargain while leaving the technical service online. Customers may face a new portal, renewal cycle, support team, plan mapping or price. The migration can be successful in the narrow sense—files and domains still work—while being disruptive in the broader sense that the service no longer matches why the customer bought it.

One July 2012 review on WHTop's Jumpline page gives a specific customer account. The reviewer said a company they called “100megs domains” had been sold to Jumpline, that hosted domains and sites were transferred, that annual hosting rose from $60 to more than $130, and that domain renewal cost increased. The writer said they then moved the domains to another registrar and the hosting elsewhere. This is a single, unverified complaint posted to a review site. It does not establish universal pricing, the precise migration date or a contractual breach. It does corroborate at customer level that a 100 Megs workload reached Jumpline after the documented acquisition, and it shows the dimensions along which the customer judged continuity.

The corporate chain later moved again. The current Jumpline customer page says Jumpline is part of the HostPapa family and provides a login path for existing customers. It says files and website content remain accessible, that there are no immediate service or price changes, and that future adjustments will be communicated. That page does not prove that any specific 100 Megs account remains active in 2026. It establishes the present successor surface for Jumpline and illustrates how a hosting brand can persist as a customer-access doorway after ownership changes.

The 2012 review is especially revealing when set beside the 2010 catalogue. The Value plan's annual price was $50 and Pro's was $100. A customer's reported move from $60 to above $130 would not merely be inflation in disk capacity; it would be a remapping of the whole bundle. Perhaps the successor included features the customer did not need. Perhaps its cost base differed. The public evidence cannot adjudicate the reason. What matters is that switching cost gave the successor room to change the offer. A customer had to separate domains, hosting and application state before price competition became effective again.

Acquisition clauses deserve the same attention as backup clauses. The 2010 terms allowed 100 Megs to assign the agreement while restricting the customer's ability to do so. That asymmetry is common in service contracts, but it means the provider can change the counterparty without the customer changing the workload. A continuity plan must therefore anticipate corporate change as well as hardware failure.

The appropriate question is not “Will this host ever be acquired?” It is “What can we independently move if it is?” Domain registration, DNS authority, off-provider backups, application documentation and billing records create negotiating power. Without them, even a technically competent migration can leave the customer commercially captive.

Exit was a data inventory, not a download button

The historical terms gave customers a control-panel backup capability while disclaiming the regularity and accuracy of provider backups. That arrangement was rational only if customers actually exported and tested their own copies. A backup left on the same hosting account was not an exit copy. A full archive that only the host could restore was not yet a recovery procedure.

Current cPanel backup documentation makes the distinction precise. A user can generate and download a full account backup, including to remote FTP or secure-copy storage. But a full backup cannot be automatically restored from the ordinary cPanel interface; automatic restoration requires WHM and therefore usually the hosting provider. The documentation also warns that creating a backup can fail when an account is near its quota because the process needs working space, and that automatic account backups exist only if the provider enables them.

That creates a practical trap. The customer most urgently needing to leave may be close to quota, suspended or within the seven-day cancellation window. The provider may control the restoration tool. The right time to test export is before conflict or failure.

The current cPanel Transfer Tool can copy accounts, packages and configurations when the operator has sufficient privileges. It can update DNS and mail routing and perform a live transfer intended to reduce downtime. Yet its documentation lists boundaries: custom DNS templates are not transferred, two-factor settings must be reconfigured, database-name conflicts can trigger renaming, remote-mail arrangements need care, and FrontPage-specific files are not restored. Even a transfer within the same control-panel family therefore requires a reconciliation step.

The TulsaMJ account supplies a historical example of that reconciliation. After moving away from 100 Megs in 2009, the writer documented that PHP had run as an Apache module at 100 Megs but as CGI at the destination. The .htaccess handler syntax had to change, and discovering the difference took time and support. The files had moved; their execution context had not.

A complete 100 Megs exit inventory would have contained at least the following:

1. The registrar account, registrant contact, transfer lock status and authorisation credential for every domain.
2. Every DNS zone and the location of authoritative nameservers, including mail, verification and service records not generated by cPanel.
3. Website files, hidden configuration files, permissions, symbolic links and scheduled tasks.
4. Each database, user, privilege and character setting, plus an application-level consistency check.
5. Mailboxes, messages, aliases, forwarders, filters, mailing lists, spam settings and the devices or local archives that depended on POP behaviour.
6. Certificate private keys, certificate chain, renewal method and proof that the destination could serve HTTPS before DNS changed.
7. Application versions, extensions, themes, licence keys, installer history and runtime requirements.
8. Traffic statistics, access logs and error logs needed for troubleshooting or retention duties.
9. Billing statements, support tickets, policy versions and proof of cancellation.
10. A rollback window in which the old service remained available while the new site, mail and jobs were tested.

Domain transfer is a separate control path from hosting migration. The current ICANN Transfer Policy requires a registrar to provide the domain's AuthInfo code and remove a transfer lock within five calendar days when self-service is unavailable, subject to the policy's conditions. It also says a registrar cannot withhold those steps solely because of a payment dispute. That protection is useful only if the business knows which registrar holds the domain, keeps the registrant contact current and begins before expiry or crisis.

Mail requires special caution. A website can be compared visually at a temporary address; email is distributed state. Messages may arrive at the old server while DNS caches expire. POP users may have unique local histories. Forwarders and filters may not reproduce exactly. The migration needs a period of parallel observation, low DNS time-to-live set in advance, test messages from outside networks, and confirmation that the old queue is empty.

Database-driven shops and forums require application consistency. Copying files at noon and a database at one o'clock can produce a site whose uploads, orders and records disagree. The customer needs a maintenance window or a replication method, a final write freeze, checksums or record counts, and a transaction-level test at the destination. The osCommerce customer's confusion in 2006 is a reminder that a technically installed cart is not a validated commercial workflow.

Cancellation terms convert these technical steps into deadlines. The archived agreement allowed either party to terminate on notice, imposed an early-cancellation fee in some circumstances, and limited the archive window after cancellation. It also capped stated liability at $500 and excluded categories of lost data, profit and use. Those historical clauses are not presented as current successor terms. They show why a customer could not make the host's liability ceiling its recovery plan.

The strongest exit test is a restore performed by someone other than the person who built the site, using a copy stored outside the provider. If that person can recover the website, database, mail flow, DNS and certificate within the required time, portability is real. If the exercise stops at “we downloaded a tar file,” the customer has an artefact, not continuity.

Security claims needed operating evidence

The archived About page used the security vocabulary of its time: controlled physical access, surveillance, firewalls, redundant power, environmental controls and continuous monitoring. The Data393 announcement independently supports several facility-level capabilities. The privacy page said physical, electronic and managerial safeguards were in place. These are relevant inputs, but they do not reveal patch latency, access review, vulnerability management, backup isolation or incident response.

The exposed response headers demonstrate why version governance belongs in security assessment. They gave outsiders exact Apache, PHP, OpenSSL and FrontPage generations for the marketing site. Version strings alone do not prove exploitability; software can be backported or configured defensively. They do give a buyer a reason to ask for lifecycle policy and compensating controls.

The acceptable-use policy placed substantial security responsibility on customers. It prohibited open mail relays, unauthorised access, malicious software, disruptive activity and several forms of abuse. It said the provider could remove information or shut down a site when it learned of harmful activity. Such powers can protect neighbours on a shared server, but they also make notice, evidence preservation and appeal procedures important for a legitimate business caught by a false positive.

No reliable public source used here establishes a company-specific security certification, independently measured uptime, breach history or incident rate for 100 Megs. That is an evidence gap, not evidence that no incident occurred. The archive also cannot show how frequently backups restored successfully or how quickly support handled abuse reports.

A buyer in this position should ask for operating evidence rather than adjectives: supported runtime versions; patch and emergency-change windows; separation between customer accounts; privileged-access controls; malware and outbound-mail monitoring; backup encryption and immutability; restore-test results; notification duties; and the facility, network and support companies that can access data. If the provider relies on a data-centre certification, the buyer should ask which service and controls it covers. A certified building does not certify a customer's PHP application.

For ecommerce, the division of responsibility must be especially clear. The host can provide HTTPS and an application installer. It does not thereby validate the shopping cart, payment integration, administrator passwords or data-retention choices. The customer should minimise payment data, use a payment design appropriate to its compliance obligations, keep applications supported and verify the complete checkout and refund path after every significant change.

Security and portability reinforce each other. A provider may need to remove an obsolete component for safety. A customer that can test and move has room to upgrade. A customer trapped on an old runtime pressures the provider to preserve risk. The best continuity investment is often the same as the best security investment: documented dependencies, current software, reproducible configuration and tested recovery.

A procurement test built from the 100 Megs record

The modern buyer choosing among shared hosting, managed application hosting, a virtual server, a dedicated machine or a larger cloud platform should not ask which category is inherently best. Each shifts labour and control. Shared hosting standardises operations at low cost but constrains resources and versions. Managed application hosting can reduce patching work but narrows supported extensions. A virtual server increases control and administration. Dedicated hardware isolates capacity but does not automatically provide resilience.

A broad cloud platform offers many building blocks while making architecture and cost management the customer's responsibility.

100 Megs itself sold several of these rungs, which makes its record a useful procurement test. A buyer can take every appealing claim from the 2010 catalogue and ask for the operating fact beneath it.

Identity and counterparty. What exact legal business signs the contract and invoices the customer? Which public brand supplies support? May the agreement be assigned? The 100 Megs brand is well proved, but its pre-acquisition legal wrapper is not. That distinction should be resolved before money or regulated data moves.

Domain control. Is the customer the registrant, with independent credentials and recovery contacts? Can the domain be transferred without an active hosting account? A site whose domain and hosting fail together has turned two dependencies into one.

Location and suppliers. Where are primary data, mail, logs and backups processed? Who owns the facility and network? Which locations are used during recovery? 100 Megs was Canadian-facing and Colorado-hosted; neither fact cancelled the other.

Capacity and enforcement. What does “unlimited” exclude? Which CPU, memory, process, file-count, database and mail limits apply? How are they measured and surfaced? The 4 per cent rule mattered more than the Ultra plan's transfer headline.

Lifecycle. Which PHP, database, operating-system and control-panel versions are offered, when do they retire, and who pays for remediation? Can a customer stage against the next version? The presence of PHP, MySQL and FrontPage in a feature list was only the beginning of the obligation.

Application boundary. Does “managed” cover the operating system, control panel, open-source application, extensions, performance tuning and recovery, or only some of them? Which changes require a paid engagement? The 100 Megs dedicated page advertised support and managed additions without enough preserved detail to price the boundary.

Support design. What are the acknowledgement and restoration targets by severity? Is there an out-of-band route? Who owns first and second line? Are ticket histories exportable? The reseller page usefully disclosed its two-layer arrangement; a buyer would still need escalation times.

Backup and restore. Is the copy off the production account and fault domain? How long is it retained? Can the customer restore without provider privilege? Are databases captured consistently? The seven-day post-cancellation archive and non-guarantee make this test non-negotiable.

Migration. Which components transfer automatically and which require manual work? Can the buyer run a live rehearsal? Are DNS, mail, scheduled tasks, certificates, two-factor settings and old extensions included? cPanel's own documentation shows why “cPanel to cPanel” is not synonymous with complete.

Pricing over time. What is the first-term, renewal and migration price? Which items are optional today but required in practice—custom SSL, backups, security, dedicated addresses or support? How are acquired accounts mapped to new plans? The 2012 Jumpline complaint is not a price list, but it identifies the risk.

Exit and deletion. How much notice is needed, when does access stop, what fees apply, and when are primary and backup copies deleted? Can the customer retrieve logs and tickets after cancellation? The historical terms made access time-bounded and provider liability limited.

This test also clarifies competition. A rival offering less disk but transparent resource telemetry, supported runtimes and a proven restore may be cheaper in business terms. A rival with a low introductory fee but expensive renewal, proprietary site builder and host-controlled domain may be costlier. A virtual server can reduce one form of constraint while increasing the cost of security and administration. The comparison should price staff time, expected migrations and outage exposure alongside the invoice.

For an SME, switching cost is often asymmetric. Joining takes minutes because the host automates setup. Leaving takes days because the customer must rediscover years of accumulated state. Procurement should reverse that asymmetry before signing: export a sample account, inspect the archive, restore it elsewhere, transfer a test domain, reproduce mail rules and record how long support takes to answer. A provider confident in continuity should be able to explain the exercise.

The same test applies after acquisition. Revalidate the contract, support contacts, data locations, runtime roadmap, backup access, renewal price and cancellation procedure. Do not assume that a working homepage proves every dependency survived. The 100 Megs-to-Jumpline account suggests that technical transfer and commercial satisfaction can diverge.

What remains knowable—and what should be watched

The exact company story has firm anchors and real gaps. Firm: the domain was registered in 2001; users described the service in 2002; the brand published a detailed Canadian contact and a Colorado-hosted catalogue in 2009–2010; the service offered shared, reseller, virtual and dedicated tiers around cPanel; Tech Assets says it acquired the brand in 2011; a later customer described transfer to Jumpline; and Jumpline now presents HostPapa as its parent surface.

Unproved: the full legal identity before acquisition, the company's claimed customer count, revenue, staff size, the number and utilisation of servers, ownership of network resources, measured uptime, the frequency of suspensions, successful restore rates and whether any original 100 Megs customer account remains active today. These are not decorative omissions. They define how strongly the history can be used.

The current domain registration should be watched as a continuity signal, not mistaken for an operating company. A registered domain can point to a successor, an inactive service or a holding page. The meaningful questions are whether old customers still have an authenticated route to account data, which terms now govern them, which runtime versions remain, and whether the successor can produce a complete export.

The successor chain also deserves monitoring. Jumpline's current page promises continued access and advance communication of major changes. Buyers with inherited accounts should preserve copies of those notices, compare plan and renewal terms, test backups before platform changes and verify that domain registration is not silently bundled with hosting. The moment before a scheduled migration is the cheapest time to find an unsupported component.

For historians of hosting, further primary records could narrow the legal and operational gaps: Alberta trade-name and corporate filings, complete pre-acquisition contracts, archived routing records, customer invoices, acquisition notices and support communications. Until such records appear, they should not be replaced with aggregator estimates or assumptions derived from the word “Megs.”

The brand's deeper lesson does not depend on filling those gaps. By 2010, 100 megabytes no longer described even the smallest advertised plan. The promise survived because it had become a name. What customers actually bought was the continued alignment of many moving parts: software that still ran, a domain that still resolved, mail that still arrived, a database that still matched the files, support that could reach the right layer and a backup that could become a working service somewhere else.

Capacity grows almost automatically. Continuity does not. It has to be designed into ownership, contracts, architecture and rehearsal. The seven-day archive clause made that visible in 2010, and the acquisition made it visible again in 2011. A hosting brand can carry an old number for decades. Its customers should carry something more useful: the tested ability to leave.