The buyer who still wants to know which machine is theirs
The most revealing SoftLayer customer is not the developer who wants a cheap virtual machine for a weekend test. It is the buyer who has already lived through the opposite problem: a workload moved into a highly abstract public cloud, billed by many tiny meters, protected by many shared controls, and then discovered to be too steady, too regulated, too latency-sensitive, too network-specific, or too operationally stubborn to be happy there. That buyer still wants cloud ordering, hourly or monthly commercial flexibility, API control, and access to storage, backup, support and private connectivity. But it also wants to know that the server is single tenant, that the network path is designed rather than guessed, that public egress is not an open-ended surprise, and that isolation is based on hardware control rather than only tenant logic.
SoftLayer Technologies matters because it built a large business around that buyer before the public-cloud market learned to describe the problem as "hybrid cloud." IBM did not acquire SoftLayer in 2013 to buy a small hosting brand. It bought an operating model in which cloud could mean physical servers as much as virtual instances, private networking as much as public internet reach, and infrastructure control as much as developer speed. IBM's announcement said SoftLayer gave clients a choice between dedicated and shared servers, physical and virtual devices, public and private cloud patterns, a full-featured API, automation, and a low-latency global network (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). The closing announcement said SoftLayer would join a new IBM cloud services division, combining with IBM SmartCloud into a global platform (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html).
The hard-number spine is unusually concrete for an old private-cloud acquisition. At announcement, SoftLayer was described as operating 13 data centers in the United States, Asia and Europe, with 100,000 devices under management (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). GI Partners, the seller, said the company managed more than 100,000 servers, firewalls and load balancers, served more than 21,000 customers across more than 140 countries, and operated 13 data centers globally (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). The Los Angeles Times reported the deal value at $2 billion, while noting that IBM did not disclose terms (https://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html). As of 2026, the public network evidence still shows a large IBM Cloud surface under the SoftLayer network identity: PeeringDB lists AS36351 as "SoftLayer Technologies, Inc. (an IBM Company)", also known as IBM Cloud, with 1,800 IPv4 prefixes, 450 IPv6 prefixes, and 1-5 Tbps traffic (https://www.peeringdb.com/net/1613). IBM's current bare-metal pricing page says classic infrastructure offers over 11 million configuration combinations and 20 TB of cost-free bandwidth, while VPC bare metal can deploy preset profiles in 10 minutes or less (https://www.ibm.com/products/bare-metal-servers/pricing).
Those numbers explain why the SoftLayer story is not nostalgia. They describe the part of cloud economics that never became fully abstract. Some workloads are not really asking for "a cloud" in the marketing sense. They are asking for a controlled server, predictable network behavior, enough private bandwidth, a known support channel, a routing plan, and a commercial structure that does not punish steady use. SoftLayer's strategic value was to make those old requirements feel modern enough to sit inside IBM Cloud.
IBM bought a control business, not just capacity
The cloud market in 2013 was already moving toward abstraction. Amazon Web Services had made the virtual instance the default mental model. OpenStack was trying to standardize private-cloud software. Enterprise buyers were beginning to talk about hybrid deployments, but many still treated public cloud and dedicated hosting as separate categories. SoftLayer's appeal was that it blurred the line from the infrastructure side. IBM could tell an enterprise buyer that the same platform supported public cloud, hosted private cloud, bare metal servers and virtual instances, without forcing every workload through the same shared-virtualization assumptions.
That distinction is visible in IBM's acquisition language. The 2013 release said SoftLayer allowed clients to buy enterprise-class cloud services on dedicated or shared servers, and that its architecture spanned physical and virtual devices (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). The closing release said SoftLayer would let IBM combine private-cloud security, privacy and reliability with public-cloud economy and speed (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html). The wording sounds like marketing, but the economic claim is specific: IBM was buying a platform where cloud adoption did not require giving up server-level control.
That mattered because IBM's natural customer base did not look like a consumer internet startup. Banks, insurers, healthcare organizations, government contractors, software vendors, outsourcing accounts, managed-service providers and industrial enterprises often care about auditability, physical isolation, routing, support escalation, license portability, operating-system control and performance predictability. Some of those needs can be met in modern virtual private cloud designs. Some are easier to sell when the buyer can point to a single-tenant physical server and a contract term.
The acquisition also gave IBM a more credible answer to a commercial problem. A traditional enterprise account might want to move only part of a workload off premises, not rewrite everything for cloud-native operations. SoftLayer's model let IBM sell a landing zone that felt closer to the customer's existing environment: dedicated machines, VLANs, gateway appliances, load balancers, firewalls, storage add-ons, backup products, support tickets and network engineering. That kind of buyer is not necessarily hostile to public cloud. It is hostile to losing operating leverage before the business case is proven.
The private-equity history reinforces the point. GI Partners acquired EV1 and The Planet in 2006, acquired SoftLayer in 2010, and merged SoftLayer and The Planet before selling to IBM (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). This was not a pure software story. It was a consolidation of dedicated hosting, network operations and data-center service capabilities into an automated infrastructure provider. The valuable asset was not only servers. It was the know-how required to turn physical infrastructure into a repeatable commercial product.
IBM's own current product language still keeps that distinction alive. Its bare-metal documentation defines the classic bare metal server as hourly or monthly, single tenant, dedicated to the customer, not shared in any part, provisioned without a hypervisor, and deployed in one or more data centers (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). The getting-started page says IBM Cloud Bare Metal Servers can be deployed and managed as cloud services with hourly and monthly billing on classic or VPC infrastructure (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started). In other words, the product has kept SoftLayer's central promise: a cloud order can still result in a physical server.
The SoftLayer identity now lives in the network and the product controls
SoftLayer is no longer best understood as a standalone public operating company. The defensible current reading is that SoftLayer survives as a legacy brand, a set of platform APIs, a public network identity, and a design lineage inside IBM Cloud. That is not a weak fact pattern. For infrastructure, network identity and operational continuity often matter more than the consumer-facing brand.
ARIN's public registration evidence still carries the older name. The RDAP organization record for SOFTL identifies SoftLayer Technologies Inc. at 4849 Alpha Road in Dallas, Texas, with a registration event in 2005 and a last-changed event in 2024 (https://rdap.arin.net/registry/entity/SOFTL). The RDAP record for AS36351 names SOFTLAYER and lists the registrant as IBM Cloud at IBM's Armonk address (https://rdap.arin.net/registry/autnum/36351). BGP.tools presents AS36351 as IBM Cloud, registered in December 2005, active and allocated under ARIN, with upstreams including Arelion, Lumen, NTT America, Bharti Airtel, Telstra, Hurricane Electric, Tata Communications and Telxius (https://bgp.tools/as/36351). PeeringDB gives the peering-facing form: SoftLayer Technologies, Inc. (an IBM Company), also known as IBM Cloud, AS-SOFTLAYER, North American scope, selective peering policy, 1,800 IPv4 prefixes, 450 IPv6 prefixes and 1-5 Tbps traffic (https://www.peeringdb.com/net/1613).
There is an important distinction between PeeringDB prefix counts and BGP.tools originated-route counts. PeeringDB is a self-maintained interconnection directory, useful for peering policy and operator contact context. BGP.tools reflects observed routing and showed 339 originated IPv4 prefixes and 72 originated IPv6 prefixes on the page reviewed for this article (https://bgp.tools/as/36351). The two measurements should not be treated as identical. The economic point is not the exact route count. It is that the SoftLayer network identity remains attached to a large IBM Cloud routing surface, with many customer and service prefixes visible across public routing data.
The SoftLayer API is another continuity signal. IBM Cloud documentation says the SoftLayer Application Programming Interface is the development interface giving developers and administrators direct interaction with the IBM Cloud backend; it powers many console features and can automate tasks, using SOAP, XML-RPC or REST (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). The SoftLayer Development Network still publishes release notes, SDK links and CLI references under the SoftLayer name, with 2026 API release notes visible on its front page (https://sldn.softlayer.com/). This is not brand sentiment. It shows a mature control plane that customers, scripts, tooling and partner integrations can still touch.
That continuity has value and risk. It gives existing customers a stable way to manage classic infrastructure, order devices, inspect resources and automate operations. It also means IBM must carry legacy behavior, old naming, mature customer expectations and backward compatibility. The more valuable the old control surface is to customers, the more carefully IBM has to change it. That is one reason server-control businesses do not disappear quickly even when market language turns toward VPCs, containers and AI platforms.
The public interconnection footprint also shows why SoftLayer was never merely "hosting." PeeringDB's detailed record shows public exchange points including AMS-IX, DE-CIX Chicago, DE-CIX Dallas, DE-CIX Frankfurt, DE-CIX Madrid, Equinix Ashburn, Equinix Chicago, Equinix Dallas, Equinix Hong Kong, Equinix Madrid, Equinix Miami and others, with capacities ranging from 10G and 20G to 100G and 200G on selected connections (https://www.peeringdb.com/net/1613). The API view of the PeeringDB record returns 73 public exchange connections and 40 interconnection facilities for the network when requested with depth (https://www.peeringdb.com/api/net/1613?depth=2). The exact mix can change, but the evidence confirms an operating surface built around routing, interconnection and traffic management, not only data-center floor space.
Bare metal turns cloud economics back into utilization math
The economic center of the article is simple: bare metal is cloud sold with inventory risk left visible. A hyperscale virtual machine is an abstraction over a pool. A dedicated physical server is a specific machine that must be bought, powered, cabled, cooled, tested, monitored, repaired, refreshed, secured, connected and ultimately filled with revenue. SoftLayer's historic innovation was to make that physical machine orderable through a cloud-like interface. IBM's economic challenge is to keep that interface attractive without letting the underlying hardware become low-utilization inventory.
IBM's current product pages show how that is managed. Classic bare metal is pitched as customizable, with more than 11 million configuration combinations and 20 TB of cost-free bandwidth, aimed at large, steady-state, predictable operations (https://www.ibm.com/products/bare-metal-servers/pricing). Fast-provisioning servers are preconfigured and ready to configure 30-40 minutes after provisioning (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Custom servers depend on complexity, quantity and testing options (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). The same documentation says bare metal provisioning generally takes up to 4 hours, and that extended hardware testing takes an extra 2 hours; tests that find critical or unrecoverable hardware errors lead to component replacement before provisioning continues (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm).
Those details matter because they describe the cost curve. A preconfigured server can be faster because IBM has already standardized the shape. A custom server is slower because the customer is asking IBM to assemble or allocate a more specific physical asset. Hardware testing protects reliability but delays revenue start and consumes labor. A single-tenant design creates isolation but prevents IBM from using that machine for another tenant while the customer holds it. The product can feel cloud-like to the buyer, but the cost base remains closer to data-center operations than pure software.
This is where the 20 TB cost-free bandwidth claim is strategically important. For steady workloads, bandwidth certainty is part of the product. A video platform, analytics vendor, backup service, game backend, software repository, financial data service or enterprise integration host can often estimate its baseline traffic better than a bursty startup can estimate peak compute. If the buyer can map a monthly server cost to a known included bandwidth pool, a dedicated-server plan may look less risky than a public cloud bill composed of compute hours, storage I/O, NAT gateways, cross-zone traffic, internet egress and managed-service meters. IBM's pricing page explicitly distinguishes classic bare metal as good for large, steady state, predictable operations (https://www.ibm.com/products/bare-metal-servers/pricing).
Reservations and contract terms show the other side of the utilization bargain. IBM's pricing page says VPC bare-metal reservations can reduce expense by up to 35 percent with a one-year term or up to 60 percent with a three-year term, and that reservations guarantee capacity in the selected availability zone and data center for the life of the term (https://www.ibm.com/products/bare-metal-servers/pricing). The classic contract-term documentation says a one-year contract term maintains bare-metal capacity in the data center and POD selected for the life of the contract, but the customer cannot change the configuration after the order is complete and cannot cancel the contract term (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers). That is not just discounting. It is a transfer of utilization risk. IBM gives price relief because the customer gives demand certainty.
The same logic applied to SoftLayer in 2013. A platform with 100,000 devices under management and 21,000 customers could be valuable because it had enough variety and scale to smooth demand across many customer types (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). A smaller dedicated-hosting firm can get trapped with the wrong servers in the wrong markets. A larger platform can standardize common builds, reuse parts, route demand across locations, and attach higher-margin services. But even at IBM scale, a physical server that is not rented is idle capital. The business therefore rewards forecast accuracy, procurement discipline, hardware refresh timing, standard configuration design, sales qualification and retention.
That makes SoftLayer a good case study in the difference between "cloud growth" and "cloud margin." IBM's 2025 annual report describes a company now centered on hybrid cloud and AI, with 2025 total revenue of $67.535 billion, software revenue of $29.962 billion, Hybrid Cloud revenue of $7.327 billion, and infrastructure revenue of $15.718 billion (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). But IBM does not disclose a SoftLayer revenue line. The public evidence does not let an outside reader calculate gross margin or utilization for IBM Cloud classic bare metal. The best public method is to read the product mechanics: what IBM prices, what it reserves, what it includes, what it meters, and what operational commitments it keeps visible.
Network billing is the hidden reason SoftLayer still makes sense
For many enterprise workloads, the decisive variable is not CPU. It is network predictability. A bare-metal server is useful only if the customer can trust how traffic enters, leaves and moves privately. SoftLayer's original pitch included secure low-latency communication and a global network (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). IBM's current documentation keeps that network logic central.
Every IBM Cloud bare metal server includes access to the private network, and a public interface is a provisioning choice rather than an automatic assumption (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). The network options page says private network access is always included, while the customer chooses whether the server also has public internet access; a server provisioned private-only cannot have a public interface added later (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). It also lists port speed choices of 100 Mbps, 1 Gbps, 10 Gbps and 25 Gbps, with 25 Gbps limited to selected server options and selected data centers (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
The same page makes the operating tradeoff explicit. Automatic port redundancy is the default and recommended setting, providing two physical network ports configured with LACP bonding on both the network and operating system during provisioning; user-managed redundancy provides two ports but requires customer action; no redundancy is maintained only for specialized needs and should be selected only in consultation with IBM Sales or Support under specific conditions (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). That is classic SoftLayer economics. The product gives customers hardware-level choices, but choices come with operating obligations.
Public egress is another key meter. IBM's network options documentation says customers choose included outbound public traffic per billing period; overage is charged per GB; inbound public traffic is free (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). The bandwidth graph documentation says outbound public data transferred from IBM Cloud data centers around the globe is assessed as outbound bandwidth charges, while bandwidth graphs show public and private network usage associated with a device (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs). The backup documentation says no bandwidth limit is enforced for private network traffic when data moves between devices sharing an account (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery).
This creates a product posture that is different from pure public cloud. IBM can tell a customer: keep east-west traffic private where possible, use included or unmetered private paths within the account, choose the right public egress bucket, and attach direct connectivity when needed. The customer still pays for public internet usage, but the architecture gives it knobs to reduce uncertainty. That is exactly the kind of control a steady-state buyer wants.
Direct Link shows how far that control can go. IBM's Direct Link on Classic documentation says setup involves basic network configuration and Border Gateway Protocol, with IBM engineers working with the customer to enable VRF capability (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). It says IBM assigns a /31 or /30 network for each connection on the IBM Cloud cross-connect router infrastructure, and that BGP is mandatory for managing routing through Direct Link (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). The FAQ says bandwidth usage across Direct Link between customers and IBM Cloud is free and unmetered, while outbound bandwidth from IBM Cloud services to the public internet is metered (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). It also says Direct Link can provide diverse connections but redundancy is created by customer BGP design, not by a single inherently redundant service (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs).
For a buyer that cares about compliance isolation, predictable network billing and private connectivity, that is why IBM kept the server-control business. The server alone is not the asset. The asset is the ability to combine a dedicated machine, private addressing, VLAN selection, Direct Link, VRF, port speed, redundancy choices and bandwidth policy into an infrastructure contract. SoftLayer gave IBM a vocabulary for that sale.
Compliance isolation is operational, not only contractual
Bare metal appeals to risk-sensitive buyers because it gives them a simpler story about isolation. A single-tenant physical server does not automatically solve compliance, security or resilience. The customer still has to patch operating systems, manage credentials, encrypt data, design backup, control ingress, monitor logs and prove procedures. But the isolation claim starts from a different place: the server is dedicated, no hypervisor is imposed by the provider, and the customer has more direct control over host-level decisions.
IBM's documentation is careful about this. It says the bare metal server is dedicated to the customer and not shared with other customers, while the customer manages the server and it is provisioned without a hypervisor (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). It also says some workloads should be spread across multiple data centers and PODs to avoid a single fault domain; merely spinning up multiple applications is not enough if deployment location is wrong (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). This is a serious operating warning. Bare metal gives control, but control transfers more design responsibility to the customer.
Network isolation works similarly. IBM's tutorial for linking secure private networks over the IBM network describes classic infrastructure and says most workloads can be implemented using IBM Cloud VPC, but then shows how secure private networks in different data centers can be linked over the IBM private network using VRF or VLAN spanning, gateway appliances, routing and firewall rules (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). It notes that no restriction exists on which two data centers can be used apart from the impact of latency, and that private subnets, VLAN IDs, gateway addresses and firewall rules must be recorded and configured (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). That is not the language of a fully managed abstraction. It is the language of infrastructure engineering.
This is precisely where SoftLayer's model remains useful for regulated and control-heavy accounts. The customer can build familiar segmentation patterns: public and private interfaces, firewalls, gateway appliances, VLANs, private subnets, Direct Link, remote network advertisement, BGP, backup, private data transfer and dedicated hosts. IBM gets to sell cloud services without pretending every enterprise workload should be refactored into the same modern pattern on day one. The buyer gets a migration step that feels safer than a full rewrite.
The tradeoff is that manual expertise is not eliminated. Direct Link documentation says customers are responsible for managing route advertisements to and from the IBM Cloud network, and that failure to plan BGP forwarding behavior can create undesired results such as asymmetric routing or incorrectly preferred paths (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). The network options page warns that user-managed redundancy requires the customer to know how to configure redundancy, and that not doing so creates a lack of network communication redundancy during routine maintenance (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). A buyer cannot buy a dedicated server and assume resilience. It must operate the control it asked for.
That tradeoff is the heart of the market. Abstract cloud wins when customers want fewer low-level decisions. SoftLayer-style cloud wins when customers want the decisions back because the workload, regulator, license, latency path, performance profile or migration plan demands it. IBM's advantage is that it can sell both narratives under one enterprise relationship. Its risk is that customers will punish it if either narrative becomes unclear.
Cloud substitution pressure never disappeared
The pressure against SoftLayer's model is obvious: most new cloud consumption prefers abstraction. Developers want managed databases, serverless functions, container platforms, object storage, identity integration, observability, AI services and regional APIs. Finance teams want discount programs and central governance. Security teams want standardized controls. Platform teams want infrastructure that can be created and destroyed without waiting for hardware tests. For those buyers, a physical server can look like an exception.
IBM's own pricing page reflects this split. VPC bare metal is presented as preset profiles deploying in 10 minutes or less across a software-defined network, ideal for high availability and maximum elasticity (https://www.ibm.com/products/bare-metal-servers/pricing). Classic bare metal is presented as highly customizable with 11 million-plus combinations and 20 TB of cost-free bandwidth, ideal for steady predictable operations (https://www.ibm.com/products/bare-metal-servers/pricing). That is not a contradiction. It is IBM segmenting the market: VPC bare metal for customers who want modern cloud constructs around dedicated hardware, classic bare metal for customers who still need the older control surface.
The substitution threat also comes from cost transparency. Public cloud providers have made pricing granular, and granular pricing can either help or hurt the bare-metal case. AWS announced that from February 1, 2024 it would charge $0.005 per public IPv4 address per hour for all public IPv4 addresses, attached or unattached, which makes a year of one continuously allocated public IPv4 address cost $43.80 before other service costs (https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/). That kind of line item pushes buyers to understand address use, NAT design and public exposure. It also makes dedicated-infrastructure providers with included address and bandwidth packages easier to compare, even if the comparison is never perfect.
Competitor pages show the same market pressure. OVHcloud positions bare metal around dedicated resources, anti-DDoS, private networking and predictable infrastructure for workloads that need control (https://us.ovhcloud.com/bare-metal/). Hetzner lists dedicated root servers with aggressive monthly pricing that can make IBM's enterprise-oriented proposition look expensive to price-sensitive European buyers (https://www.hetzner.com/dedicated-rootserver). TrustRadius, a review and comparison site rather than a primary seller, lists IBM Cloud Bare Metal Servers as starting at $0.51 per hour and $241 per month, while noting hourly or monthly options and 500 GB/month outbound bandwidth in its pricing summary (https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricing). That third-party pricing should be treated as a market signal rather than a contract, but it shows how buyers compare IBM against lower-cost and simpler alternatives.
IBM's defense is not to be the cheapest dedicated server. It is to connect bare metal to hybrid-cloud architecture, enterprise support, IBM software, Red Hat/OpenShift strategy, direct connectivity, mainframe-adjacent enterprise accounts, regulated workloads, SAP and VMware patterns, and global procurement. IBM's investor page says the company is positioned around hybrid cloud and AI (https://www.ibm.com/investor). Its 2025 annual report says Hybrid Cloud revenue under Software was $7.327 billion and OpenShift annual recurring revenue reached $1.9 billion at year-end 2025 (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). SoftLayer's role inside that IBM is not to lead the narrative. It is to provide the physical and classic-infrastructure option when the hybrid-cloud sale reaches a workload that still wants the box.
The risk is that a product kept for control becomes a product kept for inertia. If classic infrastructure remains valuable because customers actively need its features, IBM can harvest a durable niche. If it remains only because migrations are difficult, it becomes a legacy burden. The difference is visible in usage quality: are customers choosing classic bare metal for predictable operations, private bandwidth and physical isolation, or are they stuck on it because older applications and scripts are expensive to move? Public evidence cannot answer that with precision, but it frames the question correctly.
The operating surface is bigger than the server
SoftLayer's original design should be understood as an operating surface: server control, network control, storage attachment, identity, support, API automation, billing and facility placement. IBM's current documentation preserves that breadth. Bare metal can be paired with block and file storage from 20 to 12,000 GB at provisioning time, though add-on storage must be connected after the server provisions (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Bare metal add-ons include hardware firewall, monitoring, backup, response, public secondary IP addresses and IPv6 address options (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Network options include public-only choices, private-only choices, private interfaces included by default, public egress selection, VLAN selection, subnet selection and secondary IP address requests (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
The API surface matters because it changes labor economics. If a customer can order, inspect, reconfigure and cancel infrastructure programmatically, the physical server becomes part of a larger operations system rather than a one-off ticket. IBM's virtual server API documentation says the SoftLayer API powers many IBM Cloud console features and can automate all portions of the IBM Cloud environment reachable through the API (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). The SoftLayer Development Network exposes SDKs for Python, Java, Go, Perl, PHP and Ruby, as well as a classic infrastructure plugin for the IBM Cloud CLI (https://sldn.softlayer.com/). That is a deep installed base of tooling behavior.
The control plane, however, also locks in expectations. A long-running enterprise script may assume particular object names, method behavior, authentication patterns, location codes, VLAN conventions or billing item behavior. An API release note in 2026 that removes deprecated service methods is a normal maintenance event, but for an old platform it can still matter to customers (https://sldn.softlayer.com/). Every mature infrastructure business has this problem. The more powerful the control surface, the more it becomes part of the customer's own operating code.
Facilities and routing add another layer. PeeringDB's public page shows AS-SOFTLAYER and a public peering policy that is selective, prefers multiple locations, has no ratio requirement and no contract requirement (https://www.peeringdb.com/net/1613). Exchange capacities listed on the page include 200G at DE-CIX Dallas, 200G at DE-CIX Frankfurt, 200G at DE-CIX Madrid, 100G at DE-CIX Chicago, 80G at Equinix Ashburn, 60G at Equinix Chicago, 60G at Equinix Miami, and smaller links across many other exchanges (https://www.peeringdb.com/net/1613). Those numbers do not prove customer satisfaction or revenue. They do show the routing footprint that supports a global infrastructure platform.
That footprint is both asset and cost. Exchange ports, cross-connects, router capacity, route policy, traffic engineering, abuse handling, DDoS response, maintenance windows, colocation commitments and network engineering do not monetize themselves. They matter when they keep customers from leaving. A customer with a steady workload, BGP requirements, private connectivity and predictable traffic can be sticky because moving is not just a server migration. It is a network and operations migration.
This is why the SoftLayer economics fit IBM better than they might fit a pure low-cost hosting company. IBM can attach network-control infrastructure to a broader enterprise account. It can sell consulting around migration and modernization. It can connect bare metal to Red Hat, VMware, SAP, IBM Z integration, security posture and managed services. The dedicated server is then not the whole margin story. It is the anchor that keeps a particular workload inside IBM's account boundary.
The evidence also shows what cannot be known publicly
The public evidence is strong on identity, network surface, acquisition history, product mechanics and pricing posture. It is weak on current SoftLayer-specific financials. IBM does not disclose SoftLayer revenue, IBM Cloud classic bare-metal utilization, gross margin by data center, churn by workload class, support cost per server, percentage of classic workloads converted to VPC bare metal, IPv4 inventory economics, or the true revenue attach from Direct Link, support, storage, backup and security add-ons. That means any valuation must be conservative.
The most important missing number is utilization by hardware class and location. A bare-metal platform can look healthy if the headline network is large and the product page is broad, while still carrying pockets of stranded hardware. Older CPU generations may be cheap to sell but expensive in power efficiency. High-memory or GPU-ready configurations may command better prices but require careful procurement. Some markets may have strong demand for private connectivity and predictable bandwidth; others may require discounting. The public pages show product breadth, not fill rate.
The second missing number is migration flow. IBM's product pages now distinguish VPC bare metal and classic infrastructure. A rational IBM strategy would move customers toward newer constructs where possible while preserving classic control where necessary. But without a public migration metric, outside readers cannot know whether classic bare metal is growing, stable, shrinking gracefully, or retained mainly for older accounts. IBM's investor materials emphasize hybrid cloud, Red Hat and AI more than classic infrastructure (https://www.ibm.com/investor/services/annual-report). That does not mean classic bare metal is unimportant. It means its importance is operationally specific rather than headline strategic.
The third missing number is support quality. Bare metal customers judge the provider when something physical breaks or a route changes. IBM documentation warns that hardware failures, software bugs, network issues and maintenance can cause outages, and that spreading applications across multiple data centers and PODs is necessary for availability (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). That is technically honest. But customers still experience failure through support response. Public product pages cannot tell us whether IBM's support is fast enough in the moment that a drive fails, a VLAN misbehaves, a Direct Link route is wrong, or a private-only server was ordered incorrectly.
The fourth missing number is abuse and reputation cost. Hosting networks attract legitimate enterprise workloads, but public IP space and dedicated servers also attract spam, scraping, bot activity, phishing infrastructure and high-risk resellers. PeeringDB and BGP records prove scale; they do not prove reputation quality. IBM's network-control posture, support processes and address management matter here because a dirty address range or repeated abuse incident can make a cheap server expensive. Public evidence does not let us score that directly.
These uncertainties should not be treated as defects in the article. They are the economics. The public record tells us why IBM would keep a server-control business. It does not tell us whether every rack, CPU generation and customer cohort earns attractive returns.
What a buyer would underwrite today
A large buyer deciding whether to place steady workloads on IBM Cloud bare metal would underwrite a different set of facts than a developer choosing a virtual instance. It would begin with identity and continuity: SoftLayer was acquired by IBM, the current product is IBM Cloud Bare Metal Servers, the API and classic infrastructure controls remain documented, and the network identity still appears in ARIN, PeeringDB and BGP data (https://rdap.arin.net/registry/entity/SOFTL, https://rdap.arin.net/registry/autnum/36351, https://www.peeringdb.com/net/1613 and https://bgp.tools/as/36351). It would then test the product promises: single tenancy, no provider hypervisor, hourly or monthly billing, fast provisioning, 20 TB cost-free classic bandwidth, private network inclusion, port speed options, redundancy choices, Direct Link, BGP, VRF and private data movement (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm, https://www.ibm.com/products/bare-metal-servers/pricing, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options and https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link).
The buyer would also test failure behavior. If a workload needs continuous availability, IBM's own documentation says multiple application servers and placement across data centers and PODs must be considered (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). If a buyer wants a lower-cost single server with no redundant link, it must accept that routine maintenance can disrupt communication. If the buyer wants Direct Link, it must understand that redundancy is created through BGP design and diverse connections, not by the existence of one service alone (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). If it wants private-only deployment, it must decide that at provisioning because public interface cannot be added later to a private-only server (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
A lender or acquirer would ask the harder questions IBM does not publish: recurring revenue by cohort, utilization by location, hardware age, data-center power cost, support ticket volume, public egress overage revenue, private-network cost, Direct Link attach rate, storage and backup attach, customer concentration, renewal rate on contract terms, and the number of accounts that still depend on older SoftLayer API behavior. It would separate healthy control-driven demand from inertia-driven legacy demand. The former deserves investment. The latter deserves migration planning and margin protection.
A regulator would care about control claims and customer clarity. Bare metal can help with isolation, but only if customers understand which obligations remain theirs. IBM's documentation is explicit that the customer manages the server and that backups of customer devices are not completed by IBM unless the customer initiates scheduled or one-time backups through relevant solutions (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm and https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery). A compliance-sensitive buyer should read that carefully. Single tenancy is not managed compliance. It is a physical and operational starting point.
The underwriting conclusion is balanced. SoftLayer gives IBM a credible control surface for workloads that do not fit neatly into abstract cloud. The public evidence supports a real network, real API continuity, real product mechanics and real hybrid-cloud relevance. But the public evidence does not support a simple claim that SoftLayer, as a legacy name, is a growth engine on its own. Its value is embedded: server control inside IBM Cloud, useful when the customer wants cloud without losing the machine.
Evidence register for the public claims
The acquisition and historical scale evidence comes from IBM's acquisition announcement, IBM's closing announcement, GI Partners' sale announcement, and the Los Angeles Times report on the reported $2 billion deal value: https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html, https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html, https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm and https://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html.
The current network and identity evidence comes from ARIN RDAP, PeeringDB, the PeeringDB API view and BGP.tools: https://rdap.arin.net/registry/entity/SOFTL, https://rdap.arin.net/registry/autnum/36351, https://rdap.arin.net/registry/entity/IBMC-24, https://www.peeringdb.com/net/1613, https://www.peeringdb.com/api/net/1613?depth=2 and https://bgp.tools/as/36351.
The bare-metal product and pricing evidence comes from IBM's bare-metal pricing page and IBM Cloud bare-metal documentation: https://www.ibm.com/products/bare-metal-servers/pricing, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs, https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery and https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr.
The API and control-plane evidence comes from IBM Cloud API references and the SoftLayer Development Network: https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference, https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-vra-api and https://sldn.softlayer.com/.
The private-connectivity and VLAN evidence comes from IBM Cloud Direct Link and VLAN documentation: https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link, https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs, https://cloud.ibm.com/catalog/infrastructure/direct-link-cloud-exchange and https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures.
The IBM strategic and financial context comes from IBM's investor page and 2025 annual report: https://www.ibm.com/investor, https://www.ibm.com/investor/services/annual-report and https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf.
The substitution and market-comparison evidence comes from AWS public IPv4 pricing, OVHcloud bare metal, Hetzner dedicated root servers, TrustRadius IBM bare-metal pricing summaries and the 2013 Hacker News discussion as an informal developer-market signal: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/, https://us.ovhcloud.com/bare-metal/, https://www.hetzner.com/dedicated-rootserver, https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricing and https://news.ycombinator.com/item?id=5819227.
Bottom line and watchpoints
SoftLayer's enduring lesson is that the cloud did not abolish the server. It changed how the server is bought, connected, automated and financed. IBM kept SoftLayer's server-control logic because some enterprise workloads still need physical isolation, predictable bandwidth, private routing, known placement and low-level operating choice. The fact that IBM now markets itself primarily around hybrid cloud and AI does not weaken that argument. It makes the argument more precise. Hybrid cloud needs places where old and new infrastructure can meet, and SoftLayer's design gives IBM one of those places.
The positive case is that IBM can keep monetizing SoftLayer's legacy as a high-control infrastructure option: classic bare metal for steady predictable operations, VPC bare metal for newer cloud patterns, Direct Link for private connectivity, SoftLayer API continuity for existing automation, and IBM's enterprise account relationships for workloads that cannot be served by low-cost hosting alone. The numbers that support this case are 13 original data centers, 100,000 devices, 21,000 customers, a reported $2 billion acquisition, 1,800 PeeringDB IPv4 prefixes, 450 IPv6 prefixes, 1-5 Tbps PeeringDB traffic, more than 11 million classic configuration combinations, 20 TB of cost-free bandwidth on classic, 10-minute-or-less VPC bare metal deployment, and 30-40 minute fast provisioning for classic servers.
The negative case is that control can become burden. If classic infrastructure is retained mainly because older workloads are hard to move, IBM must protect margin while carrying legacy support, old API behavior, hardware refresh, address reputation, data-center complexity and customer expectations. If cheaper bare-metal providers pressure commodity accounts and hyperscalers absorb high-level workloads into managed services, IBM must keep proving why its server-control layer belongs inside a premium hybrid-cloud relationship.
The watchpoints are concrete. First, watch whether IBM continues to improve both VPC bare metal and classic bare metal, rather than letting one quietly starve the other. Second, watch whether Direct Link, VRF and private-network controls become easier for customers without losing transparency. Third, watch public routing and PeeringDB changes around AS36351, because they show whether the network remains broad and current. Fourth, watch IPv4 pricing and address policy across the industry, because public address scarcity can strengthen the case for providers with disciplined allocation and included bandwidth. Fifth, watch IBM's annual reports for shifts in infrastructure, hybrid cloud and Red Hat emphasis, because SoftLayer's value is increasingly tied to how well IBM packages physical control with software strategy.
SoftLayer is not the face of modern IBM. That is the point. It is the part of IBM Cloud that still answers a stubborn buyer with a stubborn need: give me the convenience of cloud, but do not make the server disappear.