XICON BCN Group Hosting Ltd sells hosted capacity that still depends on racks, transit and repair windows

Summary

• XICON BCN Group Hosting Ltd has a concrete legal and network trail. Companies House lists BCN Group Hosting Limited as active, incorporated on 28 June 1991, with the previous name Xicon Limited until 10 September 2021, while RIPEstat identifies AS24633 as held by XICON BCN Group Hosting Ltd.
• BCN's own public material makes the infrastructure dependency unusually visible: the company describes private-cloud, colocation, backup, HSCN-facing hosting, GPU and transit services across three data-centre facilities, with primary data homed in the UK and primarily within Greater Manchester based data centres.
• RIPEstat's 12 July 2026 routing view showed AS24633 announced 2 IPv4 prefixes, 185.108.232.0/22 and 185.108.233.0/24, covering 1,024 IPv4 addresses, with no IPv6 announcement in that view. Public BGP cross-checks from Hurricane Electric, BGP.tools and IPinfo broadly agree on the small active footprint.
• The resilience question is not whether Xicon/BCN exists. It is whether a customer's particular service is on one primary supplier data centre, a multi-site design, a backup-only arrangement or a separately priced disaster-recovery service. BCN's cloud service schedule says a single primary supplier data centre is the default unless disaster recovery is specified in the order.
• The network evidence grade is Medium. Identity and current routing evidence are strong, but PeeringDB returned no network profile for AS24633, RPKI validation was unknown for the two current prefixes, and public sources do not prove multi-carrier transit, rack-level separation, spare capacity or recovery performance for a given customer.

The Xicon name survived because the infrastructure still matters

The most important thing about XICON BCN Group Hosting Ltd is the continuity between an old private-cloud provider and the live network footprint. A buyer who searches only for "Xicon" may see a company that was acquired. A buyer who searches only for BCN may see a modern managed-services group. A buyer who follows the infrastructure records sees both: an older Xicon company name that became BCN Group Hosting Limited, a BCN acquisition story that explicitly describes Xicon Cloud as a private-cloud and healthcare infrastructure asset, and an autonomous system that still carries the Xicon label in public routing data.

That chain matters because hosted capacity is rarely a pure software product. The monthly bill may be for cloud servers, backup storage, remote desktops, colocation, HSCN-facing application hosting or managed infrastructure support. The dependency underneath is still physical. It includes racks, power, cooling, storage arrays, hypervisors, router ports, public addresses, private circuits, support staff, supplier contracts and the right to get someone into a data hall when a fault does not clear from a console.

Companies House gives the legal continuity. The Companies House overview lists BCN Group Hosting Limited as an active private limited company, incorporated on 28 June 1991, with the previous name Xicon Limited from 28 June 1991 to 10 September 2021. It also lists business activities that include computer facilities management and data processing, hosting and related activities. That is not a resilience certificate, but it places the company in the right legal and operating category for this article.

BCN's own announcement supplies the strategic reason. In its January 2021 note, BCN Group said it had acquired Xicon Cloud to strengthen management and support of business-critical applications in secure private cloud environments. The same note described Xicon Cloud as Warrington-based, established in 1991, active in public-sector healthcare, accredited to connect into and use the NHS Health and Social Care Network, and known for resilient cloud platforms for business and mission-critical applications.

Those are strong positioning claims, and they should be read as claims. The practical question is what a customer can prove now. The live edge is RIPEstat's AS overview for AS24633, which identifies the holder as XICON BCN Group Hosting Ltd and marks the ASN as announced on 12 July 2026. That makes the name more than an archive. It is tied to current public routing.

The service catalogue points to real hosting dependencies

BCN's public service pages do not present Xicon/BCN as a hyperscale abstraction. They describe the very parts that matter in a failure. The BCN data-centre page says the company offers data-centre services, colocation, Infrastructure as a Service, cloud backup, HSCN connectivity, GPU in the cloud and resilient internet transit. It also says BCN Group Hosting operates three data-centre facilities for cloud-based data-centre solutions and colocation clients.

That service mix is useful because it narrows the risk model. A customer is not only buying a place to run a virtual machine. It may be buying a managed private-cloud environment, a rack-power-cooling-and-connectivity package, storage for backups, a healthcare-facing connection path, a GPU platform, or public IP transit. Each product fails differently. A VM can fail because a host or storage pool fails. Colocation can fail because power, cooling, access or remote hands fail. Backup can fail because replication did not complete or because restore bandwidth is under-sized.

HSCN-facing service can fail because the service, the access path or the customer's permitted connectivity pattern fails.

The page's wording also shows where marketing clarity stops. "Three data centre facilities" is a valuable claim, but it does not by itself prove that every customer gets active-active placement across all three, that every facility has equal capacity, or that one facility can absorb another facility's customers at peak load. It says there is a multi-site estate. A customer's order, architecture diagram, recovery test and support terms decide whether that estate has been converted into usable resilience.

The G-Cloud listing for BCN Private Cloud - Healthcare is another public window into the product boundary. It lists cloud hosting for healthcare customers, disaster-recovery options, high-speed network connectivity, migration support, phone support, ticket support, and a managed-cloud availability target of 99.9 percent measured monthly. It also says system requirements include suitable internet connectivity. That last point is easy to skip, but it is central: the hosted platform can be available while a customer's access path, DNS, VPN, firewall or HSCN design is the failing component.

The public-sector documents also show that managed cloud is not one bundled service. The G-Cloud pricing PDF breaks managed-cloud services into virtual-machine components, storage, public IP addresses, VPN services, support, Veeam Cloud Connect, professional services and other priced items. That pricing structure reinforces the article's main point: hosted capacity is an assembled operating surface, not a magic pool of unlimited repair.

Single primary site language changes the risk conversation

The most consequential line in the public material is not the most promotional one. The BCN Cloud service schedule says the BCN Cloud service is made available in a single primary supplier data centre unless a disaster recovery service is specified in the order. If disaster recovery is specified, the order is expected to identify secondary data-centre infrastructure, disaster-recovery service components, software licences and secondary network access services.

That is a healthy contract distinction because it prevents a buyer from assuming that "cloud" automatically means two live sites. It also creates a hard procurement test. If a customer needs a service to survive the loss of one data hall, one storage domain, one upstream, one firewall cluster or one remote-hands queue, the customer needs to see whether the order actually buys that design. A data-centre estate can be multi-site while a particular service remains single-primary. A backup can be off-site while production remains down until restoration.

A disaster-recovery option can exist while the customer has not bought it, tested it or sized it.

That distinction also affects data sovereignty. BCN's data-centre page says data will primarily be homed in the UK within one of its Greater Manchester based data centres, while noting that international data-centre solutions can be provided through multiple international providers. The important word is "primarily". A customer with regulated data needs a placement map, not a country label. It should ask where production data sits, where backups sit, where logs sit, where support records sit, where administrative access originates, and which suppliers can touch the service.

The same issue appears in exit planning. The G-Cloud listing says customers can initiate data extraction through normal data access methods before contract end, and that BCN Group can assist with extraction under a separate professional-services order. It also says customer data is kept for 60 days after termination and then deleted, including cached or backup copies. Those terms are not unusual, but they mean migration is not something to discover during an outage or commercial dispute.

If the customer needs a complete exit, it should test the export while the service is healthy, verify the format, and identify what still requires paid assistance.

In other words, the article's title is not a complaint about BCN. It is a way to price the service honestly. If the customer buys one primary site, it should not describe the result as multi-site recovery. If the customer buys a multi-site design, it should see the recovery path tested. If the customer buys backup only, it should know how long a full restore takes and which dependencies must be alive before restoration can start.

AS24633 is small, visible and current

The public routing evidence is compact. RIPEstat routing status for AS24633 showed, for 12 July 2026, two announced IPv4 prefixes covering 1,024 IPv4 addresses, no IPv6 prefixes in that view, full visibility from 327 of 327 RIPE RIS IPv4 full-feed peers, and one observed neighbour. The same view listed first-seen route evidence in 2002, before the current RIPE record date, and a last-seen current route for 185.108.232.0/22 on 12 July 2026.

The current prefix list is precise. RIPEstat announced prefixes showed 185.108.232.0/22 and 185.108.233.0/24 as current over the 28 June to 12 July 2026 window. RIPEstat prefix overview for 185.108.232.0/22 and the prefix overview for 185.108.233.0/24 both identified AS24633 and XICON BCN Group Hosting Ltd. The RIPE registry browser for 185.108.232.0/22 links the allocation to UK-XICON-20150713, GB, ORG-XL23-RIPE and XICON-MNT.

Independent routing pages broadly support the same outline. Hurricane Electric's AS24633 page lists BCN Group Hosting Ltd, the United Kingdom, two originated IPv4 prefixes, no IPv6 prefixes and 1,024 IPv4 addresses. BGP.tools for AS24633 describes the network as active under RIPE, with two IPv4 prefixes and no IPv6 prefixes. IPinfo's AS24633 page names BCN Group Hosting Ltd, gives the ASN type as hosting, lists 1,024 IPv4 addresses and reports no IPv6 addresses.

This is enough to say there is a current public network surface. It is not enough to say the network is large, multi-carrier, or self-sufficient under stress. A /22 plus a more-specific /24 can support real hosted services, management endpoints, customer-facing platforms and backup systems. It can also be a small edge behind a broader private-cloud estate that uses other providers' addresses for some services. The route table tells us where to start, not where to stop.

The missing IPv6 announcement is also worth noting carefully. A provider can deliver useful services without public IPv6 on its own ASN. It may use public-cloud platforms, customer addressing, upstream-assigned IPv6 or private connectivity. But for customers with dual-stack requirements, public evidence does not show AS24633 originating IPv6 on 12 July 2026. That should be turned into a design question: which services are dual-stack, who routes the IPv6 path, and how is parity tested?

The upstream picture is not a diversity proof

Transit evidence is where the public view becomes sharply limited. RIPEstat ASN neighbours showed one observed neighbour for AS24633 on 12 July 2026: AS174, Cogent Communications. Hurricane Electric listed IPv4 peer observations including AS174 and AS1239, and BGP.tools listed AS174 as an upstream. The RIPE database whois view for AS24633, however, includes older import/export lines referencing AS43531 and the AS-XICON set. Those differences are normal in public routing data, but they are exactly why observed BGP should not be treated as a contract register.

For customers, the practical question is not whether a public page can name a transit provider. The question is whether the service has enough independent path capacity to survive the failure being planned for. One upstream tie can be perfectly adequate for a low-risk workload or a backup service that has tolerant recovery objectives. It may be inadequate for a healthcare-facing, production application that expects continuous reachability. Two observed peers can still converge onto the same commercial supplier, building entrance, router pair or maintenance window.

PeeringDB does not fill the gap here. A direct PeeringDB API query for AS24633 returned no entity found at the time of review. PeeringDB's own about page describes it as a user-maintained database for interconnection, exchange points, data centres and facilities. Absence from PeeringDB does not mean absence from facilities or exchanges. Many enterprise and managed-hosting networks do not maintain a public profile. But the absence means public readers cannot use PeeringDB to confirm facility count, exchange attachments, policy, traffic levels, route-server use or public interconnection contacts.

That should change the assurance request. A customer should ask BCN which transit providers are used for the ordered service, whether the service depends on AS24633 or another provider edge, whether upstreams are physically diverse, whether there is enough committed and burst capacity after one path fails, and whether the customer will be told when transit or facility suppliers change. It should also ask whether the status page's "External Connectivity" component maps to the customer's circuit, public edge, HSCN path, VPN service or only a central managed platform.

Route security deserves the same concrete treatment. RIPEstat RPKI validation for 185.108.232.0/22 with AS24633 and for 185.108.233.0/24 returned unknown status, with no validating ROAs, in the snapshot used here. Unknown RPKI is not the same as invalid. It does mean the public route-origin evidence did not show positive ROA validation at that moment. For an operator advertising services to regulated or mission-critical customers, this is a useful security hygiene question rather than a broad verdict.

Data centres are local only after the service order says so

BCN's public page gives a reassuring locality signal: data primarily homed in the UK within Greater Manchester based data centres. That is more specific than a generic UK cloud claim. It aligns with Companies House and the broader Manchester/Warrington history of Xicon and BCN. It also fits IPinfo's Manchester traceroute and router observations, although geolocation and traceroute evidence should be treated as signals rather than facility proof.

The signal still needs translation into service terms. A customer might buy BCN-managed infrastructure that is hosted in BCN-operated facilities. It might buy Microsoft Azure management from BCN, where the production region is a Microsoft region and BCN supplies design, monitoring and support. It might buy backup into BCN Private Cloud while production remains on-premises or in another cloud. It might buy colocation, where the customer owns the hardware and BCN supplies rack, power, cooling, connectivity and support wrap. Those are different locality stories.

The G-Cloud pricing document explicitly mentions public, private and hybrid cloud environments and multiple datacentres in North West England. It also describes Managed Azure services separately from BCN Managed Cloud services. That separation is critical. If data sovereignty is the concern, the buyer should not ask "Is BCN UK based?" and stop. It should ask which service family is being bought, what legal entity contracts the service, where production workloads run, where data is replicated, where backups are stored, who administers the environment, and whether support telemetry or tickets leave the expected geography.

Healthcare makes this sharper. NHS England's guidance on public-cloud connectivity to HSCN explains that cloud services interacting with HSCN require careful connectivity design, roles and policy alignment. BCN and Xicon's public materials cite HSCN-facing capability, but a buyer still needs the specific architecture. A provider's accreditation or historic capability does not prove that a given application is connected, segmented, encrypted, logged and supported in the way the customer's risk owner expects.

The operating lesson is simple. Locality is not a label on the provider. It is a map of data states. Live application data, backup data, logs, monitoring records, authentication records, support tickets and retained termination data can have different locations and different access paths. A customer should demand a plain placement matrix and keep it current.

Backup is capacity, not merely a copy

BCN's backup services page describes managed cloud backup powered by Veeam Cloud Connect, off-site backup, immutable on-site options, replication for disaster recovery and support for recoverability. This is directly relevant to XICON BCN Group Hosting Ltd because backup is one of the clearest places where hosted capacity becomes a physical dependency. A successful backup is not only a stored file. It is storage capacity, retention policy, network throughput, restore orchestration, authentication, monitoring, and staff availability during a stressful incident.

The difference between backup and recovery is where many cloud buyers overstate resilience. A backup can exist, be encrypted and be off-site, while the restore plan remains too slow for the business. A backup can protect data but not the application configuration, firewall rules, DNS records, secrets, identity links, print integrations, database jobs or reporting schedules that make the workload useful. A backup can also depend on the same support team and same status communications as the failed platform.

BCN's public material contains useful positive signals. It discusses Veeam, off-site protection, on-premises immutable options and recovery. The G-Cloud listing says metrics include CPU, disk, HTTP response status, memory, network and active instance counts. The status page publishes separate components for Hosted Platform, Veeam Cloud, Storage Platform, External Connectivity, Hosted Email Services, Remote Desktop Platform, Azure Services and Vendor/3rd Party. That component separation suggests the company understands that faults occur by layer.

But component labels are not a customer restore test. A buyer should ask when the last full restore was performed, how much data was restored, whether the restore target was a separate site, whether the restored workload was user-tested, and how long the recovery took under measured bandwidth constraints. It should also ask who declares that production is unrecoverable and who authorizes a failover or restore. During an incident, those authority questions can consume more time than the technical recovery.

Backup also interacts with exit terms. If customer data becomes inaccessible after termination and is then deleted after a retention period, the customer's safest path is to exercise extraction while service is live and account standing is clear. An export plan that depends on professional services should be ordered and tested before the customer is under pressure.

Support is a dependency with its own capacity limit

BCN markets support heavily, and that is appropriate for managed infrastructure. The data-centre page refers to dedicated on-call support and on-the-ground engineers ready to provide remote hands across data centres. The G-Cloud listing describes support hours, priority response targets, phone support, online ticketing and more than 50 dedicated support engineers across three UK offices. The BCN Hosted status page also gives customers an independent place to see component status and subscribe for updates.

Those are meaningful operating signals. They show the provider exposes service state publicly, names components that map to hosted infrastructure, and has published support expectations for at least one public-sector service listing. They do not, by themselves, prove support capacity during a regional outage, a supplier incident, a cyber recovery, a holiday period or a fault that affects many customers at once.

Support has a queueing problem. A provider can have qualified engineers and still hit a bottleneck if too many customers need manual recovery, firewall changes, storage restores, circuit escalation or account assistance at the same time. Remote hands can also bottleneck at the facility operator. If a fault requires a third-party data-centre engineer, a carrier repair team, a hardware supplier, a Microsoft support case or a Veeam escalation, the customer's effective support path includes those external queues too.

For a customer, the test is not only "Is there 24/7 support?" It is "What happens when my severity-one incident coincides with a platform incident?" The customer should ask whether priority is assigned by impact, contract tier, healthcare criticality, time received or technical severity. It should ask whether phone support reaches the people who can change the platform, or only intake. It should ask whether the status channel is hosted independently of the systems it reports on. It should ask how many customers can be restored in parallel if a shared storage platform or primary data centre has a major incident.

The support model also affects change control. Managed cloud is constantly being changed: hosts are patched, backup jobs adjusted, firewall rules modified, transit maintained, storage expanded and monitoring tuned. Customers need notice for planned work, a way to distinguish customer-caused faults from platform faults, and a record of changes that might explain a failure. Support is not a courtesy layer. It is part of the infrastructure product.

Billing and migration can break the same service as a router

Cloud customers often separate technical faults from commercial administration, but hosted infrastructure does not fail along such neat lines. A suspended account, an expired support entitlement, a disputed professional-services order, a delayed cross-connect charge, a missed backup-retention change or an incomplete migration order can turn into downtime just as surely as a bad line card. The Xicon/BCN public material makes this worth saying because the service is modular. The pricing documents split capacity into compute, RAM, storage, public IP addresses, VPNs, Veeam Cloud Connect, support and professional services.

That is normal commercial packaging, but it also means the customer's live service may depend on several separately described items staying aligned.

The risk is not that modular pricing is bad. It is that customers may misunderstand which module carries which failure. A virtual machine line item does not necessarily include the public address, the backup policy, the VPN design, the support tier, the restore capacity or the professional-services time needed to move an application. A backup line item does not necessarily include application rebuild, firewall change, identity repair or user testing. A disaster-recovery option does not help if the order never specified it, if secondary network access is not in place, or if the customer has never tested the failover path.

This is where billing becomes infrastructure. If a customer has to add a VPN, increase storage, buy additional public IP addresses, extend retention, order a second site or purchase migration help during an outage, the commercial approval path becomes part of recovery time. A buyer should therefore ask which changes can be made under an existing support plan, which require a new quote, which require purchase-order approval, and which can be done during a live incident before paperwork catches up. The answer will be different for a small professional-services request than for a material architecture change.

The same is true on the way out. BCN's G-Cloud listing says a customer may initiate extraction through normal data access methods before contract end, and that BCN can assist under a separate professional-services arrangement. That is a reasonable commercial model, but it places responsibility on the customer to test the route. A customer that waits until termination week to discover that a large export needs paid assistance, additional bandwidth, a storage target or a support slot has turned migration into a capacity problem.

Migration also exposes hidden dependencies. Moving a workload away from a private-cloud platform is rarely just copying virtual disks. The customer may need current firewall rules, VPN configuration, DNS data, monitoring history, backup policy, user and group mappings, SSL certificates, scheduled tasks, service accounts, application secrets and platform-specific notes from support tickets. Some of those items may be available through a portal. Some may require BCN staff. Some may belong to the customer but be undocumented after years of managed service. A clean exit plan should say who supplies each part and how long it takes.

For XICON BCN Group Hosting Ltd, this is the final practical test of hosted capacity. The company has enough public evidence to show a real infrastructure service, but a customer's resilience is only as good as the specific order and operating routine. The safest buyer treats billing, support tier, migration assistance and data extraction as live dependencies, not back-office details. That approach makes the commercial surface part of the resilience design before a failure forces everyone to negotiate under pressure.

Installed capacity is not the same as usable capacity

BCN's public evidence supports the existence of a real hosted estate: three data-centre facilities, a managed cloud offering, colocation, backup, status components, public-sector service listings and current routed IPv4 space. The harder question is how much of that estate is usable after the first failure. Installed capacity is what the provider has in normal operation. Usable capacity is what remains when a data centre, upstream, router, storage domain, backup repository, account system or support queue is impaired.

This distinction is especially important for small routed footprints. AS24633's public IPv4 footprint is 1,024 addresses, with no public IPv6 origin shown in the snapshots used here. That does not cap the entire private-cloud estate, because many workloads may use private addressing, VPNs, NAT, provider services or public-cloud addresses. It does, however, show that the public ASN is not a large global transit network. Customers should not infer broad route diversity from a small public edge.

Usable capacity is also product-specific. A colocation client may need power, cooling, access and cross-connects. A managed VM client may need hypervisor, storage, backup, console, firewall and support. A backup client may need repository health, restore compute, bandwidth and local target capacity. A healthcare application may need HSCN-aligned connectivity and evidence that the path is designed for the right consumer access pattern.

The public sources give several useful questions. The service schedule asks whether disaster recovery is in the order. The data-centre page asks whether the "three data centre" estate is active for this customer. The routing data asks whether AS24633 is the customer's live ingress and whether the transit path is diverse enough. The status page asks which component covers the service. The G-Cloud exit language asks whether data extraction is easy enough to use during a controlled migration.

This is how procurement should treat hosted capacity. Do not accept the strongest public claim as the default service. Start from the ordered service, then trace the physical and operating dependencies behind it. If the ordered service is single-primary with backup, call it that. If it is active across sites, ask for the test evidence. If it relies on a single public upstream, price that risk. If another cloud or carrier supplies a critical piece, include that supplier in the recovery plan.

How customers should test XICON BCN Group Hosting Ltd

A useful test starts with identity. Ask whether the ordered service is contracted with BCN Group Hosting Limited, BCN Group Ltd or another group company, and ask which legal entity owns the relevant service obligations. The Companies House record and RIPE records are public anchors, but the contract decides service accountability.

Then test placement. Ask which facility or facilities host production, backup and disaster-recovery components. Ask whether the primary site is one of the Greater Manchester based data centres referenced publicly, whether the service uses an international provider, and whether any Microsoft Azure or other public-cloud component is in scope. Ask whether customer data, logs, monitoring and support records share the same location story.

Next, test the network. Ask whether customer traffic uses AS24633, provider-assigned public cloud addresses, customer addresses, private circuits, HSCN paths or VPNs. Compare the answer with RIPEstat announced prefixes, Cloudflare Radar's AS24633 routing page, BGP.tools, Hurricane Electric and IPinfo. If the service relies on AS24633, ask about transit, RPKI, DDoS handling, maintenance windows and customer notification for routing changes.

Then test recovery. Ask for the exact recovery architecture in the order: single primary, backup-only, warm standby, active-standby, active-active or another design. Ask when the last recovery test occurred, what failed over, how long it took, what data was lost, and whether customers or only internal staff validated the result. Do not treat backup retention as a recovery-time answer.

Finally, test exit. Ask for a complete sample extraction of files, databases, images, logs, firewall rules, DNS dependencies, user records and configuration. Ask which parts are self-service, which parts require professional services, and whether the export can be performed while production is degraded. The best time to learn this is before the provider is under pressure.

The evidence grade

XICON BCN Group Hosting Ltd earns a Medium public network evidence grade. The identity evidence is strong: Companies House, BCN's acquisition material, RIPEstat, RIPE database records, BGP.tools, Hurricane Electric and IPinfo all point to a real UK hosted-infrastructure subject rather than a generic brand shell. The service evidence is also better than thin: BCN describes three data-centre facilities, private cloud, colocation, backup, HSCN-facing hosting, support and status components.

The grade stops at Medium because the strongest public facts do not prove the hardest resilience claims. AS24633 is current but small. RIPEstat showed two IPv4 announcements and no IPv6 announcements on 12 July 2026. RPKI validation was unknown for the two current prefixes in the RIPEstat checks. PeeringDB returned no public network profile. Current neighbour observations point to Cogent, but they do not establish commercial diversity, physical diversity or spare capacity. BCN's own cloud service schedule says a single primary supplier data centre is the default unless disaster recovery is specified.

That evidence mix leads to a practical conclusion. XICON BCN Group Hosting Ltd should not be treated as an unverified ghost; it has public legal, commercial and routing evidence. It also should not be treated as automatically resilient because it sells cloud services. The resilience is in the ordered architecture: which racks, which site, which transit, which support path, which backup repository, which recovery contract and which export route. Customers who make those questions explicit will understand the service they have bought. Customers who rely on the word cloud alone may discover the physical system only when a repair window begins.