Summary
- Wholesale Communications Group Pty Ltd remains an active Australian private company and appears in Vocus Group Holdings' latest public modern-slavery statement. That supports corporate continuity inside the Vocus group, not a conclusion that WCG still operates as an independent retail cloud brand.
- APNIC marks AS18104 active and associates it with the WCG name and Vocus as registrant. Independent routing observation, however, shows no current IPv4 or IPv6 announcements from AS18104 and records its last observed route in June 2012. A registered autonomous system is not the same thing as a live delivery network.
- PeeringDB lists one WCG facility presence at Equinix SY1/SY2 in Sydney and no public exchange connection. The facility declaration was last updated in 2016, so it is historical operating evidence rather than proof of a current rack, powered server fleet or cross-connect.
- Current Vocus material offers infrastructure capacity from Sydney, Melbourne and Perth and says the group operates 14 Australian data centres while connecting to more than 150 others. Those claims establish a plausible parent-group delivery surface, but they do not disclose which sites, racks, resource pools or support terms apply to a customer buying under the WCG name.
- Public Vocus terms expose the machinery beneath hosted capacity: connectivity may be separate, disaster recovery must be expressly ordered, customers carry important backup and restore duties, assigned IP addresses are not portable, and maintenance or third-party failures can limit remedies. A buyer needs a site-specific architecture and an executable migration plan before treating nominal capacity as recoverable capacity.
The WCG name has survived more clearly than its independent network
Hosted infrastructure is often bought through a name that hides several layers of machinery. A customer may see one invoice and one support number while the service itself crosses a legal subsidiary, a group network, leased data-centre space, a virtualisation platform, third-party software and field technicians. That is not necessarily a defect. Integrated providers routinely use several group companies and suppliers. The risk arises when the customer mistakes a durable name for a self-contained operating system.
WCG is a particularly sharp example. The Australian Business Register's current entry for ABN 21 109 626 011 identifies Wholesale Communications Group Pty Ltd as an active Australian private company, GST-registered since June 2004, with its main business location in Victoria. The Australian Government's 2025 modern-slavery statement entry for Vocus Group Holdings includes Wholesale Communications Group Pty Ltd among the reporting entities. Those are strong identity facts. They show that WCG has not simply vanished as a legal name.
They do not show that WCG currently markets virtual servers, bare metal, storage or managed hosting in its own right. WCG's historical position is easier to establish. M2's 2010 annual report says that M2 acquired Wholesale Communications Group in May 2007 and describes M2's broader retail suite as including corporate virtual private networks and remote hosting. The filed annual report also describes the acquired business as part of M2's wholesale expansion. Vocus's 2020 annual report later lists Wholesale Communications Group Pty Limited as a wholly owned Australian subsidiary.
The corporate sequence is therefore supportable: WCG became part of M2, and the M2 group became part of Vocus. But history is not a current product sheet. It would be unsafe to convert the phrase remote hosting in a 2010 report into a claim that a specific WCG compute service is available in 2026 with the same platform, locations or contract. The current operating question is narrower: what resources still carry WCG's identity, what infrastructure can be verified at Vocus group level, and where does the evidence stop?
That distinction is commercially important. If a buyer signs with Wholesale Communications Group Pty Ltd but receives a service designed, operated or supported through other Vocus entities, the order should identify which company supplies each component, which terms prevail and where liability sits. Corporate continuity can be reassuring. It is not a substitute for knowing which entity controls the rack, the network port, the backup system and the technician who will act at 3am.
The public sales surface is now a Vocus surface
WCG's own domain still exists, but it does not present a current public sales catalogue. As observed in July 2026, wcg.net.au resolved to an IPv4 address and retained WCG and M2-era mail and name-server hostnames, while ordinary web requests did not return a working WCG site. The public DNS summary for wcg.net.au reports the address 203.132.224.176, mail exchangers under m2core.com.au, and authoritative servers under wcg.net.au. It also reports no configured web server. DNS is dynamic and the third-party summary can lag changes, but it matches the broader pattern: the namespace remains maintained without functioning as a current product storefront.
The address itself is not evidence that AS18104 hosts the site. The RIPEstat network-information result for 203.132.224.176 places it in a prefix originated by another Vocus network, not AS18104. The APNIC record for the address supplies the registry context for that block. A live A record therefore demonstrates continuity of the domain and group network, but it cannot be used as a sample workload proving an active WCG cloud.
The visible current offer sits on Vocus's public pages. Vocus's Infrastructure as a Service page describes resource pools in Sydney, Melbourne and Perth, hosted in its data centres and interconnected by its core network. It advertises allocations of processing, memory and storage, several bandwidth options, backup pricing and round-the-clock support. The associated IaaS product sheet names the same three delivery points and lists backup policies and a service desk.
Vocus separately says on its data-centre solutions page that it operates 14 data centres across Australia and connects into more than 150 additional locations, including partner facilities. This is meaningful evidence that the parent group has a broad physical and interconnection estate. It is still a marketing-level aggregate. It does not name the 14 sites on that page, state the available power or compute inventory at each one, or map the three IaaS resource pools to a particular WCG order.
The careful reading is not that WCG has no service. It is that public evidence supports a current Vocus group service and a continuing WCG corporate identity, while leaving the current commercial relationship between them unstated. A prospective customer should ask whether WCG is the contracting supplier, a legacy account name, a reseller, an operating subsidiary or simply the historical identity attached to some network resources. The answer determines which support portal, service schedule, privacy notice and termination process actually govern.
AS18104 is registered but not presently announcing routes
WCG's autonomous system number is the most tempting piece of evidence to overread. APNIC's RDAP record for AS18104 marks the number active, names it WCG-AS-AP and describes Wholesale Communications Group as a national wholesale communications provider in Sydney. The registrant entity is Vocus Pty Ltd. The record also retains a WCG network-operations contact while its abuse role points to Vocus. That combination is consistent with a resource that has travelled through a corporate integration without losing all of its older labels.
An active registry status does not mean the number is actively originating traffic. The distinction is basic but consequential. A regional internet registry records assignment, registration contacts and administrative standing. Global route collectors observe what networks are actually announcing. The two datasets answer different questions.
RIPEstat's routing-status result for AS18104 reports no announced IPv4 or IPv6 space at the July 2026 observation time, no observed neighbours and zero visibility among its route-collector peers. It records the first observed route in January 2002 and the last observed route, 125.168.0.0/16, on 19 June 2012. Its announced-prefixes result returns no prefixes in the current observation window. Cloudflare Radar's routing view for AS18104 offers a second public observation surface, while Hurricane Electric's AS18104 page preserves the network identity and historical routing context.
These observations do not prove that every device once associated with WCG has been switched off. An autonomous system can remain registered while its addresses are announced by another group network, used internally, held for future use or no longer needed. Services can also run behind provider addresses without the old ASN appearing in the public route. What the data does establish is that AS18104 should not be presented as the current independent path by which hosted WCG workloads reach the internet.
The administrative routing policy in APNIC still names AS9942, AS2764 and AS9654 in import statements. Those statements are not current transit measurements. Registry policy text can remain long after topology changes, and the absence of present announcements means there is no AS18104 route on which to observe those neighbours now. Listing the three numbers as live upstream diversity would turn historical configuration text into an unsupported operational claim.
There is a useful cross-check in Vocus's current cloud contract. The Vocus Cloud Service Schedule lists several autonomous systems under which Vocus says it maintains and operates its network for Cloud Internet. AS18104 is not in that list. Vocus reserves the ability to add or remove numbers, so the list is not immutable. Even so, it reinforces the conclusion from route observation: present cloud reachability should be evaluated as a Vocus network design, not inferred from the legacy WCG ASN.
One old Sydney facility record cannot carry a national capacity claim
PeeringDB's network entry for WCG associates AS18104 with one facility, Equinix SY1/SY2 in Sydney, and no public internet exchange. The entry labels the network as regional, mostly inbound and selective in its peering policy. It discloses no traffic level and no IPv4 prefix count. Its facility information was last updated in March 2016, its contact information in March 2016, and the network record itself in July 2022.
This is evidence, but it has a long half-life. PeeringDB is maintained by participating organisations. A network-to-facility row means the entity represented the network as present there; it does not disclose whether that presence was a router in a full rack, a small allocation in shared space, a remote port, a cross-connect delivered by another party or an arrangement that later changed. The age of the facility update is especially important given the lack of current AS18104 announcements.
Equinix SY1 and SY2 are substantial Sydney interconnection sites, yet the attributes of those buildings cannot be assigned automatically to WCG. The public row does not state rack units, power allocation, number of feeds, cross-connect count, server inventory, storage architecture or remote-hands entitlement. It does not say that WCG owns the site. It does not even prove that the 2016 configuration remains installed in 2026. The proper conclusion is that WCG had a declared Sydney facility presence in the interconnection database, with current status unverified.
The lack of a public exchange row matters in a similarly limited way. It means PeeringDB does not currently show AS18104 on an exchange LAN. It does not exclude private interconnection, paid transit, remote peering or reachability through another Vocus ASN. But combined with zero current routes, it supplies no basis for claiming current WCG peering diversity or independent exchange reach.
Vocus's wider footprint should be treated separately. The parent group's current site claims three IaaS delivery cities, 14 operated Australian data centres and connections to more than 150 additional data-centre locations. Its legal page includes schedules for its own colocation facilities and for third-party operators including Equinix and NEXTDC: https://www.vocus.com.au/help-and-support/legal-contracts. This breadth can support a resilient service if the customer actually buys the relevant sites, paths and replicas. It cannot retroactively make the WCG PeeringDB row a three-city compute platform.
The evidence that would settle the issue is straightforward: a current service order identifying the delivery facility or zone, a rack or virtual-resource allocation, network handoff details, and written confirmation of the operating and contracting entities. Without those items, the public footprint is best described as one historical Sydney declaration plus a larger, current group estate whose allocation to WCG-branded customers is unknown.
Capacity is a chain of allocations, not a number on a product page
Cloud capacity looks divisible because it is sold in small units. A buyer can request another virtual processor, gigabyte of memory or storage volume without seeing a server installed. The economic promise is that a shared platform will absorb that request more efficiently than the buyer's own hardware. The physical limit has not disappeared; it has moved behind an allocation system.
Vocus's IaaS schedule makes that boundary unusually visible. It defines virtual machines in purchased processing, memory and storage units, while stating that CPU time will be balanced between requesting resources if there is contention. It says created storage capacity cannot be decreased. It also says customers remain liable for the ordered allocation even when actual use is lower. These clauses do not reveal current utilisation, but they show why ordered, installed and usable capacity are different quantities.
Ordered capacity is what appears in the service order. Installed capacity is the hardware, storage and network equipment physically available in the relevant resource pool. Usable capacity is the portion that can be allocated without violating performance, resilience or power constraints. Recoverable capacity is smaller again: the portion that remains available, or can be restored within the required time, when a host, storage system, rack, site or path fails.
For WCG, none of those quantities is published at company level. There is no public server count, processor generation, storage medium, rack allocation, committed power, utilisation figure or spare-host ratio tied to WCG. Vocus's public material gives product dimensions and locations, but not free inventory. A three-city platform can still have uneven headroom. A city may be available for new orders while lacking enough idle capacity to absorb all workloads from another city during a regional failure.
Hardware stock is part of the same equation. A platform can have spare virtual capacity until a motherboard, controller, optical module or disk model fails. Restoration then depends on compatible parts, vendor support and a technician with site access. The relevant question is not whether the group is large enough to purchase equipment. It is whether the contracted service has replacement stock in the right city, within the right security boundary, and whether replacement time is included in the restoration target.
Power is another allocation. Vocus's current NEXTDC service schedule defines racks with an agreed power allocation and describes conditioned power as finite. It warns that excess use can affect the customer, other customers and cooling. The schedule is for a third-party colocation service offered by Vocus, not proof that WCG uses NEXTDC. Its value is explanatory: even in a highly engineered facility, saleable rack space is constrained by contracted kilowatts, balanced feeds, cooling and operating rules.
The result is a more demanding definition of capacity. A buyer should not ask only how many virtual processors can be ordered. The useful questions are how much failure headroom exists in the chosen city, whether capacity is reserved at the recovery site, which components are stocked locally, and what happens when a repair requires third-party approval or a change window.
Transit diversity belongs to the delivered service, not the corporate family
The current absence of AS18104 routes does not mean a WCG-contracted service would be unreachable. It means the customer has to identify the actual delivery network. The Vocus cloud schedule says Cloud Internet may be reached through Vocus-operated autonomous systems and that the international network includes peering and transit with numerous networks. It also reserves Vocus's right to change those arrangements without notice.
That is a group-level resilience claim, not a site-specific path diagram. A virtual machine in Sydney might reach the internet over redundant routers and several upstreams; it might also depend on one customer firewall, one access circuit or one unprotected handoff. A private network may avoid the public internet while depending on a single last-mile provider. Two contracts can share the same cloud resource pool and have very different failure surfaces.
The schedule states that connectivity is not included unless explicitly stated. Access can be through the internet or a private network as specified in the order. That clause prevents a common category error: buying compute does not necessarily buy a diverse path to it. The buyer needs to see the internet service, private connection, cross-connect and customer-side equipment as separate components, each with its own protection level.
Vocus's Cloud Connect product sheet says the group reaches more than 100 public data centres and supports private connections to major cloud providers, with Layer 2 and Layer 3 options. Such reach can reduce dependence on public internet paths. But a connection to a cloud provider is not automatically redundant. Port count, metro diversity, router diversity and the cloud provider's own requirements still matter.
The same point applies to exchange reachability. A carrier may peer widely under its main ASN while a legacy subsidiary ASN has no exchange port. Customers care about the route their packets actually take, not which registrations exist elsewhere in the group. The service design should identify the originating ASN, customer address type, upstream or private-connectivity path, protected or unprotected status, and what happens during maintenance.
Provider-assigned addressing creates an additional dependency. The cloud schedule says Vocus-assigned addresses remain Vocus property, are not transferable and cease to be usable when the service ends. Vocus can change them with notice, or immediately where an urgent change is needed for stability or fault correction. Customer-supplied addresses may be possible, but porting is not available in every location or with every service. A customer that embeds provider addresses in allowlists, DNS, certificates or partner systems has therefore built a migration cost into its network design.
For WCG, the decisive evidence would be a current route trace and service specification from the actual workload, not AS18104's registration. Until then, the legacy ASN is useful for understanding history and corporate integration. It is not a present redundancy certificate.
Repair windows expose the ownership boundary
An outage becomes a chain of permissions as soon as software recovery fails. Someone must determine whether the fault sits in the virtual machine, hypervisor, physical host, storage system, rack power, cross-connect, metro fibre or upstream network. Each boundary can involve a different team, supplier and clock.
Vocus's service-level agreement offers 24-hour access to its support centre and describes phone, email, portal and automatic-alert intake. It says incidents can be escalated to appropriately skilled resources and vendors. It also states that restoration times are targets rather than guarantees and that Vocus will use reasonable endeavours to meet them. This difference matters during a physical fault. A four-hour target is an operating objective; it is not proof that a replacement component, fibre crew or building escort will be available within four hours.
The agreement requires customers to report severe incidents by phone and to supply identifying and diagnostic information. It permits escalation through a matrix made available at service delivery or on request. For a Priority 1 incident, a customer can request a post-incident report, which Vocus says it will use reasonable endeavours to provide within the stated timetable. These are meaningful support mechanisms. They are current Vocus mechanisms, and the public WCG site does not provide a separate current escalation path. A WCG buyer should have the Vocus or other applicable process named in the order before an outage occurs.
Scheduled work is a distinct exposure. The agreement describes hazard, service-impacting, outage and emergency maintenance categories. An outage maintenance notice ordinarily targets ten business days; emergency work may be announced as soon as reasonably practicable, with a goal of eight hours' notice. For colocation work or maintenance performed by third parties, Vocus promises as much notice as reasonably possible in the circumstances. Scheduled maintenance is excluded from ordinary availability rebates.
Third-party colocation makes the boundary even clearer. The NEXTDC schedule defines remote hands as an additional service limited to specified minor technical tasks. It gives facility personnel authority to control access for emergencies, security and legal requirements. It places maintenance obligations for customer equipment on the customer and requires compatibility with the facility's connectivity. Again, this is not evidence of a WCG rack at NEXTDC. It shows the kind of dependency that a group service can inherit when the building, rack customer and hosting customer are different parties.
Equinix arrangements have their own chain. Vocus's Equinix IBX Centre schedule says Equinix retains title to its centre and describes redundant cloud-fabric configurations as requiring dual ports. A customer buying only one port has not bought the redundant configuration merely by being in an Equinix building.
A credible repair design therefore names the owner of each layer. It says who monitors the host, who can open the rack, who stocks parts, who can approve a cross-connect change, when remote hands are available, and which supplier's maintenance exclusions apply. The WCG and Vocus names alone cannot answer those questions.
Multi-city availability is not automatic failover
Sydney, Melbourne and Perth are useful separation points. They reduce exposure to a single building and, depending on design, to a metropolitan power, fibre or disaster event. Vocus says its IaaS delivery points are interconnected by its core network, allowing continuity between instances hosted in other delivery points. That is a capability statement, not a declaration that every customer's data and applications are replicated across all three.
Failover requires capacity, state and authority. The recovery site needs enough reserved processing, memory, storage, licences and bandwidth. Application data must be copied at a frequency consistent with the customer's tolerable loss. Network identity must be transferable or recreated. Staff need permission and tested instructions to start the alternate environment. Dependencies such as DNS, authentication, keys, monitoring and third-party allowlists must survive the move.
The Vocus cloud schedule explicitly says disaster-recovery services are not included unless the service order says otherwise. It excludes virtual-machine and data import and environment configuration unless expressly ordered. It says monitoring and alerting of customer virtual machines sit outside the base compute and storage description. Those exclusions place much of continuity design back with the customer.
The backup provisions are similarly divided. Vocus may provide access to a backup environment, but the customer remains responsible for applying policies and monitoring that the backup works. Under Backup as a Service, Vocus manages the backup platform while the customer manages endpoints, chooses protected data, plans recovery objectives and performs testing. Restoration can incur additional charges, and some restoration is supplied on a reasonable-efforts basis rather than guaranteed. The schedule says the customer is responsible for ensuring the integrity of backed-up data because Vocus cannot validate its nature, content and form.
Australian government guidance reaches the same operational conclusion. The Australian Signals Directorate's cloud security guidance for executives tells organisations to assess business continuity, disaster recovery, secure connectivity, availability terms, retention and portability. Its regular-backup guidance recommends resilient backups and coordinated restoration tests. A replica that has never been restored under realistic conditions is evidence of copying, not evidence of recovery.
For a WCG-labelled service, a buyer should ask for the recovery design in nouns and numbers: primary city, recovery city, replication method, recovery-point objective, recovery-time objective, reserved capacity, route and DNS changes, backup administrator, test frequency and last successful exercise. A claim of three delivery points answers only the first question: where a platform can exist.
Billing failure can become an infrastructure failure
The physical story is only half of hosting resilience. A workload can be healthy and still become inaccessible because an invoice, licence or contract condition is unresolved. This is why billing contacts and renewal dates belong in continuity planning.
Vocus's cloud schedule says customers pay for the allocation in their order even if actual use is lower. Excess bandwidth and backup data can attract additional charges. Third-party software price increases may be passed through with notice, and licence non-compliance can lead to immediate termination in specified circumstances. The customer is responsible for holding the right quantity and type of software licences.
Colocation terms make the consequences more tangible. The Vocus data-centre colocation schedule links charges to ordered space and power, allows cost review in described circumstances and addresses access restrictions. The NEXTDC schedule contains rights relating to unpaid amounts, suspension and customer equipment. These are ordinary commercial protections in infrastructure contracts, but they show that possession and access can diverge. A customer may own a server while depending on payment status and facility permission to reach it.
Provider contracts create another concentration risk when a reseller sits between the customer and the facility. The end customer may pay WCG, while Vocus or another entity contracts with the data-centre operator. If the upstream agreement changes, the buyer needs to know whether its service continues, migrates or terminates. Public corporate membership does not disclose the contractual chain for a particular order.
The practical controls are mundane and valuable: more than one authorised billing contact, verified invoice details, documented dispute escalation, renewal reminders, a record of licence ownership, and a continuity plan that does not depend on logging into a suspended service. The customer should also know whether service credits are automatic or must be claimed. Vocus's agreement requires a written rebate request within a defined period and applies approved amounts as account credits, not cash.
This is where hosted capacity reveals its dual nature. It is a physical reservation and a continuing legal permission to use that reservation. A spare server has little value if the customer's credentials, address allocation or facility access end with the contract. Recoverability must include commercial access, not only hardware survival.
Portability starts before the first workload is installed
Moving a hosted workload is not one operation. It is a bundle of exports and substitutions: data, virtual machines, application configuration, secrets, logs, domain names, DNS records, certificates, IP addresses, licences and support knowledge. Each component can have a different owner and transfer rule.
The WCG domain itself illustrates the separation. A domain licence, authoritative DNS, email hosting and web hosting are distinct services even when one supplier sells all four. auDA's guide to transferring a .au domain says a registrant can move to another eligible provider and explains the transfer-authorisation code. That protects domain portability. It does not move the zone content, mailbox data, website files or server environment automatically.
IP portability is more constrained. Vocus's cloud schedule says provider-supplied addresses cannot be transferred and the right to use them ends with the service. Customer-owned address use is subject to registry standing, approval and service availability. An application built around Vocus addresses may therefore need DNS changes, partner allowlist updates and a carefully timed cutover. The old AS18104 registration does not grant each hosted customer portable WCG addresses.
Compute portability is not specified publicly at the WCG level. Vocus uses widely known virtualisation technology and advertises a single management interface, but familiarity is not an export commitment. A customer needs to know whether it can export virtual disks in a documented format, at what speed, with what assistance and at what cost. Database consistency, snapshot format and software licensing can determine whether an exported image actually starts elsewhere.
Bandwidth can be the slowest part. A large data estate that is easy to store may take days or weeks to copy over a constrained link. If the service is already impaired or suspended, the effective export rate may be lower. Physical media can be faster for very large transfers, but the customer then needs encryption, chain of custody, compatible media and an agreed return process. The cloud schedule's tape provisions, for example, require a timely request if media is to be returned at termination and do not include restoration from tape by default.
A robust exit design is tested while the service is healthy. The customer should export a representative machine and dataset, rebuild networking in a neutral environment, rotate secrets, confirm DNS authority, measure transfer time and verify that backups are readable without the original account. The exercise turns the word portable into an observed duration and a list of dependencies.
For WCG, no public document provides a current export format, guaranteed egress rate, migration-assistance scope or post-termination retention period for a WCG-branded service. Those are not reasons to assume the worst. They are terms that must be supplied before a buyer can price the exit.
Australian delivery points do not answer every locality question
Vocus's public IaaS page says its delivery points are in Sydney, Melbourne and Perth and that they are hosted in its data centres. This is useful evidence for an Australian primary-compute option. It is more specific than a general claim of sovereignty. It still does not identify the location of every copy or every person who can access the environment.
Data locality has several layers. The primary virtual disk may sit in Sydney. Replicas may be in Melbourne or Perth. Backup tapes may be held at an off-site third-party location. Monitoring logs, support records and account information may be processed elsewhere. A vendor may provide remote assistance from another jurisdiction. Public-cloud interconnection can move customer traffic to a separate provider whose regions and support arrangements follow another contract.
The Vocus cloud schedule itself says services in different zones may use different infrastructure and software. It says off-site tape storage can involve a third party. These provisions do not establish overseas storage, but they prevent a buyer from treating an Australian company address as proof that all data remains in Australia.
For personal information, the customer's own legal obligations remain relevant. The Office of the Australian Information Commissioner's Australian Privacy Principles page sets out APP 8 on cross-border disclosure. The OAIC's current Chapter 8 guidance explains the accountability framework and exceptions. Whether a particular transfer is a disclosure, and what steps are reasonable, depends on the facts and applicable law. A data-centre city on a brochure cannot answer that legal question by itself.
A locality schedule should identify primary data, replicas, backups, logs, account data, support access and subprocessors separately. It should also state how location changes are notified and how data is returned or destroyed at the end. Customers with government, health, financial or other regulated workloads may need additional controls beyond the general privacy framework.
The appropriate conclusion for WCG is narrow. An Australian primary hosting option is plausible and supported at Vocus group level. The public evidence does not establish the full location architecture for any current WCG service. Data sovereignty is therefore an order-level property of the selected zones, copies, access paths and suppliers, not an attribute inherited automatically from the letters AU in a registry entry.
What current evidence would close the largest gaps
WCG's public record is strong enough to prevent mistaken identity and weak enough to require direct technical disclosure. A buyer does not need a secret view of the provider's entire estate. It needs evidence tied to the service it will actually receive.
First, the supplier should identify the contracting entity, operating entity and support entity. If Wholesale Communications Group Pty Ltd signs the order while Vocus Pty Ltd operates the network and another Vocus company controls a facility contract, that allocation of responsibility should be explicit. The order should incorporate the applicable standard terms, cloud schedule and service-level agreement by version.
Second, the architecture should name the primary and recovery sites, not merely the country. It should identify whether the site is operated by Vocus or a partner, whether customer equipment or provider equipment is involved, and whether the service uses one or two power feeds, one or two network devices, and protected or unprotected access. A customer does not need the location of every cable, but it does need to know whether two apparent paths share a duct, router, cross-connect or upstream.
Third, capacity evidence should distinguish current allocation from failure headroom. The useful disclosure is not total fleet size; it is whether the selected recovery zone has reserved resources for the customer's workload, which performance limits apply under contention, and what replacement stock and vendor coverage exist. A recent failover exercise is stronger evidence than a design adjective.
Fourth, support should be executable. The customer needs the 24-hour number, service identifiers, named escalation levels, severity definitions, notification method and authority to request urgent work. It should know whether remote hands are included, chargeable or supplied by a third party, and whether a severe hardware fault can be handled outside ordinary business hours.
Fifth, recovery and exit need measurable tests. Backup scope, retention, immutability, restore responsibility, recovery objectives, export format, egress method, address transition and deletion timing should be written down. A sample restore and sample export should be completed before production dependence becomes deep.
Finally, current route evidence should be collected from the delivered service. The originating ASN, address ownership, visible upstream paths and private-connectivity design can all differ from AS18104. A route trace, BGP information where applicable, service order and network diagram would resolve more than the legacy registry text can.
These requests are not an accusation that the service lacks resilience. They are the normal translation from a group-level offer into a customer-level dependency. WCG's unusual combination of corporate continuity and dormant public routing makes that translation impossible to skip.
The operating verdict
WCG is neither a blank name nor a transparently independent cloud operator. Wholesale Communications Group Pty Ltd is active, remains within current Vocus group disclosure, retains a live domain namespace and is associated with AS18104. Those facts support identity and continuity.
The network evidence points in a different direction. AS18104 is registered but not currently visible as an origin. Its last route observation is from 2012. PeeringDB's single Sydney facility declaration is old and shows no public exchange connection. WCG's domain resolves through another Vocus network and does not provide a working public sales site. The most supportable current hosting proposition is therefore the Vocus group offer, not a standalone platform proven by the WCG ASN.
That group offer has real infrastructure claims: three Australian IaaS cities, a national data-centre estate, extensive external facility reach and round-the-clock support. Its public terms also make the dependency structure legible. Compute can require separately ordered connectivity. Multi-city presence does not include disaster recovery by default. Backup correctness and restore testing remain partly the customer's job. Assigned IP addresses do not leave with the customer. Repair and maintenance can cross facility and vendor boundaries. Remedies are bounded by targets, exclusions and claims procedures.
For customers, the central risk is not that hosted capacity is imaginary. It is that nominal capacity, usable capacity and recoverable capacity may be different, while the WCG name does not reveal which Vocus assets and terms bridge the gap. A sound purchase identifies the actual provider, site, route, protection level, spare capacity, repair authority, recovery reservation and exit mechanism.
The final judgment is therefore conditional. WCG has credible group context and an identifiable legal home, but AS18104 cannot presently carry a claim of independent routing, and public records do not establish WCG-specific racks, transit diversity, server stock or tested failover. Buyers should treat current availability as service-order evidence: strong when tied to named Vocus resources and tested recovery, weak when inferred from a legacy network number or a corporate name alone.