Granite Networks After Acquisition: Data-Centre Identity, IPv4 Continuity, and Operational Handover Costs

Summary

Granite Networks was a Canadian colocation, managed-services, and cloud-hosting company acquired by Rogers in 2013. Canadian corporate records then show a continuation into British Columbia and an amalgamation under Rogers Data Services Inc. Those events establish a transfer of legal and operating responsibility, not an instantaneous replacement of every system, address, customer record, or facility process.
A current public record for 198.41.28.0/22 retains a Granite-derived network label while naming Rogers Communications Canada Inc. and showing AS29988 as the observed origin. That combination is evidence of number-resource and routing continuity across a change of company identity. It is not proof of uptime, latency, security, capacity, customer satisfaction, or the current use of every address.
The durable engineering problem is re-keying: legal authority, network records, abuse contacts, monitoring, credentials, customer inventory, physical access, suppliers, recovery procedures, and incident ownership must all point to the accountable operator without erasing the historical labels needed to diagnose old services.

Image note: The accompanying photograph shows Wikimedia Foundation server equipment and cabling as generic hosting and network-continuity context. It does not depict Granite Networks, Rogers, a Granite or Rogers facility, the 198.41.28.0/22 network, a customer deployment, service reliability, an incident, or a production outcome.

Granite Networks is useful to study precisely because its public identity did not disappear in one clean technical transaction. The current BTW directory entry preserves Granite Networks Inc. as a company object. A Rogers acquisition announcement says Rogers completed acquisitions of Granite Networks and Pivot Data Centres in September 2013. Canadian registry records subsequently trace the Granite corporation through a provincial continuation and amalgamation. Meanwhile, public Internet-number records still contain a Granite-derived label on an IPv4 block now associated with Rogers.

Those sources describe different layers. The directory identifies the research subject. Corporate registries record legal status and succession. Rogers describes the transaction and the service capability it expected to add. Internet registries and routing-data services expose current responsibility metadata and observed route origin. None of those sources, alone or together, is a complete picture of present architecture or service performance.

This distinction matters in infrastructure operations. A transaction can close on one date, a corporate amalgamation can take effect on another, customer contracts can move in waves, and registry contacts can be updated on yet another schedule. Equipment may remain in place while monitoring, credentials, ticket ownership, and escalation paths change. A historical network name may remain valuable because customers, devices, circuits, address records, and runbooks still carry it. Removing every old label can be as damaging as leaving every old authority active.

The central technical question is therefore not whether a corporate acquisition happened. The public record establishes that. The question is how an accountable operator preserves coherent authority and recoverability when a hosting company's independent legal identity ends but operational assets and records continue. Granite Networks offers a bounded case through which to examine that problem without inventing private architecture, tests, incidents, customer results, or benchmarks.

The exact identity boundary

Entity precision comes first. Granite Networks Inc. is the exact existing directory company object considered here. The federal corporation record identifies corporation number 799789-2 and records the entity as inactive after discontinuance on 19 December 2013. A British Columbia registry notice records the continuation into that province on the same date. A later provincial notice records an amalgamation effective 1 January 2014 under the Rogers Data Services Inc. name.

These records establish a legal sequence. They do not show that servers stopped, addresses were withdrawn, or customers lost service on either date. A corporation's status is an authority fact. A running network is an operational fact. The two are connected because someone must own contracts, assets, credentials, and duties, but they are not interchangeable measurements.

Rogers supplies the transaction link. Its acquisition announcement describes Granite as providing colocation, managed services, and cloud hosting in Eastern Ontario and Western Quebec. Rogers' third-quarter 2013 results release reports a cash consideration of approximately CAD 6.25 million for Granite. Financial consideration confirms that an acquisition was accounted for; it does not value individual systems or establish the quality of integration.

The public identity after that transaction becomes layered. "Granite Networks" can refer to the historical company, a former commercial service identity, a label retained in a network record, or an internal alias used to find inherited assets. "Rogers Data Services" describes a successor corporate identity in the amalgamation record. "Rogers Communications Canada" appears in current Internet-number evidence. Those names may all be accurate in their own contexts while pointing to different legal and operational roles.

An operator needs an explicit identity map rather than a rule that replaces one string with another. The map should connect historical legal names, current legal owner, service brands, facility identifiers, network labels, customer-account identifiers, number resources, support queues, and escalation groups. Each connection needs an effective date and evidence. A customer report that mentions Granite should still resolve to the correct current owner. A registry account that once belonged to Granite should not remain controlled by a departed employee merely because the old label is still searchable.

This approach follows a practical boundary between records and running systems. A registry is a ledger and recordkeeper. It can state who is registered, when a corporate event took effect, or which organisation is associated with an address block. It does not configure a router, restore a server, admit a technician to a facility, or decide whether a customer application is healthy. Conversely, a responding service does not prove that every authority record is current. Operations have to reconcile both surfaces.

Granite's documented hosting model before acquisition

Rogers' description places Granite in the data-centre operating chain rather than in generic business software. Colocation provides controlled space, power, cooling, physical security, and network access for customer equipment. Managed services add operating responsibility around systems, networks, monitoring, backup, security, or support, depending on the contract. Cloud hosting abstracts some physical resources behind service interfaces and allocation processes. These capabilities create related but distinct control surfaces.

The acquisition announcement is evidence that Rogers represented Granite as having those service capabilities in 2013. It does not disclose a complete facility list, topology, hardware inventory, software stack, staffing model, utilisation level, or customer architecture. Nor does it prove that every capability operated under one platform. A small hosting company can deliver apparently unified services through a mixture of owned equipment, leased space, upstream connectivity, vendor appliances, scripts, human procedures, and supplier portals.

That mixture makes handover expensive. A rack location may be linked to a customer record in one system and to a power circuit in another. A public address may appear in a firewall object, a reverse-DNS zone, a monitoring target, an abuse case, and a billing record. A managed server may depend on a hardware warranty, backup credential, privileged account, maintenance window, and customer-specific escalation rule. A cloud service may depend on storage, network, identity, orchestration, and capacity controls that fail in different ways.

The service label alone does not reveal those dependencies. "Managed hosting" may mean monitoring and incident notification for one customer, while it includes operating-system administration and backup responsibility for another. "Colocation" may include only space and power, or it may include remote hands and connectivity. "Cloud" may describe virtual machines on a local platform without saying how redundancy, backup, or recovery is implemented. The public evidence establishes a capability category, not the detailed responsibility boundary for any contract.

Integration must therefore begin with a service-by-service inventory. The acquiring operator needs to know which entity signed the contract, where the equipment is, who owns it, how it is powered, which network resources it uses, which team can change it, what is monitored, what the customer controls, and how recovery is authorised. A simple count of migrated accounts cannot prove that those relationships survived.

Historical capability also needs a time label. A 2013 description can support a statement about the acquisition target at that time. It cannot safely describe Rogers' current data-centre platform. Rogers later announced expansions in other Canadian markets, including in its data-centre expansion release. That later development provides context for a broader data-centre strategy, but it does not prove that an Edmonton or Calgary facility used Granite's architecture or served Granite's former customers.

The defensible conclusion is narrow: Granite brought documented hosting and managed-service capability into Rogers. The technology value of that capability depended not only on equipment and space but also on accurate operating knowledge, access, customer mappings, network identity, and recovery authority. Those intangible links are easy to omit from a transaction summary and difficult to reconstruct after staff and systems change.

Acquisition, continuation, and amalgamation

The sequence from acquisition announcement to discontinuance, continuation, and amalgamation is not administrative trivia. It defines when different kinds of authority may need to move. Transaction completion can transfer economic control. Continuation can move the corporate entity between jurisdictions. Amalgamation can place rights and obligations under a successor. Operational teams still have to translate those legal events into access controls, supplier instructions, customer notices, registry contacts, and change authority.

The first handover task is asset identity. An inventory needs more than a hostname or serial number. It should connect the physical asset, logical service, customer, facility, network addresses, support entitlement, maintenance state, data sensitivity, and current owner. Duplicate or ambiguous identifiers are especially dangerous after acquisition because an old and new system may each appear authoritative.

The second task is credential and authority transfer. Routers, switches, hypervisors, storage systems, environmental controls, ticketing platforms, backup systems, domain accounts, certificate stores, supplier portals, and Internet registries can all carry privileged access. Copying a password is not an authority model. The acquirer needs named roles, deputies, approval boundaries, revocation evidence, emergency access, and logs that remain usable after the acquired entity disappears.

The third task is supplier continuity. A hosting service can depend on power utilities, facility landlords, carriers, transit providers, hardware vendors, maintenance contractors, security services, domain registrars, certificate authorities, and software-support organisations. A corporate name change can make a valid support request fail if entitlement remains tied to the predecessor. It can also create a security risk if a supplier continues accepting instructions from an address or contact that no longer has authority.

The fourth task is customer continuity. Customers may know a circuit, rack, IP address, server, invoice description, or support number by the Granite name. The operating successor may use a different account identifier and system of record. A crosswalk needs to preserve both the current identity and the historical search keys. Otherwise, a legitimate incident can arrive with facts that no current system recognises.

The fifth task is evidence continuity. Configuration history, diagrams, monitoring baselines, maintenance reports, backup records, incident notes, and customer exceptions need retention rules. The goal is not to keep every obsolete document forever. It is to preserve enough provenance to explain why current state exists and to recover safely. A current diagram without change history may hide an inherited exception. An old diagram without a clear validity date may be mistaken for current architecture.

Rogers' fourth-quarter 2013 results release places acquired data-centre businesses within the reporting period, while the corporate registry notices show legal steps around the turn of the year. These sources establish that several transition surfaces existed close together. They do not expose the internal migration schedule. Any claim that all systems, customers, or network records moved at once would go beyond the evidence.

Good handover design accepts staggered movement and controls it. Every asset or service should have an old identity, a current identity, a migration state, an accountable owner, a validation result, and a rollback or recovery plan. The oldest unresolved exceptions deserve attention because they are most likely to contain undocumented dependencies. Completion should mean that the successor can operate and recover the service, not merely that a database row was copied.

IPv4 registration and routing continuity

Internet-number records provide a concrete example of identity surviving corporate change. The RIPEstat prefix overview for 198.41.28.0/22 associates the observed origin with AS29988. The corresponding RIPEstat WHOIS aggregation exposes the network name RCC-GN-198 and identifies Rogers Communications Canada Inc. The embedded GN is a historical clue; the current organisation field points to Rogers.

That record is evidence of registration metadata and a particular observed routing relationship. It does not establish that the block was Granite's entire address footprint, that every address was used by Granite, or that every address still supports the same service. It does not show internal subnetting, customer assignment, firewall policy, reverse DNS, traffic volume, or dependency. It should be treated as one traceable number-resource object.

The RIPEstat routing-status endpoint adds current observation data. A route collector can report that a prefix is visible and name an origin. That is valuable because it describes running public routing at a point in time. It remains a bounded observation. It cannot prove end-to-end reachability from every network, traffic delivery to a specific customer, stable routing over a month, or compliance with a service objective.

RPKI is another separate layer. The RIPEstat RPKI validation endpoint provides a way to inspect how a prefix-origin pair relates to published route-origin authorisation data at a given time. Its result must be interpreted with the exact prefix, origin, capture time, and relying-party state. RPKI validation does not authenticate a company's whole network, measure availability, or prove that a route was intended by a customer.

For an acquiring operator, number-resource handover requires several reconciliations. Registration records need the correct organisation and abuse contacts. Route policy needs an approved origin and propagation intent. RPKI and Internet Routing Registry objects need current maintainers and authorised content. Reverse-DNS authority needs the correct delegation and operational owner. Monitoring needs to know which prefixes are expected and which change is planned. Incident processes need to connect a historical label to the team that can act now.

These records move on different paths. Updating a corporate name does not automatically update router configuration. Changing a registry contact does not automatically update PeeringDB, RPKI, reverse DNS, a customer's access list, or a carrier's prefix filter. Conversely, a route can continue to work while its abuse mailbox is stale. The absence of immediate traffic impact can conceal a control failure until an incident requires a change or an external party needs an authorised response.

Accuracy matters because Internet numbers are shared coordination resources. Uniqueness prevents conflicting assignment. Registration identifies responsibility and supports transfer records. Security metadata helps other networks evaluate route origin. Operational continuity ensures that the recorded owner can actually investigate and repair a problem. None of those functions makes a registry sovereign over the running network; each supports accountable coordination.

The Granite-derived label is therefore useful rather than embarrassing if it is intentionally retained and correctly mapped. Historical labels help operators find old customer documents, access lists, tickets, and diagrams. The risk is not that history remains visible. The risk is that the label is mistaken for current legal authority, or that current authority cannot interpret it. A good identity model keeps history searchable while ensuring that every high-impact action resolves to a current accountable owner.

Capability, reliability, and customer results are different claims

Technology-company reporting often collapses three evidence layers. Granite's case shows why they need separation.

The first layer is capability. Rogers' acquisition release describes colocation, managed services, and cloud hosting. A public route record shows that a prefix-origin relationship can be observed. Corporate records show that an entity was acquired and amalgamated. These facts support statements about service categories, recorded authority, and observable interfaces.

The second layer is operational reliability. Reliability requires repeated measurements across a declared service boundary. For hosting, that might include power events, environmental conditions, hardware failures, backup results, network reachability, change failure, incident restoration, and recurrence. For routing, it might include expected-prefix coverage, origin consistency, convergence, reachability from independent vantage points, and change correlation. A single successful query or visible route is not a reliability study.

The third layer is customer production outcome. A customer outcome needs a defined customer context, baseline, measurement period, dependencies, and result. Lower incident time, faster provisioning, reduced cost, or improved availability cannot be inferred from an acquisition announcement or a current registry record. Customer environments can differ even when they use the same provider.

The distinction prevents two opposite errors. One is promotional inflation: turning capability or strategy into a claim that customers received a measured benefit. The other is unsupported pessimism: treating missing public reliability data as evidence that the service failed. Public evidence can be strong for identity and capability while remaining insufficient for performance and customer outcomes.

This article does not claim to have tested Granite or Rogers systems. It does not reproduce a benchmark, inspect private configuration, measure an outage rate, verify a customer workload, or interview operating staff. The analysis instead identifies the controls that would be required to connect public identity evidence to defensible operational conclusions.

Four recurring operating costs

Supervision cost

Supervision defines intended state and decision rights. After acquisition, someone must be accountable for corporate identity mappings, facilities, customer services, network resources, monitoring, credentials, suppliers, and recovery. The owner of a record may differ from the person who operates a device, and both may differ from the person authorised to accept business risk.

The cost recurs because responsibility data ages. Staff leave, legal entities change, service brands are retired, supplier portals are replaced, and customer contacts become stale. A quarterly or event-driven review should test whether published contacts reach the right team, whether deputies exist, and whether the owner can produce evidence of current state. A name in a field is not supervision if no one can act through it.

Independent checks are part of supervision. A high-impact registry or routing change should be compared with approved intent by someone or something outside the execution path. Facility-access lists, backup restoration, customer escalation, and supplier authority also benefit from exercised controls. Independence reduces the chance that the same mistaken assumption controls both action and evidence.

Integration cost

Integration connects systems that represent the same service differently. Granite's customer records, physical assets, IP assignments, monitoring targets, tickets, invoices, and supplier accounts would have needed mappings into Rogers systems. A successful data import can still lose relationships. A server can exist in inventory without its customer, power circuit, backup owner, or recovery dependency.

End-to-end tests should begin with an operating question. Can a current responder take a Granite-era customer identifier, find the active service, locate the physical and logical dependencies, identify the current change authority, contact the right supplier, and confirm recovery? Can an abuse report for an address in 198.41.28.0/22 reach a team that understands both the current Rogers record and the historical network label? Record counts cannot answer those questions.

Integration also requires shared definitions. "Owner" can mean legal owner, asset custodian, commercial account owner, configuration approver, on-call responder, or risk acceptor. "Active" can mean powered, reachable, monitored, billable, supported, or authorised. Ambiguous fields create silent errors at system boundaries. A precise state model is a production control, not documentation decoration.

Maintenance cost

Maintenance keeps the combined operating model usable after the migration project ends. Corporate aliases, address records, route intent, abuse contacts, reverse DNS, facility inventories, customer crosswalks, monitoring, backups, software support, spares, and recovery procedures all need review. The historical Granite label may need to remain in search indexes and runbooks even after it no longer represents an independent corporation.

Lifecycle evidence is essential. Public acquisition material does not say which Granite-era servers, network devices, storage systems, or software remained in service, when they were replaced, or how support was maintained. The current operator needs an internal asset record tied to version, support state, owner, dependency, backup, and replacement plan. Without that record, old capability descriptions can be mistaken for current architecture.

Evidence itself needs maintenance. A change without a retained reason becomes hard to interpret later. A facility move without updated address and access records delays the next incident. A customer migration without an old-to-new identifier mapping leaves support unable to find a valid service. Maintenance cost includes keeping enough history to explain and recover current state.

Exception-handling cost

Normal cases can be automated. Exceptions consume judgement. A route appears under an unexpected origin, an old abuse address still receives mail, a customer identifier has no current mapping, a supplier rejects the successor's authority, or a physical asset does not match inventory. Each case needs impact assessment, evidence, an owner, a decision, communication, and closure.

An exception register should record age as well as count. The oldest cases often contain the most obscure dependencies. Repeated mismatches should change the control system rather than generate more reminders. If Granite labels repeatedly fail to resolve to current ownership, identity mapping and alert context need repair. If customer assets repeatedly lack power or network relationships, the inventory model is incomplete.

Exception cost belongs in service economics. A transaction can appear complete while a small tail of inherited services consumes disproportionate attention for years. The objective is not an unrealistic claim that no inconsistency remains. It is that every material exception is visible, bounded, owned, and prevented from becoming an unexamined production dependency.

Failure modes and concrete controls

1. The historical company name is mistaken for current authority

An operator sees GN or Granite in a network record and directs a change to an obsolete contact. The control is an approved identity map with effective dates, accepted aliases, current legal owner, operating owner, and escalation path. Historical labels remain searchable but cannot authorise a change.

2. Current authority erases useful historical identity

A migration removes every Granite alias from inventory and support search. A customer or abuse report then arrives with a valid old identifier that no current system recognises. The control is alias retention with explicit status. Old labels should resolve to current objects without retaining old privileges.

3. Corporate status is treated as network state

A reviewer interprets the 2013 discontinuance or 2014 amalgamation as proof that routes, hosted systems, or customer services stopped on that date. The control is evidence typing: corporate records describe legal identity; routing observations describe public route state; service evidence describes actual delivery. One layer cannot silently substitute for another.

4. A visible route is reported as service reliability

198.41.28.0/22 appears in collector data and a report declares the associated service healthy. The route may be visible while a server, application, customer circuit, power feed, DNS dependency, or return path fails. The control is layered monitoring with a declared boundary and independent service checks.

5. An expected route disappears

The prefix is withdrawn, filtered, or originated elsewhere. The control is an approved expected-prefix inventory, multi-vantage observation, planned-change correlation, RPKI and registry review, and an escalation path that distinguishes engineering from leak, hijack, or equipment failure.

6. An unexpected prefix or origin appears

AS29988 begins originating an address range absent from the approved inventory, or the Granite-derived prefix appears under another origin. The control is fail-closed reconciliation: verify authorisation, registration, route-origin data, configuration intent, and affected services before treating the observation as normal.

7. Abuse and NOC contacts drift apart

The registry lists a current organisation but an abuse report reaches an old or unmonitored channel. The control is regular delivery testing, role accounts, deputy coverage, ticket integration, and measured response ownership. A syntactically valid mailbox is not an operating contact.

8. Privileged access survives the legal entity

An acquired administrator or supplier account remains active after authority has moved. The control is a transaction-specific access inventory, explicit revocation, role-based replacement accounts, emergency-access testing, and review of high-impact actions. Searchable historical identity must not preserve obsolete authority.

9. The successor cannot prove supplier entitlement

A facility, carrier, or hardware vendor rejects a support request because the contract or asset remains under the predecessor name. The control is a supplier crosswalk with assignment evidence, current contacts, account identifiers, and a tested escalation route before an incident occurs.

10. Customer billing moves but technical context does not

A commercial account is present in the successor system, but rack, circuit, address, maintenance restriction, backup scope, or monitoring owner is missing. The control is an end-to-end migration test that links customer, contract, logical service, physical asset, network identity, support entitlement, and recovery owner.

11. A facility asset cannot be located or accessed

Inventory says a server or network device exists, but rack position, power path, access list, key, remote-hands procedure, or spare is wrong. The control is physical verification, access exercises, current diagrams, labelled dependencies, and recovery drills that include off-hours conditions.

12. Backup evidence exists but recovery fails

A report shows successful backup jobs, yet credentials, encryption keys, network dependencies, or restore instructions are unusable. The control is a restoration test into an isolated target with measured completeness and a named decision owner. Backup completion is capability evidence, not recovery proof.

13. Shared platforms increase common-mode exposure

Consolidation reduces duplicated tooling but places multiple inherited services behind one identity, monitoring, network, or orchestration dependency. The control is dependency mapping, staged migration, independent observation, rollback, and recovery tests that assume the shared control plane is unavailable.

14. Old architecture is presented as current

A historical Granite description is copied into a current diagram without verification. The control is evidence dating. Every material architecture claim should identify source date, current owner, verification status, and replacement history. Historical material belongs in provenance until current evidence confirms it.

15. A registry update is assumed to update every consumer

The organisation or contact changes in one database, while PeeringDB, route policy, RPKI, reverse DNS, customer access lists, monitoring, or carrier filters retain old state. The control is a change checklist across independent systems, followed by outside verification and explicit closure.

16. Acquisition rationale becomes a customer outcome claim

A transaction release describes strategic capability and later reporting treats it as proof of lower cost, better uptime, or improved performance. The control is an evidence ladder. Capability belongs to the first layer. Reliability needs repeated measurements. Customer outcomes need customer-specific baselines and results.

17. Exception debt becomes invisible

Most services migrate and a small group of difficult records remains unresolved without an owner. The control is an aged exception register with impact, next action, accepted risk, and expiry. A high completion percentage must not hide a consequential unresolved dependency.

18. The observed prefix is mistaken for the whole company network

One Granite-derived netname is available publicly, and analysis generalises it to all historical or current services. The control is scope labelling. 198.41.28.0/22 is one observed object. Any broader inventory requires separate evidence for each address range, origin, assignment, and service relationship.

Questions an accountable operator should be able to answer

The first question is identity. What is the authoritative mapping among Granite Networks Inc., Rogers Data Services Inc., Rogers Communications Canada Inc., historical service labels, facilities, customer records, and network objects? Which aliases are intentionally retained, and which identities can still authorise action?

The second question is number-resource intent. Which address ranges are currently registered to the operator, which origins are approved, which RPKI and routing-policy objects should exist, and which team owns reverse DNS and abuse response? Public data can help verify the answer, but the approved inventory belongs to the operator.

The third question is service boundary. For each inherited colocation, managed, or cloud service, which components are controlled by Rogers, which are customer-controlled, and which depend on suppliers? A service objective is meaningful only when that boundary is explicit.

The fourth question is physical continuity. Can staff locate equipment, trace power and network dependencies, obtain facility access, reach remote hands, identify spares, and execute a recovery procedure? A facility address and a rack count do not establish recoverability.

The fifth question is change authority. Who can approve and execute changes to registry records, route policy, RPKI, reverse DNS, network devices, hosting platforms, backups, monitoring, and customer configuration? Which changes require independent review, and what evidence confirms the final state?

The sixth question is customer traceability. Can current support staff resolve a report that contains only a Granite-era account, hostname, circuit, rack, or IP address? Can they identify entitlement, dependencies, maintenance restrictions, and the current escalation owner without relying on personal memory?

The seventh question is reliability evidence. What repeated measures cover facility power, environmental control, hardware, storage, backup, network reachability, route intent, incidents, restoration, and recurrence? Which measurements are independent of the system they assess, and what service boundary does each one prove?

The eighth question is customer outcome. What changed for a defined customer after integration, compared with what baseline and over what period? If that evidence is unavailable, claims should remain at capability or process level. Missing outcome evidence is a limit on reporting, not evidence of success or failure.

The ninth question is portability. Could the operator recover or transfer the service if a facility, supplier, control plane, credential system, or key employee became unavailable? Portability requires usable data, documented authority, compatible exports, tested credentials, and a recipient able to reconstruct relationships.

The tenth question is exception debt. Which inherited records, services, suppliers, or physical assets remain unresolved? How old are they, what impact can they create, who owns the next action, and when does accepted risk expire? A migration is not operationally complete while material exceptions remain unowned.

What the evidence establishes and what remains unknown

The public record establishes a real company, a documented hosting role, an acquisition, a legal succession, and a continuing number-resource trace. Granite Networks Inc. is an existing BTW directory object. Canadian corporate records document discontinuance, continuation, and amalgamation. Rogers describes the service capability it acquired and reports transaction consideration. RIPEstat exposes a current Granite-derived network label associated with Rogers and an observed AS29988 origin.

That evidence is strong enough to analyse authority and continuity. It shows why company identity, service identity, corporate succession, address registration, and observed routing must be reconciled. It supports a discussion of supervision, integration, maintenance, exception handling, and failure modes.

Important facts remain unknown. The reviewed sources do not disclose Granite's complete historic address inventory, private topology, facility design, server inventory, software versions, staffing, customer list, utilisation, incident history, backup results, security controls, supplier contracts, or current descendant architecture. They do not establish how many original systems remained after acquisition, when individual customers moved, or which present Rogers services descend directly from Granite.

The sources also do not establish longitudinal reliability. A current route observation is not an availability series. A registry contact is not a response-time measurement. A corporate transaction is not a recovery test. No customer-specific production result was reviewed. Those limitations should remain visible rather than being filled with assumptions.

Conclusion

Granite Networks is not best understood as a vanished company name or as a generic acquisition story. It is an infrastructure-identity case. The independent corporation ended through a documented legal sequence, while hosting responsibilities and an identifiable Internet-number record continued under Rogers. That continuity is possible only when records, running systems, and recovery authority are re-keyed coherently.

The durable asset is not merely a facility, server, or address block. It is the relationship among legal authority, customer obligation, physical location, network identity, privileged access, supplier entitlement, monitoring, evidence, and recovery. A transaction can transfer economic control quickly. Rebuilding those relationships after they are lost can take far longer.

The public evidence supports capability and identity claims. It does not support invented uptime, benchmark, architecture, incident, or customer-outcome claims. That boundary is productive. It directs attention to the controls that can actually be tested: identity mapping, expected route state, contact reachability, access authority, asset traceability, restore exercises, customer crosswalks, supplier escalation, and aged exception ownership.

Granite's historical label in a current number-resource record is therefore not proof that nothing changed. Nor is the company's inactive status proof that the network stopped. Together they show why infrastructure operations need both a reliable ledger and evidence from running systems. The accountable successor must preserve history without confusing it with current authority, and it must maintain current authority without making inherited services impossible to find.